Spécification d'un autre référentiel source de correctifs (Linux)

Lorsque vous utilisez les référentiels par défaut configurés sur un nœud géré pour les opérations d'application de correctifs, une fonctionnalité de recherchePatch Manager, de recherche ou d' AWS Systems Managerinstallation de correctifs liés à la sécurité. Il s'agit du comportement par défaut pour Patch Manager. Pour des informations détaillées sur la façon dont Patch Manager sélectionne et installe les correctifs de sécurité, consultez Sélection des correctifs de sécurité.

Toutefois, sur les systèmes Linux, vous pouvez également utiliser Patch Manager pour installer des correctifs non liés à la sécurité ou provenant d'un référentiel source autre de celui configuré par défaut sur le nœud géré. Vous pouvez spécifier d'autres référentiels source de correctifs lors de la création d'un référentiel de correctifs personnalisée. Dans chaque référentiel de correctifs personnalisée, vous pouvez spécifier des configurations source de correctifs pour un maximum de 20 versions d'un système d'exploitation Linux pris en charge.

Par exemple, supposons que votre parc Ubuntu Server contienne à la fois les instances gérées Ubuntu Server 14.04 et Ubuntu Server 16.04. Dans ce cas, vous pouvez spécifier d'autres référentiels pour chaque version dans la même référentiel de correctifs personnalisée. Pour chaque version, vous fournissez un nom, spécifiez le type de version du système d'exploitation (produit) et indiquez une configuration de référentiel. Vous pouvez également spécifier un autre référentiel source unique, qui s'applique à toutes les versions d'un système d'exploitation pris en charge.

Note

L'exécution d'un référentiel de correctifs personnalisé spécifiant des référentiels alternatifs pour un nœud géré ne fait pas de ceux-ci les nouveaux référentiels par défaut sur le système d'exploitation. Une fois les correctifs appliqués, les référentiels précédemment configurés par défaut pour le système d'exploitation du nœud restent les référentiels par défaut.

Pour obtenir la liste des exemples de scénarios pour l'utilisation de cette option, consultez Exemples d'utilisations pour d'autres référentiels source de correctifs plus loin dans cette rubrique.

Pour plus d'informations sur les références de correctifs par défaut et personnalisées, consultez À propos des références de correctifs prédéfinies et personnalisées.

Exemple : utilisation de la console

Pour spécifier d'autres référentiels source de correctifs lorsque vous travaillez dans la console Systems Manager, utilisez la section Sources des correctifs de la page Créer un référentiel de correctifs. Pour de plus amples informations sur l'utilisation des options Sources des correctifs, veuillez consulter Création d'un référentiel de correctifs personnalisé (Linux).

Exemple : utilisation du AWS CLI

Pour un exemple d'utilisation de l'option --sources à l'aide de l' AWS Command Line Interface (AWS CLI), consultez Création d'un référentiel de correctifs avec des référentiels personnalisés pour les différentes versions du système d'exploitation.

Points importants à prendre en compte pour d'autres référentiels

Gardez les points suivants à l'esprit lorsque vous planifiez votre stratégie d'application de correctifs en utilisant d'autres référentiels de correctifs.

Seuls les référentiels spécifiés sont utilisés pour l'application de correctifs

Spécifier d'autres référentiels ne signifie pas spécifier des référentiels supplémentaires. Vous pouvez choisir de spécifier des référentiels autres que ceux configurés par défaut sur un nœud géré. Toutefois, vous devez également spécifier les référentiels par défaut dans le cadre de la configuration d'autres sources de correctifs si vous voulez que leurs mises à jour soient appliquées.

Par exemple, sur les nœuds gérés Amazon Linux 2, les référentiels par défaut sont amzn2-core et amzn2extra-docker. Si vous souhaitez inclure le référentiel EPEL (Extra Packages for Enterprise Linux) dans vos opérations d'application de correctifs, vous devez spécifier ces trois référentiels en tant que référentiels alternatifs.

Note

L'exécution d'un référentiel de correctifs personnalisé spécifiant des référentiels alternatifs pour un nœud géré ne fait pas de ceux-ci les nouveaux référentiels par défaut sur le système d'exploitation. Une fois les correctifs appliqués, les référentiels précédemment configurés par défaut pour le système d'exploitation du nœud restent les référentiels par défaut.

Le comportement d'application de correctifs pour les distributions basées sur YUM dépend du manifeste updateinfo.xml

Lorsque vous spécifiez des référentiels de correctifs alternatifs pour les distributions basées sur Yum, telles qu'Amazon Linux 1, Amazon Linux 2 Red Hat Enterprise Linux ou CentOS, le comportement des correctifs dépend du fait que le référentiel inclut ou non un manifeste de mise à jour sous la forme d'un fichier complet et correctement formaté. updateinfo.xml Ce fichier spécifie la date de parution, la classification et la sévérité des différents packages. Les éléments suivants ont un impact sur le comportement d'application des correctifs :

• Si vous filtrez selon Classification et Severity (Sévérité), mais qu'elles ne sont pas spécifiées dans updateinfo.xml, le package ne sera pas inclus par le filtre. Cela signifie également que les packages sans fichier updateinfo.xml ne seront pas inclus dans l'application des correctifs.

• Si vous filtrez ApprovalAfterDays, mais que la date de sortie du package n'est pas au format Unix Epoch (ou qu'aucune date de sortie n'est spécifiée), le package ne sera pas inclus dans le filtre.

• Il existe une exception si vous cochez la case Inclusion de mises à jour non liées à la sécurité sur la page Créer une référence de correctif. Dans ce cas, les packages sans fichier updateinfo.xml (ou contenant ce fichier sans que les valeurs de Classification, Severity (Sévérité) et Date soient correctement formatées) seront inclus dans la liste préfiltrée des correctifs. (Ils doivent encore satisfaire aux autres conditions préalables relatives aux règles de référentiel de correctifs pour pouvoir être installés.)

Exemples d'utilisations pour d'autres référentiels source de correctifs

Exemple 1 - Mises à jour non liées à la sécurité pour Ubuntu Server

Vous avez déjà l'habitude d'Patch Managerinstaller des correctifs de sécurité sur un parc de nœuds Ubuntu Server gérés à l'aide de la base AWS-UbuntuDefaultPatchBaseline de correctifs prédéfinie AWS fournie. Vous pouvez créer un référentiel de correctifs basée sur cette valeur par défaut, mais spécifiez dans les règles d'approbation que vous ne voulez pas que les mises à jour non liées à la sécurité qui font partie de la distribution par défaut soient également installées. Lorsque ce référentiel de correctifs est exécuté sur vos nœuds, tous les correctifs, qu'ils soient liés ou non à la sécurité, sont appliqués. Vous pouvez également choisir d'approuver les correctifs non liés à la sécurité dans les exceptions de correctif que vous spécifiez pour une référence.

Exemple 2 - Dépôts PPA (Personal Package Archive) pour Ubuntu Server

Vos nœuds gérés Ubuntu Server exécutent des logiciels distribués par le biais de référentiels PPA (Personal Package Archive) pour Ubuntu. Dans ce cas, vous créez un référentiel de correctifs spécifiant un référentiel PPA que vous avez configuré sur le nœud géré en tant que référentiel source pour l'application des correctifs. Utilisez ensuite la fonctionnalité Run Command pour exécuter le document de référentiel de correctifs sur les nœuds.

Exemple 3 – Applications d'entreprise internes sur Amazon Linux

Certaines applications doivent être exécutées sur vos nœuds gérés Amazon Linux pour mettre ceux-ci en conformité avec les réglementations du secteur. Vous pouvez configurer un référentiel dédié à ces applications sur les nœuds, utiliser YUM pour installer les applications, puis mettre à jour ou créer un référentiel de correctifs pour inclure ce nouveau référentiel d'entreprise. Vous pouvez ensuite utiliser la fonctionnalité Run Command pour exécuter le document AWS-RunPatchBaseline avec l'option Scan afin de déterminer si le package d'entreprise est répertorié parmi les packages installés et à jour sur le nœud géré. S'il n'est pas à jour, vous pouvez exécuter à nouveau le document à l'aide de l'option Install pour mettre à jour les applications.