• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la [documentation Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Document de commande SSM pour l’application de correctifs : `AWS-RunPatchBaseline` AWS Systems Manager supports`AWS-RunPatchBaseline`, un document Systems Manager (document SSM) pourPatch Manager, un outil dans AWS Systems Manager. Ce document SSM permet d'appliquer des correctifs sur les nœuds gérés, tant pour les mises à jour liées à la sécurité que pour les autres types de mises à jour. Si aucun groupe de correctifs n'est spécifié, lorsque le document est exécuté, il utilise le référentiel de correctifs spécifié « par défaut » pour un type de système d'exploitation. Sinon, il utilise le référentiel de correctifs associé au groupe de correctifs. Pour de plus amples informations sur les groupes de correctifs, veuillez consulter [Groupes de correctifs](patch-manager-patch-groups.md). Vous pouvez utiliser le document `AWS-RunPatchBaseline` pour appliquer des correctifs pour les systèmes d'exploitation et les applications. (Sur Windows Server, la prise en charge des applications est limitée à des mises à jour pour les applications publiées par Microsoft.) Ce document prend en charge les nœuds gérés Linux, macOS et Windows Server. Ce document effectue les actions correspondant à chaque plateforme. **Note** Patch Manager prend également en charge le document SSM `AWS-ApplyPatchBaseline` hérité. Toutefois, seule l'application de correctifs sur les nœuds gérés Windows est prise en charge par ce document. Nous vous recommandons vivement de privilégier l'utilisation d'`AWS-RunPatchBaseline` dans la mesure où celui-ci prend en charge l'application de correctifs sur les nœuds gérés Linux, macOS et Windows Server. La version 2.0.834.0 ou une version ultérieure de SSM Agent pour pouvoir utiliser le document `AWS-RunPatchBaseline`. ------ #### [ Windows Server ] Sur les nœuds Windows Server gérés, le `AWS-RunPatchBaseline` document télécharge et invoque un PowerShell module, qui télécharge à son tour un instantané de la ligne de base des correctifs qui s'applique au nœud géré. Cet instantané de référentiel de correctifs contient une liste des correctifs approuvés qui sont compilés en interrogeant le référentiel de correctifs sur un serveur Windows Server Update Services (WSUS). Cet instantané du référentiel de correctifs est transmis à l'API Windows Update qui contrôle le téléchargement et l'installation des correctifs approuvés selon les besoins. ------ #### [ Linux ] Sur les nœuds gérés Linux, le document `AWS-RunPatchBaseline` appelle un module Python qui, à son tour, télécharge un instantané du référentiel de correctifs qui s'applique au nœud géré. Cet instantané du référentiel de correctifs utilise les règles définies et les listes de correctifs approuvés et bloqués afin de piloter le gestionnaire de package approprié pour chaque type de nœud : + Les nœuds gérés Amazon Linux 2, Oracle Linux et RHEL 7 utilisent YUM. Pour les opérations YUM, Patch Manager nécessite `Python 2.6` ou une version ultérieure prise en charge (2.6 à 3.12). Amazon Linux 2023 utilise DNF. Pour les opérations DNF, Patch Manager nécessite une version prise en charge de `Python 2` ou `Python 3` (2.6 à 3.12). + Les nœuds gérés RHEL 8 utilisent DNF. Pour les opérations DNF, Patch Manager nécessite une version prise en charge de `Python 2` ou `Python 3` (2.6 à 3.12). (Aucune des versions n'est installée par défaut sur RHEL 8. Vous devez les installer manuellement.) + Les instances Debian Server et Ubuntu Server utilisent APT. Pour les opérations APT, Patch Manager nécessite une version prise en charge de `Python 3` (3.0 à 3.12). ------ #### [ macOS ] Sur les nœuds gérés macOS, le document `AWS-RunPatchBaseline` appelle un module Python qui, à son tour, télécharge un instantané du référentiel de correctifs qui s'applique au nœud. Ensuite, un sous-processus Python invoque le AWS Command Line Interface (AWS CLI) sur le nœud pour récupérer les informations d'installation et de mise à jour pour les gestionnaires de packages spécifiés et pour piloter le gestionnaire de packages approprié pour chaque package de mise à jour. ------ Chaque instantané est spécifique à un groupe de correctifs Compte AWS, à un système d'exploitation et à un identifiant de capture d'écran. L'instantané est délivré via une URL Amazon Simple Storage Service (Amazon S3) présignée, qui expire 24 heures après la création de l'instantané. Toutefois, après l'expiration de l'URL, si vous souhaitez appliquer le même contenu d'instantané à d'autres nœuds gérés, générez une nouvelle URL Amazon S3 présignée jusqu'à trois jours après la création de l'instantané. Pour ce faire, utilisez la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html). Une fois que toutes les mises à jour approuvées et applicables ont été installées, et que les redémarrages nécessaires ont été effectués, des informations relatives à la conformité des correctifs sont générées sur un nœud géré et transmises à Patch Manager. **Note** Si le paramètre `RebootOption` est défini sur `NoReboot` dans le document `AWS-RunPatchBaseline`, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour de plus amples informations, veuillez consulter [Nom du paramètre: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption). Pour plus d'informations sur l'affichage des données de conformité des correctifs, consultez [A propos de la conformité des correctifs](compliance-about.md#compliance-monitor-patch). ## Paramètres dans l’`AWS-RunPatchBaseline` `AWS-RunPatchBaseline` prend en charge six paramètres. Le paramètre `Operation` est obligatoire. Les paramètres `InstallOverrideList`, `BaselineOverride` et `RebootOption` sont facultatifs. `Snapshot-ID` est techniquement facultatif, mais nous vous recommandons de lui attribuer une valeur personnalisée lorsque vous exécutez `AWS-RunPatchBaseline`en dehors d'une fenêtre de maintenance, et de laisser Patch Manager fournir automatiquement la valeur personnalisée lorsque le document est exécuté dans le cadre d'une opération de fenêtre de maintenance. **Topics** + [Nom du paramètre: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation) + [Nom du paramètre: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id) + [Nom du paramètre: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id) + [Nom du paramètre: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) + [Nom du paramètre: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption) + [Nom du paramètre: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride) + [Nom du paramètre: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds) ### Nom du paramètre: `Operation` **Utilisation** : Obligatoire. **Options** : `Scan` \$1 `Install`. Analyser Lorsque vous sélectionnez l'option `Scan`, `AWS-RunPatchBaseline` détermine l'état de conformité du nœud géré en matière de correctifs et transmet cette information à Patch Manager. `Scan` n'invite pas à installer les mises à jour ou à redémarrer les nœuds gérés. Mais l'opération identifie les mises à jour manquantes qui sont approuvées et applicables au nœud. Installation Lorsque vous sélectionnez l'option `Install`, `AWS-RunPatchBaseline` tente d'installer les mises à jour approuvées et applicables qu'il manque sur le nœud géré. Les informations de conformité des correctifs générées dans le cadre d'une opération `Install` ne répertorient pas les mises à jour manquantes, mais peuvent signaler les mises à jour avec un état d'échec si l'installation de la mise à jour a échoué pour une raison ou pour une autre. Chaque fois qu'une mise à jour est installée sur un nœud géré, ce dernier est redémarré pour s'assurer que la mise à jour est non seulement installée, mais également active. (Exception : si le paramètre `RebootOption` est défini sur `NoReboot` dans le document `AWS-RunPatchBaseline`, le nœud géré n'est pas redémarré après l'exécution de Patch Manager. Pour plus d'informations, consultez [Nom du paramètre: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)). Si un correctif spécifié par les règles de référentiel est installé *avant* la mise à jour du nœud géré par Patch Manager, le système peut ne pas redémarrer comme prévu. Cela peut se produire lorsqu'un correctif est installé manuellement par un utilisateur ou installé automatiquement par un autre programme, tel que le package `unattended-upgrades` sur Ubuntu Server. ### Nom du paramètre: `AssociationId` **Utilisation** : Facultatif. `AssociationId` est l’ID d’une association existante dans State Manager, un outil d’ AWS Systems Manager. Il est utilisé par Patch Manager pour ajouter des données de conformité à une association spécifiée. Cette association est liée à une opération d'application de correctifs [définie dans une politique de correctifs dans Quick Setup](quick-setup-patch-manager.md). **Note** Avec le `AWS-RunPatchBaseline`, si une valeur `AssociationId` est fournie avec un remplacement du référentiel de la politique de correctifs, l'application des correctifs est effectuée en tant qu'opération `PatchPolicy` et la valeur `ExecutionType` indiquée dans `AWS:ComplianceItem` est également `PatchPolicy`. Si aucune valeur `AssociationId` n'est fournie, l'application des correctifs est effectuée en tant qu'opération `Command` et le rapport de valeur `ExecutionType` sur l'`AWS:ComplianceItem` soumis est également `Command`. Si vous n'avez pas encore d'association à utiliser, vous pouvez en créer une en exécutant la commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html). ### Nom du paramètre: `Snapshot ID` **Utilisation** : Facultatif. `Snapshot ID` est un ID unique (GUID) utilisé par Patch Manager pour s'assurer que les nœuds gérés d'un groupe auquel des correctifs ont été appliqués dans le cadre d'une opération individuelle disposent tous du même ensemble de correctifs approuvés. Bien que le paramètre soit défini comme facultatif, nous recommandons deux bonnes pratiques différentes : l'une si vous exécutez `AWS-RunPatchBaseline` dans une fenêtre de maintenance, l'autre si l'exécution a lieu hors d'une fenêtre de maintenance, comme décrit dans le tableau ci-dessous. **Bonnes pratiques `AWS-RunPatchBaseline`** | Mode | Bonne pratique | Détails | | --- | --- | --- | | Exécution de AWS-RunPatchBaseline à l'intérieur d'une fenêtre de maintenance | Ne fournissez pas d'ID d'instantané. Patch Manager le fournira pour vous. | Si vous utilisez une fenêtre de maintenance pour exécuter `AWS-RunPatchBaseline`, vous ne devriez pas fournir votre propre ID d'instantané généré. Dans ce scénario, Systems Manager fournit une valeur de GUID en fonction de l'ID d'exécution de la fenêtre de maintenance. Cela permet de garantir que l'ID correct est utilisé pour tous les appels de `AWS-RunPatchBaseline` dans cette fenêtre de maintenance. Si vous spécifiez une valeur dans ce scénario, notez que pendant plus de trois jours, l'instantané du référentiel de correctifs peut changer. Par la suite, un nouvel instantané est généré même si vous spécifiez le même ID après l'expiration de l'instantané. | | Exécution de AWS-RunPatchBaseline à l'extérieur d'une fenêtre de maintenance | Générez et spécifiez une valeur de GUID personnalisée pour l'ID d'instantané.¹ | Si vous n'avez pas recours à une fenêtre de maintenance pour exécuter `AWS-RunPatchBaseline`, nous vous recommandons de générer et de spécifier un ID d'instantané unique pour chaque référentiel de correctifs, en particulier si vous exécutez le document `AWS-RunPatchBaseline` sur plusieurs nœuds gérés au cours de la même opération. Dans ce cas de figure, si vous ne spécifiez pas d'ID, Systems Manager génère un ID d'instantané différent pour chacun des nœuds gérés auxquels la commande est envoyée. Cela peut entraîner la spécification de différents ensembles de correctifs parmi les nœuds gérés. Par exemple, si vous exécutez le document `AWS-RunPatchBaseline` directement via Run Command, un outil d’ AWS Systems Manager et que vous ciblez un groupe de 50 nœuds gérés. La spécification d'un ID d'instantané personnalisé entraîne la génération d'un instantané de référentiel unique qui permet d'évaluer et de corriger tous les nœuds, garantissant ainsi un état final cohérent. | | ¹ Vous pouvez utiliser n'importe quel outil capable de générer un GUID afin de générer une valeur pour le paramètre d'ID d'instantané. Par exemple, dans PowerShell, vous pouvez utiliser l'`New-Guid`applet de commande pour générer un GUID au format de. `12345699-9405-4f69-bc5e-9315aEXAMPLE` | ### Nom du paramètre: `InstallOverrideList` **Utilisation** : Facultatif. `InstallOverrideList` vous permet de spécifier une URL https ou une URL de type chemin Amazon S3 vers une liste de correctifs à installer. Cette liste d'installation de correctifs que vous conservez au format YAML remplace les correctifs spécifiés par le référentiel de correctifs par défaut actuelle. Cela vous confère un contrôle plus précis sur les correctifs installés sur vos nœuds gérés. **Important** Le nom de fichier `InstallOverrideList` ne peut pas contenir les caractères suivants : backtick (`), guillemet simple ('), guillemet double ("), et signe dollar (\$1). Le comportement de l’application des correctifs lors de l’utilisation du paramètre `InstallOverrideList` diffère entre les nœuds gérés Linux et macOS et les nœuds gérés par Windows Server. Sur les nœuds Linux et macOS, Patch Manager tente d’appliquer les correctifs inclus dans la liste de correctifs `InstallOverrideList` et présents dans tout référentiel activé sur le nœud, que les correctifs correspondent ou non aux règles de référentiel de correctifs. Sur les nœuds Windows Server, cependant, les correctifs de la liste de correctifs `InstallOverrideList` ne sont appliqués *que* s’ils correspondent également aux règles de référentiel de correctifs. Sachez que les rapports de conformité reflètent les états de correctif en fonction de ce qui est spécifié dans le référentiel de correctifs et non pas de ce que vous spécifiez dans une liste `InstallOverrideList` de correctifs. En d'autres termes, les opérations d'analyse ignorent le paramètre `InstallOverrideList`. Cela permet de garantir que les rapports de conformité reflètent constamment les états de correctif en fonction de la politique plutôt que de ce qui a été approuvé pour une opération spécifique d'application de correctifs. **Note** Lorsque vous appliquez des correctifs à un nœud qui utilise uniquement IPv6, assurez-vous que l'URL fournie est accessible depuis le nœud. Si l'option de SSM Agent configuration `UseDualStackEndpoint` est définie sur`true`, un client S3 à double pile est utilisé lorsqu'une URL S3 est fournie. Consultez [Tutoriel : Appliquer des correctifs à un serveur dans un environnement IPv6 uniquement](patch-manager-server-patching-iPv6-tutorial.md) pour plus d'informations sur la configuration de l'agent pour utiliser Dualstack. Pour obtenir une description de la façon dont vous pouvez utiliser le paramètre `InstallOverrideList` pour appliquer différents types de correctifs à un groupe cible, selon des calendriers de fenêtre de maintenance différents, tout en utilisant une ligne de base de correctifs unique, veuillez consulter [Exemple de scénario d'utilisation du InstallOverrideList paramètre dans `AWS-RunPatchBaseline` ou `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md). **Formats d'URL valides** **Note** Si votre fichier est stocké dans un compartiment accessible au public, vous pouvez spécifier un format d'URL https ou une URL de style chemin Amazon S3. Si votre fichier est stocké dans un compartiment privé, vous devez spécifier une URL de style chemin Amazon S3. + **Format des URL https** : ``` https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml ``` + **URL de style chemin Amazon S3** : ``` s3://amzn-s3-demo-bucket/my-windows-override-list.yaml ``` **Formats de contenu YAML valides** Les formats que vous utilisez pour spécifier les correctifs dans votre liste dépendent du système d'exploitation de votre nœud géré. Le format général, toutefois, est le suivant : ``` patches: - id: '{patch-d}' title: '{patch-title}' {additional-fields}:{values} ``` Vous pouvez fournir des champs supplémentaires dans votre fichier YAML, mais ils sont ignorés pendant les opérations d'application de correctifs. De plus, nous vous recommandons de vérifier que le format de votre fichier YAML est valide avant d'ajouter ou de mettre à jour la liste dans votre compartiment S3. Pour plus d'informations sur le format YAML, consultez [yaml.org](http://www.yaml.org). Pour les options de l'outil de validation, recherchez « validateurs de format yaml » sur le web. ------ #### [ Linux ] **id** Le champ **id** est obligatoire. Utilisez-le pour spécifier des correctifs à l'aide du nom du package et de l'architecture. Par exemple : `'dhclient.x86_64'`. Vous pouvez utiliser des caractères génériques dans l'ID pour indiquer plusieurs packages. Par exemple : `'dhcp*'` et `'dhcp*1.*'`. **Titre** Le champ **title (titre)** est facultatif mais, sur les systèmes Linux, il fournit des fonctionnalités de filtrage supplémentaires. Si vous utilisez le champ **title (titre)**, il doit contenir les informations de version de package dans l'un des formats suivants : YUM/SUSE Linux Enterprise Server (SLES) : ``` {name}.{architecture}:{epoch}:{version}-{release} ``` APT ``` {name}.{architecture}:{version} ``` Pour les titres de correctifs Linux, vous pouvez utiliser un ou plusieurs caractères génériques dans n'importe quelle position pour étendre le nombre de correspondances de package. Par exemple : `'*32:9.8.2-0.*.rc1.57.amzn1'`. Par exemple : + La version du package apt qui est actuellement installée sur votre nœud géré est la version 1.2.25, mais la version 1.2.27 est désormais disponible. + Vous ajoutez apt.amd64 version 1.2.27 à la liste des correctifs. Elle dépend de apt utils.amd64 version 1.2.27, mais apt-utils.amd64 version 1.2.25 est spécifié dans la liste. Dans ce cas, l'installation de la version 1.2.27 d'apt sera bloquée et signalée comme « Failed- NonCompliant ». ------ #### [ Windows Server ] **id** Le champ **id** est obligatoire. Utilisez-le pour spécifier des correctifs à l'aide de la base de connaissances Microsoft IDs (par exemple KB2736693) et du bulletin de sécurité Microsoft IDs (par exemple, MS17 -023). Tous les autres champs que vous voulez fournir dans une liste de correctifs pour Windows sont facultatifs et fournis à titre d'information uniquement. Vous pouvez utiliser des champs supplémentaires, tels que **title**, **classification**, **severity** ou autre, pour fournir des informations plus détaillées sur les correctifs spécifiés. ------ #### [ macOS ] **id** Le champ **id** est obligatoire. La valeur du champ **id** peut être fournie sous un format `{package-name}.{package-version}` ou un format \$1package\$1name\$1. ------ **Exemples de listes de correctifs** + **Amazon Linux 2** ``` patches: - id: 'kernel.x86_64' - id: 'bind*.x86_64' title: '39.11.4-26.P2.amzn2.5.2' id: 'glibc*' - id: 'dhclient*' title: '*4.2.5-58.amzn2' - id: 'dhcp*' title: '*4.2.5-77.amzn2' ``` + **Debian Server** ``` patches: - id: 'apparmor.amd64' title: '2.10.95-0ubuntu2.9' - id: 'cryptsetup.amd64' title: '*2:1.6.6-5ubuntu2.1' - id: 'cryptsetup-bin.*' title: '*2:1.6.6-5ubuntu2.1' - id: 'apt.amd64' title: '*1.2.27' - id: 'apt-utils.amd64' title: '*1.2.25' ``` + **macOS** ``` patches: - id: 'XProtectPlistConfigData' - id: 'MRTConfigData.1.61' - id: 'Command Line Tools for Xcode.11.5' - id: 'Gatekeeper Configuration Data' ``` + **Oracle Linux** ``` patches: - id: 'audit-libs.x86_64' title: '*2.8.5-4.el7' - id: 'curl.x86_64' title: '*.el7' - id: 'grub2.x86_64' title: 'grub2.x86_64:1:2.02-0.81.0.1.el7' - id: 'grub2.x86_64' title: 'grub2.x86_64:1:*-0.81.0.1.el7' ``` + **Red Hat Enterprise Linux (RHEL)** ``` patches: - id: 'NetworkManager.x86_64' title: '*1:1.10.2-14.el7_5' - id: 'NetworkManager-*.x86_64' title: '*1:1.10.2-14.el7_5' - id: 'audit.x86_64' title: '*0:2.8.1-3.el7' - id: 'dhclient.x86_64' title: '*.el7_5.1' - id: 'dhcp*.x86_64' title: '*12:5.2.5-68.el7' ``` + **SUSE Linux Enterprise Server (SLES)** ``` patches: - id: 'amazon-ssm-agent.x86_64' - id: 'binutils' title: '*0:2.26.1-9.12.1' - id: 'glibc*.x86_64' title: '*2.19*' - id: 'dhcp*' title: '0:4.3.3-9.1' - id: 'lib*' ``` + **Ubuntu Server ** ``` patches: - id: 'apparmor.amd64' title: '2.10.95-0ubuntu2.9' - id: 'cryptsetup.amd64' title: '*2:1.6.6-5ubuntu2.1' - id: 'cryptsetup-bin.*' title: '*2:1.6.6-5ubuntu2.1' - id: 'apt.amd64' title: '*1.2.27' - id: 'apt-utils.amd64' title: '*1.2.25' ``` + **Windows** ``` patches: - id: 'KB4284819' title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)' - id: 'KB4284833' - id: 'KB4284835' title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)' - id: 'KB4284880' - id: 'KB4338814' ``` ### Nom du paramètre: `RebootOption` **Utilisation** : Facultatif. **Options** : `RebootIfNeeded` \$1 `NoReboot` **Par défaut** : `RebootIfNeeded` **Avertissement** L'option par défaut est `RebootIfNeeded`. Veillez à sélectionner l'option qui correspond à votre cas d'utilisation. Par exemple, si vos nœuds gérés doivent redémarrer immédiatement pour finaliser un processus de configuration, sélectionnez `RebootIfNeeded`. Ou, si des nœuds gérés doivent rester disponibles jusqu'à une heure de redémarrage planifiée, sélectionnez `NoReboot`. **Important** Nous vous déconseillons de Patch Manager les utiliser pour appliquer des correctifs à des instances de cluster dans Amazon EMR (précédemment appelé Amazon MapReduce Elastic). Ne sélectionnez pas l'option `RebootIfNeeded` pour le paramètre `RebootOption`. (Cette option est disponible dans les documents SSM Command pour l'application de correctifs sur `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` et `AWS-RunPatchBaselineWithHooks`.) Les commandes sous-jacentes pour l'application de correctifs à l'aide de Patch Manager utilisent les commandes `yum` et `dnf`. Par conséquent, les opérations entraînent des incompatibilités en raison de la manière dont les packages sont installés. Pour plus d'informations sur les méthodes préférées de mise à jour logicielle sur les clusters Amazon EMR, veuillez consulter la rubrique [Utilisation de l'AMI par défaut pour Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) dans le *Guide de gestion Amazon EMR*. RebootIfNeeded Lorsque vous sélectionnez l'option `RebootIfNeeded`, le nœud géré est redémarré dans l'un des cas suivants : + Patch Manager a installé un ou plusieurs correctifs. Patch Manager n'évalue pas si un redémarrage est *requis* par le correctif. Le système est redémarré même si le correctif ne nécessite pas de redémarrage. + Patch Manager détecte un ou plusieurs correctifs à l'état `INSTALLED_PENDING_REBOOT` durant l'opération `Install`. Le statut `INSTALLED_PENDING_REBOOT` peut signifier que l’option `NoReboot` a été sélectionnée lors de la dernière exécution de l’opération `Install`, ou qu’un correctif a été installé en dehors de Patch Manager depuis le dernier redémarrage du nœud géré. Dans ces deux cas, le redémarrage des nœuds gérés permet de supprimer les packages mis à jour de la mémoire, et assure la cohérence du comportement d'application des correctifs et de redémarrage sur tous les systèmes d'exploitation. NoReboot Lorsque vous sélectionnez l'option `NoReboot`, Patch Manager ne redémarre pas le nœud géré même s'il y a installé des correctifs pendant l'opération `Install`. Cette option est utile si vous savez qu'il n'est pas nécessaire de redémarrer vos nœuds gérés après l'application de correctifs, ou si des applications ou des processus en cours d'exécution sur un nœud ne doivent pas être perturbés par un redémarrage suite à l'application de correctifs. Elle est également utile lorsque vous souhaitez bénéficier de plus de contrôle sur le timing des redémarrages des nœuds gérés, par exemple en utilisant une fenêtre de maintenance. Si vous sélectionnez l'option `NoReboot` et qu'un correctif est installé, l'état du correctif est attribué au correctif `InstalledPendingReboot`. Le nœud géré, quant à lui, est marqué comme `Non-Compliant`. Après un redémarrage et l'exécution d'une opération `Scan`, l'état du nœud géré est mis à jour et devient `Compliant`. L’option `NoReboot` empêche uniquement les redémarrages au niveau du système d’exploitation. Les redémarrages au niveau du service peuvent toujours avoir lieu dans le cadre du processus d’application des correctifs. Par exemple, lorsque Docker est mis à jour, les services dépendants, comme Amazon Elastic Container Service, peuvent redémarrer automatiquement même avec `NoReboot` activé. Si vos services essentiels ne doivent pas être interrompus, envisagez des mesures supplémentaires, comme la suppression temporaire des instances du service ou la planification de l’application de correctifs pendant des fenêtres de maintenance. **Fichier de suivi de l'installation des correctifs** : pour suivre l'installation des correctifs, en particulier ceux installés depuis le dernier redémarrage du système, Systems Manager gère un fichier sur le nœud géré. **Important** Ne supprimez pas ou ne modifiez pas le fichier de suivi. Si ce fichier est supprimé ou endommagé, le rapport de conformité des correctifs correspondant au nœud géré est inexact. Dans ce cas, redémarrez le nœud et lancez une opération d'analyse des correctifs pour restaurer le fichier. Ce fichier de suivi est stocké aux emplacements suivants sur vos nœuds gérés : + Systèmes d'exploitation Linux : + `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json` + `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json` + Système d'exploitation Windows Server : + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json` + `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json` ### Nom du paramètre: `BaselineOverride` **Utilisation** : Facultatif. Vous pouvez définir des préférences d'application de correctifs au moment de l'exécution en utilisant le paramètre `BaselineOverride`. Ce remplacement de référentiel est conservé en tant qu'objet JSON dans un compartiment S3. Il garantit que les opérations d'application de correctifs utilisent les référentiels correspondant au système d'exploitation hôte au lieu d'appliquer les règles du référentiel de correctifs par défaut **Important** Le nom de fichier `BaselineOverride` ne peut pas contenir les caractères suivants : backtick (`), guillemet simple ('), guillemet double ("), et signe dollar (\$1). Pour de plus amples informations sur l'utilisation du paramètre `BaselineOverride`, veuillez consulter [Utilisation du BaselineOverride paramètre](patch-manager-baselineoverride-parameter.md). ### Nom du paramètre: `StepTimeoutSeconds` **Utilisation** : Obligatoire. Nombre de secondes de 1 à 36000 (10 heures) accordées à l’exécution d’une commande avant qu’elle soit considérée comme ayant échoué.