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-RunPatchBaselineAssociation
Wie das AWS-RunPatchBaseline
-Dokument führt auch AWS-RunPatchBaselineAssociation
Patching-Operationen auf Instances für sicherheitsrelevante und andere Arten von Updates aus. Sie können das Dokument AWS-RunPatchBaselineAssociation
auch 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 Amazon Elastic Compute Cloud (AmazonEC2) -Instances für Linux, macOS, und Windows Server. In einer Hybrid- und Multi-Cloud-Umgebung werden keine EC2 Knoten unterstützt. Das Dokument führt die entsprechenden Aktionen für jede Plattform durch und ruft ein Python-Modul unter Linux auf und macOS Instanzen und ein PowerShell Modul auf Windows-Instanzen.
AWS-RunPatchBaselineAssociation
unterscheidet sich jedoch auf folgende Weise von AWS-RunPatchBaseline
:
-
AWS-RunPatchBaselineAssociation
ist hauptsächlich für die Verwendung mit vorgesehen State Manager Assoziationen, die erstellt wurden mit Quick Setup, eine Fähigkeit von AWS Systems Manager. Insbesondere, wenn Sie das verwenden Quick Setup Wenn Sie die Option Instanzen täglich nach fehlenden Patches scannen wählen, verwendet das System den Konfigurationstyp Host ManagementAWS-RunPatchBaselineAssociation
für den Vorgang.In den meisten Fällen sollten Sie jedoch beim Einrichten eigener Patching-Vorgänge AWS-RunPatchBaseline oder AWS-RunPatchBaselineWithHooks anstelle von
AWS-RunPatchBaselineAssociation
auswählen. -
Wenn Sie das
AWS-RunPatchBaselineAssociation
-Dokument verwenden, können Sie ein Tag-Schlüssel-Paar imBaselineTags
-Parameterfeld des Dokuments angeben. Wenn eine benutzerdefinierte Patch-Baseline in Ihrem AWS-Konto System diese Tags verwendet, Patch Manager, eine Funktion von AWS Systems Manager, verwendet diese markierte Baseline, wenn sie auf den Ziel-Instances ausgeführt wird, und nicht die aktuell angegebene „Standard“ -Patch-Baseline für den Betriebssystemtyp.Wichtig
Wenn Sie sich für die Verwendung
AWS-RunPatchBaselineAssociation
bei anderen Patch-Vorgängen als denen entscheiden, die mit Quick Setup, und wenn Sie den optionalenBaselineTags
Parameter verwenden möchten, müssen Sie einige zusätzliche Berechtigungen für das Instance-Profil für Amazon Elastic Compute Cloud (AmazonEC2) -Instances bereitstellen. Weitere Informationen finden Sie unter Parametername: BaselineTags.Die beiden folgenden Formate sind gültig für Ihre
BaselineTags
-Parameter:Key=
tag-key
,Values=tag-value
Key=
tag-key
,Values=tag-value1
,tag-value2
,tag-value3
-
Bei der
AWS-RunPatchBaselineAssociation
Ausführung werden die gesammelten Patch-Compliance-Daten mit demPutComplianceItems
API Befehl aufgezeichnet und nicht mit demPutInventory
Befehl, der von verwendet wirdAWS-RunPatchBaseline
. Dieser Unterschied bedeutet, dass die Patch-Compliance-Informationen gemäß einer bestimmten Zuordnung gespeichert und gemeldet werden. Patch-Compliance-Daten, die außerhalb dieser Zuordnung generiert wurden, werden nicht überschrieben. -
Die Patch-Compliance-Informationen, die nach der Ausführung von
AWS-RunPatchBaselineAssociation
gemeldet werden, geben an, ob eine Instance konform ist oder nicht. Es enthält keine Details auf Patch-Ebene, wie die Ausgabe des folgenden AWS Command Line Interface (AWS CLI) -Befehls zeigt. Der Befehl filtert aufAssociation
als Compliance-Typ:aws ssm list-compliance-items \ --resource-ids "i-02573cafcfEXAMPLE" \ --resource-types "ManagedInstance" \ --filters "Key=ComplianceType,Values=Association,Type=EQUAL" \ --region us-east-2
Das System gibt unter anderem folgende Informationen zurück
{ "ComplianceItems": [ { "Status": "NON_COMPLIANT", "Severity": "UNSPECIFIED", "Title": "MyPatchAssociation", "ResourceType": "ManagedInstance", "ResourceId": "i-02573cafcfEXAMPLE", "ComplianceType": "Association", "Details": { "DocumentName": "AWS-RunPatchBaselineAssociation", "PatchBaselineId": "pb-0c10e65780EXAMPLE", "DocumentVersion": "1" }, "ExecutionSummary": { "ExecutionTime": 1590698771.0 }, "Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE" } ] }
Wenn ein Tag-Schlüsselpaarwert als Parameter für das AWS-RunPatchBaselineAssociation
Dokument angegeben wurde, Patch Manager sucht nach einer benutzerdefinierten Patch-Baseline, die dem Betriebssystemtyp entspricht und mit demselben Tag-Schlüsselpaar gekennzeichnet wurde. Diese Suche ist nicht auf die aktuell angegebene Standard-Patch-Baseline oder die Baseline beschränkt, die einer Patch-Gruppe zugewiesen ist. Wenn keine Baseline mit den angegebenen Tags gefunden wird, Patch Manager als Nächstes sucht nach einer Patch-Gruppe, falls eine in dem ausgeführten Befehl angegeben wurdeAWS-RunPatchBaselineAssociation
. Wenn keine Patch-Gruppe gefunden wurde, Patch Manager greift auf die aktuelle Standard-Patch-Baseline für das Betriebssystemkonto zurück.
Wenn mehr als eine Patch-Baseline mit den im AWS-RunPatchBaselineAssociation
Dokument angegebenen Tags gefunden wird, Patch Manager gibt eine Fehlermeldung zurück, die angibt, dass nur eine Patch-Baseline mit diesem Schlüssel-Wert-Paar markiert werden kann, damit der Vorgang fortgesetzt werden kann.
Anmerkung
Auf Linux-Instances wird der entsprechende Paketmanager für jeden Instance-Typ verwendet, um Pakete zu installieren:
-
Amazon Linux 1, Amazon Linux 2, CentOS, Oracle Linux, und RHEL Instanzen verwendenYUM. Für YUM Operationen Patch Manager erfordert
Python 2.6
oder eine neuere unterstützte Version (2.6 - 3.10). -
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 Instanzen verwenden Zypper. Für Zypper-Operationen Patch Manager erfordert
Python 2.6
oder eine neuere unterstützte Version (2.6 - 3.10).
Nachdem der Scan abgeschlossen wurde oder alle genehmigten und zutreffenden Updates installiert und je nach Bedarf Neustarts durchgeführt wurden, werden Patch-Compliance-Informationen auf einer Instance generiert und wieder an den Patchmanager-Service gemeldet.
Anmerkung
Wenn der RebootOption
Parameter NoReboot
im AWS-RunPatchBaselineAssociation
Dokument auf gesetzt ist, wird die Instanz 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-RunPatchBaselineAssociation
parameters
AWS-RunPatchBaselineAssociation
unterstützt vier Parameter. Die Parameter Operation
und AssociationId
müssen angegeben werden. Die Parameter InstallOverrideList
, RebootOption
und BaselineTags
sind optional.
Parameter
Parametername: Operation
Nutzung: erforderlich.
Optionen: Scan
| Install
.
- Scan
-
Wenn Sie
Scan
diese Option auswählen,AWS-RunPatchBaselineAssociation
wird der Status der Patch-Konformität der Instanz ermittelt und diese Informationen an zurückgemeldet Patch Manager.Scan
fordert nicht zur Installation von Updates oder zum Neustarten von Instanzen auf. Stattdessen erkennt der Vorgang, wo für die Instance genehmigte und geeignete Updates fehlen. - Installieren
-
Bei Auswahl der Option
Install
versuchtAWS-RunPatchBaselineAssociation
, die genehmigten und geeigneten Updates zu installieren, die auf der Instance fehlen. Patch-Compliance-Informationen, die als Teil einesInstall
-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 einer Instance installiert wird, wird die Instance neu gestartet, um sicherzustellen, dass es installiert und aktiviert ist. (Ausnahme: Wenn derRebootOption
ParameterNoReboot
imAWS-RunPatchBaselineAssociation
Dokument auf gesetzt ist, wird die Instanz 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 die Instanz, 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: BaselineTags
Nutzung: optional.
BaselineTags
ist ein eindeutiges Tag-Schlüssel-Wert-Paar, das Sie auswählen und einer individuellen benutzerdefinierten Patch-Baseline zuweisen. Sie können einen oder mehrere Werte für diesen Parameter angeben. Beider der folgenden Formate sind gültig:
Key=
tag-key
,Values=tag-value
Key=
tag-key
,Values=tag-value1
,tag-value2
,tag-value3
Der BaselineTags
Wert wird verwendet von Patch Manager um sicherzustellen, dass eine Gruppe von Instanzen, die in einem einzigen Vorgang gepatcht werden, alle über exakt dieselben genehmigten Patches verfügen. Wenn der Patch-Vorgang ausgeführt wird, Patch Manager überprüft, ob eine Patch-Baseline für den Betriebssystemtyp mit demselben Schlüssel-Wert-Paar gekennzeichnet ist, für das Sie angegeben haben. BaselineTags
Wenn eine Übereinstimmung vorliegt, wird diese benutzerdefinierte Patch-Baseline verwendet. Wenn keine Übereinstimmung vorliegt, wird eine Patch-Baseline anhand einer beliebigen Patchgruppe identifiziert, die für die Patching-Operation angegeben wurde. Wenn keine vorhanden ist, wird die AWS verwaltete vordefinierte Patch-Baseline für dieses Betriebssystem verwendet.
Zusätzliche Berechtigungsanforderungen
Wenn Sie AWS-RunPatchBaselineAssociation
bei anderen Patchvorgängen als denen, die mit eingerichtet wurden, Quick Setup, und wenn Sie den optionalen BaselineTags
Parameter verwenden möchten, müssen Sie dem Instance-Profil für Amazon Elastic Compute Cloud (AmazonEC2) -Instances die folgenden Berechtigungen hinzufügen.
Anmerkung
Quick Setup und unterstützen AWS-RunPatchBaselineAssociation
keine lokalen Server und virtuelle Maschinen (VMs).
{ "Effect": "Allow", "Action": [ "ssm:DescribePatchBaselines", "tag:GetResources" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ssm:GetPatchBaseline", "ssm:DescribeEffectivePatchesForPatchBaseline" ], "Resource": "
patch-baseline-arn
" }
Ersetzen patch-baseline-arn
mit dem Amazon-Ressourcennamen (ARN) der Patch-Baseline, auf die Sie Zugriff gewähren möchten, im Formatarn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE
.
Parametername: AssociationId
Nutzung: erforderlich.
AssociationId
ist die ID einer bestehenden Assoziation in State Manager, eine Fähigkeit von AWS Systems Manager. Es wird verwendet von Patch Manager um einer bestimmten Zuordnung Konformitätsdaten hinzuzufügen. Diese Zuordnung bezieht sich auf einen Scan
Patch-Vorgang, der in einer Host Management-Konfiguration aktiviert wurde, die in erstellt wurde Quick Setup. Indem Sie die Patching-Ergebnisse als Zuordnungs-Compliance-Daten statt als Inventar-Compliance-Daten senden, werden bestehende Inventar-Compliance-Informationen für Ihre Instances weder nach einem Patchvorgang noch bei anderen Zuordnungen überschrieben. IDs Wenn Sie noch keine Zuordnung haben, die Sie verwenden möchten, können Sie eine erstellen, indem Sie den folgenden Befehl ausführen create-associationder Befehl. Beispielsweise:
Parametername: InstallOverrideList
Nutzung: optional.
Mit InstallOverrideList
geben Sie einen https URL - oder Amazon Simple Storage Service (Amazon S3) -Pfadstil URL zu einer Liste von zu installierenden Patches an. Diese Patch-Installationsliste, deren YAML Format Sie beibehalten, setzt die in der aktuellen Standard-Patch-Baseline angegebenen Patches außer Kraft. Dies bietet Ihnen eine differenziertere Kontrolle darüber, welche Patches auf Ihren Instances installiert sind.
Das Verhalten des Patch-Vorgangs bei Verwendung des InstallOverrideList
Parameters unterscheidet sich zwischen Linux und macOS verwaltete Knoten und Windows Server verwaltete Knoten. Unter Linux & macOS, Patch Manager versucht, in der InstallOverrideList
Patch-Liste enthaltene Patches anzuwenden, die in einem beliebigen Repository vorhanden sind, das auf dem Knoten aktiviert ist, unabhängig davon, ob die Patches den Patch-Baseline-Regeln entsprechen oder nicht. Ein Windows Server Knoten, Patches in der InstallOverrideList
Patch-Liste werden jedoch nur angewendet, wenn sie auch den Patch-Baseline-Regeln entsprechen.
Beachten Sie, dass Compliance-Berichte Patch-Status entsprechend den Angaben in der Patch-Baseline wiedergeben, nicht entsprechend Ihren Angaben in einer InstallOverrideList
-Liste von Patches. Mit anderen Worten: Scan-Operationen ignorieren den Parameter InstallOverrideList
. Auf diese Weise wird sichergestellt, dass Compliance-Berichte den Patch-Status konsistent entsprechend der Richtlinie wiedergeben und nicht danach, was für eine bestimmte Patching-Operation genehmigt wurde.
Gültige URL Formate
Anmerkung
Wenn Ihre Datei in einem öffentlich verfügbaren Bucket gespeichert ist, können Sie entweder ein URL HTTPS-Format oder ein Amazon S3 URL S3-Pfadformat angeben. Wenn Ihre Datei in einem privaten Bucket gespeichert ist, müssen Sie einen Amazon S3 URL S3-Pfadstil angeben.
-
Beispiel für das URLHTTPS-Format:
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
-
Beispiel im Pfadstil URL von Amazon S3:
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
Gültige Inhaltsformate YAML
Die Formate, die Sie verwenden, um Patches in Ihrer Liste anzugeben, hängen von dem Betriebssystem Ihrer Instance ab. Das allgemeine Format lautet jedoch folgendermaßen:
patches: - id: '{patch-d}' title: '{patch-title}' {
additional-fields
}:{values
}
Sie können zwar zusätzliche Felder in Ihrer YAML Datei angeben, diese werden jedoch bei Patch-Vorgängen ignoriert.
Darüber hinaus empfehlen wir, zu überprüfen, ob das Format Ihrer YAML Datei gültig ist, bevor Sie die Liste in Ihrem S3-Bucket hinzufügen oder aktualisieren. Weitere Informationen zum YAML Format finden Sie unter yaml.org
-
Microsoft Windows
id
Das Feld id ist ein Pflichtfeld. Verwenden Sie es, um Patches mithilfe von Microsoft Knowledge Base IDs (z. B.KB2736693) und Microsoft Security Bulletin IDs (z. B. MS17 -023) anzugeben.
Alle anderen Felder, die Sie in einer Patch-Liste für Windows bereitstellen möchten, sind optional und dienen nur zu Ihrer eigenen Information. Sie können zusätzlichen Felder verwenden, wie z. B. Titel, Klassifizierung, Schweregrad oder andere Angaben für detailliertere Informationen über die angegebenen Patches.
-
Linux
id
Das Feld id ist ein Pflichtfeld. Verwenden Sie es, um Patches mit Paketnamen und Architektur anzugeben. Beispiel:
'dhclient.x86_64'
. Sie können Platzhalter in der ID verwenden, um mehrere Pakete anzugeben. Zum Beispiel'dhcp*'
und'dhcp*1.*'
.Titel
Das Feld Titel ist optional, es bietet jedoch auf Linux-Systemen zusätzliche Filterfunktionen. Wenn Sie Titel verwenden, sollte er die Versionsinformationen des Pakets in einem der folgenden Formate enthalten:
YUM/SUSE Linux Enterprise Server (SLES):
{name}.{architecture}:{epoch}:{version}-{release}
APT
{name}.{architecture}:{version}
Für Linux-Patch-Titel können Sie einen oder mehrere Platzhalter in beliebigen Positionen verwenden, um die Anzahl der Paketzuordnungen zu erhöhen. Beispiel:
'*32:9.8.2-0.*.rc1.57.amzn1'
.Zum Beispiel:
-
apt-Paketversion 1.2.25 ist derzeit auf Ihrer Instance installiert, aber Version 1.2.27 ist jetzt verfügbar.
-
Fügen Sie die apt.amd64-Version 1.2.27 der Liste hinzu. Sie ist abhängig von apt utils.amd64 Version 1.2.27, aber apt-utils.amd64 Version 1.2.25 ist in der Liste angegeben.
In diesem Fall wird die Installation der APT-Version 1.2.27 blockiert und als „Fehlgeschlagen-“ gemeldet. NonCompliant
-
Andere Felder
Alle anderen Felder, die Sie in einer Patch-Liste für Linux bereitstellen möchten, sind optional und dienen nur zu Ihrer eigenen Information. Sie können zusätzlichen Felder verwenden, wie z. B. Klassifizierung, Schweregrad oder andere Angaben für detailliertere Informationen über die angegebenen Patches.
Patch-Beispiellisten
-
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'
-
APT
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'
-
Amazon Linux
patches: - id: 'kernel.x86_64' - id: 'bind*.x86_64' title: '32:9.8.2-0.62.rc1.57.amzn1' - id: 'glibc*' - id: 'dhclient*' title: '*12:4.1.1-53.P1.28.amzn1' - id: 'dhcp*' title: '*10:3.1.1-50.P1.26.amzn1'
-
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'
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 Instances beispielsweise sofort neu starten müssen, um einen Konfigurationsprozess abzuschließen, wählen Sie RebootIfNeeded
aus. Oder wenn Sie die Verfügbarkeit von Instances 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-RunPatchBaseline
AWS-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 die Instance 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 desInstall
Vorgangs einen oder mehrere Patches mit dem Status.Der
INSTALLED_PENDING_REBOOT
Status kann bedeuten, dass die Option ausgewähltNoReboot
wurde, als derInstall
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 Instances 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 eine Instanz nicht neu, auch wenn sie während desInstall
Vorgangs Patches installiert hat. Diese Option ist nützlich, wenn Sie wissen, dass für Ihre Instances nach dem Anwenden von Patches kein Neustart erforderlich ist oder Anwendungen bzw. Prozesse auf einer Instance ausgeführt werden, die nicht durch einen Neustart des Patches unterbrochen werden sollten. Sie ist auch nützlich, wenn Sie mehr Kontrolle über das Timing von Instance-Neustarts wünschen, z. B. durch die Verwendung eines Wartungsfensters.
Datei zum Nachverfolgen der Patch-Installation (Tracking-Datei): Um die Patch-Installation nachzuverfolgen, insbesondere von Patches, die seit dem letzten Neustart des Systems installiert wurden, erstellt Systems Manager eine Datei auf der verwalteten Instance.
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 die Instance ungenau. Starten Sie in diesem Fall die Instance neu und führen Sie einen Patch-Scan-Vorgang aus, um die Datei wiederherzustellen.
Diese Tracking-Datei wird an den folgenden Speicherorten auf Ihren verwalteten Instances 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
-