SSMBefehlsdokument für das Patchen: AWS-RunPatchBaselineWithHooks - AWS Systems Manager
AWS-RunPatchBaselineWithHooks-BetriebsschritteAWS-RunPatchBaselineWithHooks parameters

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

SSMBefehlsdokument für das Patchen: AWS-RunPatchBaselineWithHooks

AWS Systems Manager unterstütztAWS-RunPatchBaselineWithHooks, ein Systems Manager Manager-Dokument (SSMDokument) für Patch Manager, eine Fähigkeit von AWS Systems Manager. In diesem SSM Dokument werden Patch-Operationen auf verwalteten Knoten sowohl für sicherheitsrelevante als auch für andere Arten von Updates durchgeführt.

AWS-RunPatchBaselineWithHooks unterscheidet sich auf folgende Weise von AWS-RunPatchBaseline:

  • Ein Wrapper-Dokument – AWS-RunPatchBaselineWithHooks ist ein Wrapper für AWS-RunPatchBaseline und setzt für einige seiner Operationen aufAWS-RunPatchBaseline.

  • Die Install-Operation – AWS-RunPatchBaselineWithHooks unterstützt Lebenszyklus-Hooks, die während dem Patchen von verwalteten Knoten an festgelegten Punkten ausgeführt werden. Da Patch-Installationen manchmal den Neustart von verwalteten Knoten erfordern, ist die Patch-Operation in zwei Ereignisse unterteilt, wobei insgesamt drei Hooks enthalten sind, die benutzerdefinierte Funktion unterstützen. Der erste Hook ist vor der Install with NoReboot-Operation. Der zweite Hook ist nach der Install with NoReboot-Operation. Der dritte Hook ist nach dem Neustart des verwalteten Knoten verfügbar.

  • Keine Unterstützung für benutzerdefinierte Patchlisten – AWS-RunPatchBaselineWithHooks unterstützt den InstallOverrideList-Parameter nicht.

  • SSM Agent Unterstützung — AWS-RunPatchBaselineWithHooks erfordert das SSM Agent 3.0.502 oder höher muss auf dem verwalteten Knoten für das Patchen installiert sein.

Wenn das Dokument ausgeführt wird, verwendet es die Patch-Baseline, die aktuell der „Standard“ für einen Betriebssystemtyp ist, wenn keine Patch-Gruppe angegeben ist. Andernfalls werden die Patch-Baselines verwendet, die der Patch-Gruppe zugeordnet sind. Informationen zu Patch-Gruppen finden Sie unter Patch-Gruppen.

Sie können das Dokument AWS-RunPatchBaselineWithHooks verwenden, um Patches sowohl für Betriebssysteme als auch für Anwendungen durchzuführen. (Am Windows Server, die Anwendungsunterstützung ist auf Updates für von Microsoft veröffentlichte Anwendungen beschränkt.)

Dieses Dokument unterstützt Linux und Windows Server verwaltete Knoten. Das Dokument führt die entsprechenden Aktionen für jede Plattform durch.

Anmerkung

AWS-RunPatchBaselineWithHookswird nicht unterstützt auf macOS.

Linux

Auf Linux-verwalteten Knoten ruft das Dokument AWS-RunPatchBaselineWithHooks ein Python-Modul auf, das wiederum einen entsprechenden Snapshot der Patch-Baseline für den verwalteten Knoten herunterlädt. Dieser Patch-Baseline-Snapshot verwendet die definierten Regeln und Listen der genehmigten und gesperrten Patches, um den entsprechenden Paketmanager für jeden Knoten-Typ anzutreiben:

  • Amazon Linux 1, Amazon Linux 2, CentOS, Oracle Linux, und RHEL 7 verwaltete Knoten verwendenYUM. Für YUM Operationen Patch Manager erfordert Python 2.6 oder eine neuere unterstützte Version (2.6 - 3.10).

  • RHEL Es werden 8 verwaltete Knoten verwendetDNF. Für DNF Operationen Patch Manager erfordert eine unterstützte Version von Python 2 oder Python 3 (2.6 - 3.10). (Keine der Versionen ist standardmäßig installiert auf RHEL 8. Sie müssen eine dieser Versionen manuell installieren.)

  • Debian Server, Raspberry Pi OS, und Ubuntu Server Instanzen verwendenAPT. Für APT Operationen Patch Manager erfordert eine unterstützte Version von Python 3 (3.0 - 3.10).

  • SUSE Linux Enterprise Server verwaltete Knoten verwenden Zypper. Für Zypper-Operationen Patch Manager erfordert Python 2.6 oder eine neuere unterstützte Version (2.6 - 3.10).

Windows Server

Ein Windows Server verwaltete Knoten, das AWS-RunPatchBaselineWithHooks Dokument lädt ein PowerShell Modul herunter und ruft es auf, das wiederum einen Snapshot der Patch-Baseline herunterlädt, die für den verwalteten Knoten gilt. Dieser Snapshot der Patch-Baseline enthält eine Liste der genehmigten Patches, die durch Abfragen der Patch-Baseline anhand eines Windows Server Update Services (WSUS) -Servers zusammengestellt wird. Diese Liste wird an das Windows Update weitergegebenAPI, das das Herunterladen und Installieren der genehmigten Patches entsprechend steuert.

Jeder Snapshot ist spezifisch für eine AWS-Konto Patchgruppe, ein Betriebssystem und eine Snapshot-ID. Der Snapshot wird über einen vorsignierten Amazon Simple Storage Service (Amazon S3) bereitgestelltURL, der 24 Stunden nach der Erstellung des Snapshots abläuft. Wenn Sie jedoch nach URL Ablauf derselben Snapshot-Inhalte auf andere verwaltete Knoten anwenden möchten, können Sie URL bis zu drei Tage nach der Erstellung des Snapshots ein neues vorsigniertes Amazon S3 generieren. Verwenden Sie dazu den get-deployable-patch-snapshot-for-instanceBefehl.

Nachdem alle genehmigten und anwendbaren Updates installiert wurden und gegebenenfalls Neustarts durchgeführt wurden, werden Informationen zur Patch-Konformität auf einem verwalteten Knoten generiert und an Patch Manager.

Anmerkung

Wenn der RebootOption Parameter NoReboot im AWS-RunPatchBaselineWithHooks Dokument auf eingestellt ist, wird der verwaltete Knoten danach nicht neu gestartet Patch Manager läuft. Weitere Informationen finden Sie unter Parametername: RebootOption.

Weitere Informationen zum Anzeigen von Patch-Compliance-Daten finden Sie unter Info zu Patch Compliance.

AWS-RunPatchBaselineWithHooks-Betriebsschritte

Wenn AWS-RunPatchBaselineWithHooks ausgeführt wird, werden die folgenden Schritte durchgeführt:

  1. Scan – Eine Scan-Operation mit AWS-RunPatchBaseline wird auf dem verwalteten Knoten ausgeführt und ein Compliance-Bericht wird generiert und hochgeladen.

  2. Überprüfen der lokalen Patch-Zustände – Ein Skript wird ausgeführt, um zu bestimmen, welche Schritte auf der Grundlage der ausgewählten Operation und dem Scan-Ergebnis aus Schritt 1 ausgeführt werden.

    1. Wenn die ausgewählte Operation Scan ist, wird die Operation als abgeschlossen markiert. Die Operation ist abgeschlossen.

    2. Wenn die gewählte Operation istInstall, Patch Manager wertet das Scan Ergebnis aus Schritt 1 aus, um zu bestimmen, was als Nächstes ausgeführt werden soll:

      1. Wenn keine fehlenden Patches erkannt werden und keine ausstehenden Neustarts erforderlich sind, fährt die Operation direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen.

      2. Wenn keine fehlenden Patches erkannt werden, aber ausstehende Neustarts erforderlich sind und die Neustartoption NoReboot ist, fährt die Operation direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen.

      3. Andernfalls fährt die Operation mit dem nächsten Schritt fort.

  3. Hook-Vorgang vor dem Patch — Das SSM Dokument, das Sie für den ersten Lifecycle-Hook bereitgestellt habenPreInstallHookDocName, wird auf dem verwalteten Knoten ausgeführt.

  4. Installation mit NoReboot — Auf dem verwalteten Knoten AWS-RunPatchBaseline wird ein Install Vorgang NoReboot mit der Neustartoption ausgeführt, und es wird ein Konformitätsbericht generiert und hochgeladen.

  5. Hook-Vorgang nach der Installation — Das SSM Dokument, das Sie für den zweiten Lifecycle-Hook bereitgestellt habenPostInstallHookDocName, wird auf dem verwalteten Knoten ausgeführt.

  6. Überprüfen des Neustarts – Ein Skript wird ausgeführt, um festzustellen, ob ein Neustart für den verwalteten Knoten erforderlich ist und welche Schritte ausgeführt werden sollen:

    1. Wenn die ausgewählte Neustartoption NoReboot ist, geht die Operation direkt zum letzten Schritt (Schritt 8) über, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen.

    2. Wenn die gewählte Neustartoption ist, RebootIfNeeded Patch Manager prüft anhand des in Schritt 4 gesammelten Inventars, ob noch ausstehende Neustarts erforderlich sind. Dies bedeutet, dass der Vorgang mit Schritt 7 fortgesetzt wird und der verwaltete Knoten in einem der folgenden Fälle neu gestartet wird:

      1. Patch Manager hat einen oder mehrere Patches installiert. (Patch Manager bewertet nicht, ob für den Patch ein Neustart erforderlich ist. Das System wird neu gestartet, auch wenn für den Patch kein Neustart erforderlich ist.)

      2. Patch Manager erkennt während des INSTALLED_PENDING_REBOOT Installationsvorgangs einen oder mehrere Patches mit dem Status. Der INSTALLED_PENDING_REBOOT Status kann bedeuten, dass die Option ausgewählt NoReboot wurde, als der Installationsvorgang das letzte Mal ausgeführt wurde, oder dass ein Patch außerhalb von installiert wurde Patch Manager seit dem letzten Neustart des verwalteten Knotens.

      Wenn keine Patches gefunden werden, die diese Kriterien erfüllen, ist der Patch-Vorgang für verwaltete Knoten abgeschlossen, und der Vorgang fährt direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen.

  7. Neustart und Bericht – Eine Installations-Operation mit der Neustart-Option RebootIfNeeded wird auf dem verwalteten Knoten unter Verwendung von AWS-RunPatchBaseline ausgeführt und ein Compliance-Bericht wird generiert und hochgeladen.

  8. Hook-Vorgang nach dem Neustart — Das SSM Dokument, das Sie für den dritten Lifecycle-Hook bereitgestellt habenOnExitHookDocName, wird auf dem verwalteten Knoten ausgeführt.

Bei einer Scan-Operation wird der Prozess der Ausführung des Dokuments beendet, wenn Schritt 1 fehlschlägt, und der Schritt wird als fehlgeschlagen gemeldet, obwohl nachfolgende Schritte als erfolgreich gemeldet werden.

Wenn bei einem Install-Vorgang einer der aws:runDocument-Schritte während des Vorgangs fehlschlagen, werden diese Schritte als fehlgeschlagen gemeldet, und der Vorgang fährt direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen. Dieser Schritt wird als fehlgeschlagen gemeldet, der letzte Schritt meldet den Status des Vorgangsergebnisses, und alle dazwischen liegenden Schritte werden als erfolgreich gemeldet.

AWS-RunPatchBaselineWithHooks parameters

AWS-RunPatchBaselineWithHooks unterstützt sechs Parameter.

Der Parameter Operation muss angegeben werden.

Die Parameter RebootOption, PreInstallHookDocName, PostInstallHookDocName und OnExitHookDocName sind optional.

Snapshot-ID ist eigentlich optional, wir empfehlen jedoch, einen benutzerdefinierten Wert dafür anzugeben, wenn Sie AWS-RunPatchBaselineWithHooks außerhalb eines Wartungsfensters ausführen. Lass Patch Manager gibt den Wert automatisch an, wenn das Dokument im Rahmen eines Wartungsfensters ausgeführt wird.

Parametername: Operation

Nutzung: erforderlich.

Optionen: Scan | Install.

Scan

Wenn Sie Scan diese Option wählen, ermittelt das System anhand des AWS-RunPatchBaseline Dokuments den Status der Patch-Konformität des verwalteten Knotens und meldet diese Informationen an Patch Manager. Scanfordert nicht auf, Updates zu installieren oder verwaltete Knoten neu zu starten. Stattdessen erkennt die Operation, wo für den Knoten genehmigte und geeignete Updates fehlen.

Installieren

Bei Auswahl der Option Install versucht AWS-RunPatchBaselineWithHooks, die genehmigten und geeigneten Updates zu installieren, die auf dem verwalteten Knoten fehlen. Patch-Compliance-Informationen, die als Teil eines Install-Vorgangs generiert wurden, enthalten keine fehlenden Updates, melden allerdings möglicherweise Updates im Fehlerzustand, wenn die Installation des Updates aus einem beliebigen Grund nicht erfolgreich war. Immer wenn ein Update auf einem verwalteten Knoten installiert wird, wird der Knoten neu gestartet, um sicherzustellen, dass das Update installiert und aktiviert ist. (Ausnahme: Wenn der RebootOption Parameter NoReboot im AWS-RunPatchBaselineWithHooks Dokument auf gesetzt ist, wird der verwaltete Knoten danach nicht neu gestartet Patch Manager läuft. Weitere Informationen finden Sie unter Parametername: RebootOption.)

Anmerkung

Wenn zuvor ein in den Basisregeln festgelegter Patch installiert wurde Patch Manager aktualisiert den verwalteten Knoten, wird das System möglicherweise nicht wie erwartet neu gestartet. Dies kann passieren, wenn ein Patch manuell von einem Benutzer oder automatisch von einem anderen Programm installiert wird, z. B. dem unattended-upgrades Paket auf Ubuntu Server.

Parametername: Snapshot ID

Nutzung: optional.

Snapshot IDist eine eindeutige ID (GUID), die von verwendet wird Patch Manager um sicherzustellen, dass alle verwalteten Knoten, die in einem einzigen Vorgang gepatcht werden, über exakt dieselben genehmigten Patches verfügen. Auch wenn der Parameter als optional definiert ist, hängen unsere Empfehlungen für bewährte Methoden davon ab, ob Sie AWS-RunPatchBaselineWithHooks in einem Wartungsfenster, wie in der folgenden Tabelle beschrieben, ausführen.

Bewährte Methoden für AWS-RunPatchBaselineWithHooks
Mode Bewährte Methode Details
Ausführen von AWS-RunPatchBaselineWithHooks innerhalb eines Wartungsfensters Geben Sie keine Snapshot-ID an. Patch Manager wird es für Sie liefern.

Falls Sie ein Wartungsfenster zum Ausführen von AWS-RunPatchBaselineWithHooks verwenden, dürfen Sie Ihre eigene generierte Snapshot ID nicht angeben. In diesem Szenario stellt Systems Manager einen GUID Wert bereit, der auf der Ausführungs-ID des Wartungsfensters basiert. Auf diese Weise wird sichergestellt, dass eine richtige ID für alle Aufrufe von AWS-RunPatchBaselineWithHooks in diesem Wartungsfenster verwendet wird.

Wenn Sie einen Wert in diesem Szenario angeben, beachten Sie, dass der Snapshot der Patch-Baseline möglicherweise nicht länger als drei Tagen erhalten bleibt. Danach wird ein neuer Snapshot erstellt, auch wenn Sie dieselbe ID angeben, nachdem der Snapshot abgelaufen ist.

Ausführen von AWS-RunPatchBaselineWithHooks außerhalb eines Wartungsfensters Generieren Sie einen benutzerdefinierten GUID Wert für die Snapshot-ID und geben Sie ihn an.¹

Wenn Sie kein Wartungsfenster zum Ausführen von AWS-RunPatchBaselineWithHooks verwenden, empfehlen wir, dass Sie eine eindeutige Snapshot-ID für jede Patch-Baseline generieren und angeben, insbesondere wenn Sie das Dokument AWS-RunPatchBaselineWithHooks auf mehreren verwaltete Knoten in derselben Operation ausführen. Wenn Sie keine ID in diesem Szenario angeben, generiert Systems Manager eine andere Snapshot-ID für jeden verwalteten Knoten, an den der Befehl gesendet wird. Dies kann zu unterschiedlichen Sätzen von Patches führen, die auf den Knoten angegeben sind.

Nehmen wir zum Beispiel an, Sie führen das AWS-RunPatchBaselineWithHooks Dokument direkt durch Run Command, eine Fähigkeit von AWS Systems Manager und zielt auf eine Gruppe von 50 verwalteten Knoten ab. Das Angeben einer benutzerdefinierten Snapshot-ID führt zur Erstellung eines einzelnen Baseline-Snapshots, der verwendet wird, um alle verwaltete Knoten zu bewerten und zu patchen. Dadurch wird gewährleistet, dass sie letztendlich einen konsistenten Zustand aufweisen.

¹ Sie können jedes Tool verwenden, das einen generieren kannGUID, um einen Wert für den Snapshot-ID-Parameter zu generieren. Beispielsweise können Sie mit dem New-Guid Cmdlet einen GUID im Format von generieren. PowerShell 12345699-9405-4f69-bc5e-9315aEXAMPLE

Parametername: RebootOption

Nutzung: optional.

Optionen: RebootIfNeeded | NoReboot

Standardwert: RebootIfNeeded

Warnung

Die Standardoption ist RebootIfNeeded. Stellen Sie sicher, dass Sie die richtige Option für Ihren Anwendungsfall auswählen. Wenn Ihre verwalteten Knoten beispielsweise sofort neu gestartet werden müssen, um einen Konfigurationsprozess abzuschließen, wählen Sie RebootIfNeeded aus. Oder wenn Sie die Verfügbarkeit von verwalteten Knoten bis zu einer geplanten Neustartzeit beibehalten müssen, wählen Sie NoReboot aus.

Wichtig

Wir empfehlen nicht zu verwenden Patch Manager für das Patchen von Cluster-Instances in Amazon EMR (früher Amazon Elastic genannt MapReduce). Wählen Sie insbesondere nicht die Option RebootIfNeeded für den Parameter RebootOption aus. (Diese Option ist in den SSM Befehlsdokumenten für das Patchen AWS-RunPatchBaselineAWS-RunPatchBaselineAssociation, und AWS-RunPatchBaselineWithHooks verfügbar.)

Die zugrunde liegenden Befehle für das Patchen mit Patch Manager Verwendung yum und dnf Befehle. Daher führen die Operationen aufgrund der Art und Weise, wie Pakete installiert werden, zu Inkompatibilitäten. Informationen zu den bevorzugten Methoden für die Aktualisierung von Software auf EMR Amazon-Clustern finden Sie unter Verwenden der Standardeinstellung AMI für Amazon EMR im Amazon EMR Management Guide.

RebootIfNeeded

Wenn Sie die Option RebootIfNeeded auswählen, wird der verwaltete Knoten in einem der folgenden Fälle neu gestartet:

  • Patch Manager hat einen oder mehrere Patches installiert.

    Patch Manager bewertet nicht, ob für den Patch ein Neustart erforderlich ist. Das System wird neu gestartet, auch wenn der Patch keinen Neustart erfordert.

  • Patch Manager erkennt INSTALLED_PENDING_REBOOT während des Install Vorgangs einen oder mehrere Patches mit dem Status.

    Der INSTALLED_PENDING_REBOOT Status kann bedeuten, dass die Option ausgewählt NoReboot wurde, als der Install Vorgang das letzte Mal ausgeführt wurde, oder dass ein Patch außerhalb von installiert wurde Patch Manager seit dem letzten Neustart des verwalteten Knotens.

Durch den Neustart von verwalteten Knoten wird in diesen beiden Fällen sichergestellt, dass aktualisierte Pakete aus dem Speicher gelöscht werden und das Patch- und Neustartverhalten über alle Betriebssysteme hinweg konsistent bleibt.

NoReboot

Wenn Sie die Option wählen, NoReboot Patch Manager startet einen verwalteten Knoten nicht neu, auch wenn er während des Install Vorgangs Patches installiert hat. Diese Option ist nützlich, wenn Sie wissen, dass für Ihre verwalteten Knoten nach dem Anwenden von Patches kein Neustart erforderlich ist oder Anwendungen bzw. Prozesse auf einem Knoten ausgeführt werden, die nicht durch einen Neustart beim Patchen unterbrochen werden sollten. Sie ist auch nützlich, wenn Sie mehr Kontrolle über das Timing von Neustarts von verwalteten Knoten wünschen, z. B. durch die Verwendung eines Wartungsfensters.

Anmerkung

Wenn Sie die Option NoReboot auswählen und ein Patch installiert ist, wird dem Patch der Status InstalledPendingReboot zugewiesen. Der verwaltete Knoten selbst wird jedoch als Non-Compliant gekennzeichnet. Nach einem Neustart und Ausführung einer Scan-Operation wird der Knoten-Status in Compliant aktualisiert.

Datei zum Nachverfolgen der Patch-Installation: Um die Patch-Installation nachzuverfolgen, insbesondere von Patches, die seit dem letzten Neustart des Systems installiert wurden, erstellt Systems Manager eine Datei auf dem verwalteten Knoten.

Wichtig

Löschen oder ändern Sie die Tracking-Datei nicht. Wenn diese Datei gelöscht oder beschädigt wird, ist der Patch-Compliance-Bericht für den verwalteten Knoten ungenau. Starten Sie in diesem Fall den Knoten neu und führen Sie eine Patch-Scan-Operation aus, um die Datei wiederherzustellen.

Diese Tracking-Datei wird an den folgenden Speicherorten auf Ihren verwalteten Knoten gespeichert:

  • Linux-Betriebssysteme:

    • /var/log/amazon/ssm/patch-configuration/patch-states-configuration.json

    • /var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json

  • Windows Server Betriebssystem:

    • C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json

    • C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json

Parametername: PreInstallHookDocName

Nutzung: optional.

Standard: AWS-Noop.

Der für den PreInstallHookDocName Parameter bereitzustellende Wert ist der Name oder der Amazon-Ressourcenname (ARN) eines SSM Dokuments Ihrer Wahl. Sie können den Namen eines AWS verwalteten Dokuments oder den Namen ARN eines benutzerdefinierten SSM Dokuments angeben, das Sie erstellt haben oder das für Sie freigegeben wurde. (Für ein SSM Dokument, das von einem anderen für Sie freigegeben wurde AWS-Konto, müssen Sie die vollständige Ressource angebenARN, z. arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument B.)

Das von Ihnen angegebene SSM Dokument wird vor dem Install Vorgang ausgeführt und führt alle Aktionen aus, die von unterstützt werden SSM Agent, z. B. ein Shell-Skript zur Überprüfung des Anwendungszustands, bevor das Patchen auf dem verwalteten Knoten ausgeführt wird. (Eine Liste der Aktionen finden Sie unter Referenz für Befehlsdokument-Plug-ins). Der Standardname des SSM Dokuments istAWS-Noop, wodurch keine Operation auf dem verwalteten Knoten ausgeführt wird.

Informationen zum Erstellen eines benutzerdefinierten SSM Dokuments finden Sie unterSSMDokumentinhalte erstellen.

Parametername: PostInstallHookDocName

Nutzung: optional.

Standard: AWS-Noop.

Der für den PostInstallHookDocName Parameter bereitzustellende Wert ist der Name oder der Amazon-Ressourcenname (ARN) eines SSM Dokuments Ihrer Wahl. Sie können den Namen eines AWS verwalteten Dokuments oder den Namen ARN eines benutzerdefinierten SSM Dokuments angeben, das Sie erstellt haben oder das für Sie freigegeben wurde. (Für ein SSM Dokument, das von einem anderen für Sie freigegeben wurde AWS-Konto, müssen Sie die vollständige Ressource angebenARN, z. arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument B.)

Das von Ihnen angegebene SSM Dokument wird nach dem Install with NoReboot Vorgang ausgeführt und führt alle Aktionen aus, die von unterstützt werden SSM Agent, z. B. ein Shell-Skript zur Installation von Updates von Drittanbietern vor dem Neustart. (Eine Liste der Aktionen finden Sie unter Referenz für Befehlsdokument-Plug-ins). Der Standardname des SSM Dokuments lautetAWS-Noop, wodurch keine Operation auf dem verwalteten Knoten ausgeführt wird.

Informationen zum Erstellen eines benutzerdefinierten SSM Dokuments finden Sie unterSSMDokumentinhalte erstellen.

Parametername: OnExitHookDocName

Nutzung: optional.

Standard: AWS-Noop.

Der für den OnExitHookDocName Parameter bereitzustellende Wert ist der Name oder der Amazon-Ressourcenname (ARN) eines SSM Dokuments Ihrer Wahl. Sie können den Namen eines AWS verwalteten Dokuments oder den Namen ARN eines benutzerdefinierten SSM Dokuments angeben, das Sie erstellt haben oder das für Sie freigegeben wurde. (Für ein SSM Dokument, das von einem anderen für Sie freigegeben wurde AWS-Konto, müssen Sie die vollständige Ressource angebenARN, z. arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument B.)

Das von Ihnen angegebene SSM Dokument wird nach dem Neustart des verwalteten Knotens ausgeführt und führt alle Aktionen aus, die von unterstützt werden SSM Agent, z. B. ein Shell-Skript zur Überprüfung des Knotenzustands nach Abschluss des Patchvorgangs. (Eine Liste der Aktionen finden Sie unter Referenz für Befehlsdokument-Plug-ins). Der Standardname des SSM Dokuments lautetAWS-Noop, wodurch keine Operation auf dem verwalteten Knoten ausgeführt wird.

Informationen zum Erstellen eines benutzerdefinierten SSM Dokuments finden Sie unterSSMDokumentinhalte erstellen.