AWS Systems ManagerChange Managersteht neuen Kunden nicht mehr offen. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter Änderung der AWS Systems ManagerChange Manager Verfügbarkeit.

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.

Fehlerbehebung für Patch Manager

Im Folgenden finden Sie Informationen zur Behandlung von Problemen mit Patch Manager, einem Tool in AWS Systems Manager.

Problem: Fehler „Invoke-PatchBaselineOperation : Zugriff verweigert“ oder Fehler „Datei kann nicht von S3 heruntergeladen werden“ für baseline_overrides.json

Problem: Wenn die von Ihrer Patch-Richtlinie festgelegten Patching-Vorgänge ausgeführt werden, erhalten Sie eine Fehlermeldung ähnlich dem folgenden Beispiel.

Example error on Windows Server

----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff

Example error on Linux

[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.

Ursache: Sie haben in eine Patch-Richtlinie erstelltQuick Setup, und an einige Ihrer verwalteten Knoten war bereits ein Instanzprofil (für EC2 Instanzen) oder eine Servicerolle (für EC2 Nicht-Computer) angehängt.

Sie haben jedoch das Kontrollkästchen Erforderliche IAM-Richtlinien zu vorhandenen Instance-Profilen hinzufügen, die an Ihre Instances angehängt sind, nicht aktiviert, wie in der folgenden Abbildung dargestellt.

Wenn Sie eine Patch-Richtlinie erstellen, wird auch ein Amazon-S3-Bucket erstellt, in dem die baseline_overrides.json Konfigurationsdatei der Richtlinie gespeichert wird. Wenn Sie bei der Erstellung der Richtlinie das Kontrollkästchen Erforderliche IAM-Richtlinien zu bestehenden Instance-Profilen hinzufügen, die mit Ihren Instances verbunden sind, nicht aktivieren, werden die IAM-Richtlinien und Ressourcen-Tags, die für den Zugriff auf baseline_overrides.json im S3-Bucket erforderlich sind, nicht automatisch zu Ihren bestehenden IAM-Instance-Profilen und Servicerollen hinzugefügt.

Lösung 1: Löschen Sie die bestehende Patch-Richtlinienkonfiguration und erstellen Sie dann eine neue. Aktivieren Sie dabei das Kontrollkästchen Erforderliche IAM-Richtlinien zu bestehenden Instance-Profilen hinzufügen, die mit Ihren Instances verbunden sind. Diese Auswahl wendet die mit dieser Quick Setup-Konfiguration erstellten IAM-Richtlinien auf Knoten an, denen bereits ein Instance-Profil oder eine Servicerolle zugewiesen ist. (Quick Setup fügt standardmäßig die erforderlichen Richtlinien zu Instances und Knoten hinzu, die noch nicht über Instance-Profile oder Servicerollen verfügen.) Weitere Informationen finden Sie unter Automatisieren von unternehmensweitem Patching mithilfe einer Quick Setup-Patch-Richtlinie.

Lösung 2: Fügen Sie die erforderlichen Berechtigungen und Tags manuell zu jedem IAM-Instance-Profil und jeder IAM-Servicerolle hinzu, die Sie mit Quick Setup verwenden. Detaillierte Anweisungen finden Sie unter Berechtigungen für den S3-Bucket mit der Patch-Richtlinie.

Problem: Das Patchen schlägt fehl, ohne dass eine offensichtliche Ursache oder Fehlermeldung vorliegt

Problem: Ein Patch-Vorgang schlägt fehl, ohne dass eine Fehlermeldung zurückgegeben wird.

Mögliche Ursache: Wenn mehr als ein Aufruf von AWS-RunPatchBaseline gleichzeitig erfolgt, können sie miteinander in Konflikt geraten, sodass Patch-Aufgaben fehlschlagen. Dies wird möglicherweise nicht in den Patchprotokollen angegeben.

Um zu überprüfen, ob sich gleichzeitige Patch-Vorgänge möglicherweise gegenseitig unterbrochen haben, überprüfen Sie den Befehlsverlauf in Run Command, einem Tool in AWS Systems Manager. Prüfen Sie bei einem verwalteten Knoten mit einem Patching-Fehler, ob mehrere Vorgänge innerhalb von 2 Minuten nacheinander versucht haben, die Maschine zu patchen. Dieses Szenario kann manchmal zu einem Fehler führen.

Sie können die AWS Command Line Interface (AWS CLI) auch verwenden, um mithilfe des folgenden Befehls nach gleichzeitigen Patchversuchen zu suchen. Ersetzen Sie den Wert für node-id durch die ID für Ihren verwalteten Knoten.

aws ssm list-commands \
    --filter "key=DocumentName,value=AWS-RunPatchBaseline" \
    --query 'Commands[*].{CommandId:CommandId,RequestedDateTime:RequestedDateTime,Status:Status}' \
    --instance-id node-id \
    --output table

Lösung: Wenn Sie feststellen, dass das Patching aufgrund konkurrierender Patching-Operationen auf demselben verwalteten Knoten fehlgeschlagen ist, passen Sie Ihre Patching-Konfigurationen an, damit dies nicht noch einmal geschieht. Wenn zum Beispiel zwei Wartungsfenster sich überschneidende Patching-Zeiten angeben, entfernen oder ändern Sie eines davon. Wenn in einem Wartungsfenster eine Patching-Operation angegeben ist, in einer Patch-Richtlinie jedoch eine andere für dieselbe Zeit angegeben ist, sollten Sie die Aufgabe aus dem Wartungsfenster entfernen.

Mögliche Ursache: Beim Patchen verwalteter Knoten kann die Ausführung des Dokuments unterbrochen und als fehlgeschlagen markiert werden, obwohl Patches erfolgreich installiert wurden. Dies kann der Fall sein, wenn das System während des Patchvorgangs einen unerwarteten Neustart einleitet (z. B. um Firmware-Updates oder Funktionen wie) anzuwenden. SecureBoot Der SSM-Agent kann den Status der Dokumentausführung bei externen Neustarts nicht beibehalten und wieder aufnehmen, was dazu führt, dass die Ausführung als fehlgeschlagen gemeldet wird.

Lösung: Um den Status der Patch-Installation nach einer fehlgeschlagenen Ausführung zu überprüfen, führen Sie einen Scan Patch-Vorgang aus und überprüfen Sie anschließend die Patch-Kompatibilitätsdaten in Patch Manager, um den aktuellen Konformitätsstatus zu beurteilen.

Wenn Sie feststellen, dass widersprüchliche Patchvorgänge oder externe Neustarts in diesem Szenario nicht die Ursache für den Fehler waren, empfehlen wir Ihnen, sich an uns zu wenden. AWS -Support

Problem: Unerwartete Patch-Compliance-Ergebnisse

Problem: Bei der Überprüfung der nach einem Scan-Vorgang generierten Details zur Patching-Compliance enthalten die Ergebnisse Informationen, die nicht die in Ihrer Patch-Baseline festgelegten Regeln widerspiegeln. Beispielsweise wird eine Ausnahme, die Sie der Liste Rejected patches (Abgelehnte Patches) in einer Patch-Baseline hinzugefügt haben, als Missing aufgeführt. Oder als Important klassifizierte Patches werden als fehlend aufgeführt, obwohl Ihre Patch-Baseline nur Critical-Patches angibt.

Ursache: Patch Manager unterstützt derzeit mehrere Methoden zum Ausführen von Scan-Operationen:

Wenn eine Scan-Operation ausgeführt wird, überschreibt dies die Compliance-Details aus dem letzten Scan. Wenn Sie mehr als eine Methode zum Ausführen einer Scan-Operation eingerichtet haben und diese unterschiedliche Patch-Baselines mit unterschiedlichen Regeln verwenden, führt dies zu unterschiedlichen Patch-Compliance-Ergebnissen.

Lösung: Um unerwartete Patch-Compliance-Ergebnisse zu vermeiden, empfehlen wir, jeweils nur eine Methode zum Ausführen der Patch Manager Scan-Operation zu verwenden. Weitere Informationen finden Sie unter Identifizieren der Ausführung, die Patch-Compliance-Daten erstellt hat.

Fehler beim Ausführen von AWS-RunPatchBaseline unter Linux

Problem: Fehler 'No such file or directory'

Problem: Wenn Sie AWS-RunPatchBaseline ausführen, schlägt das Patchen mit einem der folgenden Fehler fehl.

IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'

Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155

Unable to load and extract the content of payload, abort.failed to run commands: exit status 152

Ursache 1: Zwei Befehle zum Ausführen von AWS-RunPatchBaseline wurden gleichzeitig auf demselben verwalteten Knoten ausgeführt. Dies erzeugt eine Race-Bedingung, die in der temporären file patch-baseline-operations* nicht richtig erstellt oder auf die nicht richtig zugegriffen wird.

Ursache 2: Unzureichender Speicherplatz verbleibt im /var-Verzeichnis.

Lösung 1: Stellen Sie sicher, dass kein Wartungsfenster zwei oder mehr Run Command Aufgaben enthält, die AWS-RunPatchBaseline mit derselben Prioritätsstufe und auf demselben Ziel ausgeführt werden. IDs Wenn dies der Fall ist, ordnen Sie die Priorität neu an. Run Commandist ein Tool in AWS Systems Manager.

Lösung 2: Stellen Sie sicher, dass jeweils nur ein Wartungsfenster Run Command-Aufgaben ausführt, die AWS-RunPatchBaseline auf denselben Zielen und nach demselben Zeitplan verwenden. Ändern Sie in diesem Fall den Zeitplan.

Lösung 3: Stellen Sie sicher, dass nur eine State Manager-Zuordnung AWS-RunPatchBaseline nach demselben Zeitplan ausführt und die gleichen verwalteten Knoten anvisiert. State Manager ist ein Tool in AWS Systems Manager.

Lösung 4: Machen Sie genügend Speicherplatz im /var-Verzeichnis für die Update-Pakete. frei

Problem: Fehler 'another process has acquired yum lock'

Problem: Wenn Sie AWS-RunPatchBaseline ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.

12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.

Ursache: Das AWS-RunPatchBaseline-Dokument wurde auf einem verwalteten Knoten ausgeführt, in dem es bereits in einer anderen Operation ausgeführt wird und den yum-Paketmanager-Prozess erhalten hat.

Lösung: Stellen Sie sicher, dass keine State Manager-Zuordnung, Aufgaben im Wartungsfenster oder andere Konfigurationen, die AWS-RunPatchBaselinenach einem Zeitplan ausführen, ungefähr zur gleichen Zeit denselben verwalteten Knoten als Ziel haben.

Problem: Fehler 'Permission denied / failed to run commands'

Problem: Wenn Sie AWS-RunPatchBaseline ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.

sh: 
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126

Ursache: /var/lib/amazon/ könnte mit noexec-Berechtigungen gemountet sein. Dies ist ein Problem, weil SSM Agent Payload-Skripte auf /var/lib/amazon/ssm herunterlädt und sie von diesem Speicherort ausführt.

Lösung: Stellen Sie sicher, dass Sie exklusive Partitionen für /var/log/amazon und /var/lib/amazon konfiguriert haben und sind mit exec-Berechtigungen gemountet sind.

Problem: Fehler 'Unable to download payload'

Problem: Wenn Sie AWS-RunPatchBaseline ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.

Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156

Ursache: Der verwaltete Knoten verfügt nicht über die erforderlichen Berechtigungen für den Zugriff auf den angegebenen Amazon Simple Storage Service (Amazon S3)-Bucket.

Lösung: Aktualisieren Sie Ihre Netzwerkkonfiguration so, dass S3-Endpunkte erreichbar sind. Weitere Informationen finden Sie unter den Informationen zum erforderlichen Zugriff auf S3-Buckets für Patch Manager in SSM Agent-Kommunikationen mit AWS -verwalteten S3-Buckets.

Problem: Fehler 'unsupported package manager and python version combination'

Problem: Wenn Sie AWS-RunPatchBaseline ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.

An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1

Ursache: Eine unterstützte Version von Python3 ist nicht auf der Instance Debian Server oder Ubuntu Server installiert.

Lösung: Installieren Sie eine unterstützte Version von python3 (3.0–3.12) auf dem Server, die für verwaltete Debian Server- und Ubuntu Server-Knoten erforderlich ist.

Problem: Patch Manager wendet keine Regeln an, die zum Ausschließen bestimmter Pakete angegeben sind

Problem: Sie haben versucht, bestimmte Pakete auszuschließen, indem Sie sie in der /etc/yum.conf-Datei im Format exclude=package-name angeben, aber sie werden nicht während der Patch Manager-Operation Install ausgeschlossen.

Ursache: Patch Manager enthält keine Ausschlüsse, die in der /etc/yum.conf-Datei angegeben sind.

Lösung: Um bestimmte Pakete auszuschließen, erstellen Sie eine benutzerdefinierte Patch-Baseline und eine Regel, um die Pakete auszuschließen, die nicht installiert werden sollen.

Problem: Patching schlägt fehl und Patch Manager meldet, dass die Erweiterung „Servername Indication“ für TLS nicht verfügbar ist

Problem: Der Patchvorgang gibt die folgende Meldung aus.

/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369: 
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS 
certificate, which can cause validation failures. You can upgrade to a newer version of Python 
to solve this. 
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings

Ursache: Diese Meldung zeigt keinen Fehler an. Stattdessen ist dies eine Warnung, dass die ältere Version von Python, die mit dem Betriebssystem vertrieben wird, TLS Server Name Indication nicht unterstützt. Das Systems Manager Manager-Patch-Payload-Skript gibt diese Warnung aus, wenn eine Verbindung zu AWS APIs diesem unterstützenden SNI hergestellt wird.

Lösung: Um Patching-Fehler zu beheben, wenn diese Meldung gemeldet wird, überprüfen Sie den Inhalt der stdout- und stderr-Dateien. Wenn Sie die Patch-Baseline nicht so konfiguriert haben, dass diese Dateien in einem S3-Bucket oder in Amazon CloudWatch Logs gespeichert werden, können Sie die Dateien am folgenden Speicherort auf Ihrem verwalteten Linux-Node finden.

/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux

Problem: Patch Manager meldet 'No more mirrors to try'

Problem: Der Patchvorgang gibt die folgende Meldung aus.

[Errno 256] No more mirrors to try.

Ursache: Die auf dem verwalteten Knoten konfigurierten Repositorys funktionieren nicht richtig. Mögliche Gründe hierfür sind:

Lösung: Patch Manager verwendet den Standard-Paketmanager des verwalteten Knoten, um die Patching-Operation durchzuführen. Überprüfen Sie, ob Repositorys richtig konfiguriert sind und funktionieren.

Problem: Patching schlägt fehl mit 'Error code returned from curl is 23'

Problem: Eine Patching-Operation, die AWS-RunPatchBaseline verwendet, schlägt mit einer Fehlermeldung ähnlich der folgenden fehl:

05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23

Ursache: Das auf Ihren Systemen verwendete Curl-Tool verfügt nicht über die erforderlichen Rechte, um in das Dateisystem zu schreiben. Dies kann vorkommen, wenn das Standard-Curl-Tool des Paketmanagers durch eine andere Version ersetzt wurde, beispielsweise durch eine, die mit snap installiert wurde.

Lösung: Wenn die vom Paketmanager bereitgestellte curl-Version deinstalliert wurde, während eine andere Version installiert wurde, installieren Sie sie erneut.

Wenn Sie mehrere curl-Versionen installiert halten müssen, stellen Sie sicher, dass sich die mit dem Paketmanager verknüpfte Version im ersten in der PATH-Variable aufgeführten Verzeichnis befindet. Sie können dies überprüfen, indem Sie den Befehl echo $PATH ausführen, um die aktuelle Reihenfolge der Verzeichnisse zu sehen, die auf Ihrem System auf ausführbare Dateien überprüft werden.

Problem: Patching schlägt mit der Meldung 'Error unpacking rpm package...' fehl

Problem: Ein Patch-Vorgang schlägt mit einem Fehler ähnlich dem folgenden fehl:

Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1

Ursache 1: Wenn ein bestimmtes Paket in mehreren Paket-Installationsprogrammen vorhanden ist, z. B. sowohl in pip als auch in yum oder dnf, kann es bei der Verwendung des Standard-Paketmanagers zu Konflikten kommen.

Ein häufiges Beispiel ist das urllib3-Paket, das sich in pip, yum und dnf befindet.

Ursache 2: Das python-urllib3-Paket ist beschädigt. Dies kann passieren, wenn die Paketdateien von pip installiert oder aktualisiert wurden, nachdem das rpm-Paket zuvor von yum oder dnf installiert wurde.

Lösung: Entfernen Sie das python-urllib3-Paket aus Pip, indem Sie den Befehl sudo pip uninstall urllib3 ausführen, und behalten Sie das Paket nur im Standard-Paketmanager (yum oder dnf) bei.

Problem: Patching schlägt fehl mit 'Fehler auf Serviceseite beim Hochladen des Inventars'

Problem: Beim Ausführen des AWS-RunPatchBaseline-Dokuments erhalten Sie die folgende Fehlermeldung:

Encounter service side error when uploading the inventory

Ursache: Zwei Befehle zum Ausführen von AWS-RunPatchBaseline wurden gleichzeitig auf demselben verwalteten Knoten ausgeführt. Dies führt zu einer Race-Bedingung, wenn der Boto3-Client während Patch-Vorgängen initialisiert wird.

Lösung: Stellen Sie sicher, dass keine State Manager-Zuordnung, Aufgaben im Wartungsfenster oder andere Konfigurationen, die AWS-RunPatchBaselinenach einem Zeitplan ausführen, ungefähr zur gleichen Zeit denselben verwalteten Knoten als Ziel haben.

Problem: Das Patchen schlägt fehl und die Meldung „Beim Herunterladen von Paketen sind Fehler aufgetreten“ wird angezeigt

Problem: Beim Patchen erhalten Sie eine Fehlermeldung, die der folgenden ähnelt:

YumDownloadError: [u'Errors were encountered while downloading 
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12] 
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5] 
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64: 
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64: 
[Errno 5] [Errno 12] Cannot allocate memory',

Ursache: Dieser Fehler kann auftreten, wenn auf einem verwalteten Knoten nicht genügend Speicher verfügbar ist.

Lösung: Konfigurieren Sie den Swap-Speicher oder aktualisieren Sie die Instance auf einen anderen Typ, um die Speicherunterstützung zu erhöhen. Starten Sie dann einen neuen Patch-Vorgang.

Problem: Patching schlägt fehl mit der Meldung 'Die folgenden Signaturen konnten nicht verifiziert werden, da der öffentliche Schlüssel nicht verfügbar ist'

Problem: Das Patchen schlägt bei Ubuntu Server mit einer Fehlermeldung ähnlich der folgenden fehl:

02/17/2022 21:08:43 root [ERROR]: W:GPG error: 
http://repo.mysql.com/apt/ubuntu  bionic InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic

Ursache: Der Schlüssel für GNU Privacy Guard (GPG) ist abgelaufen oder fehlt.

Lösung: Aktualisieren Sie den GPG-Schlüssel, oder fügen Sie den Schlüssel erneut hinzu.

Anhand des zuvor gezeigten Fehlers sehen wir zum Beispiel, dass der 467B942D3A79BD29-Schlüssel fehlt und hinzugefügt werden muss. Führen Sie dazu einen der folgenden Befehle aus:

sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29

Oder, um alle Schlüssel zu aktualisieren, führen Sie den folgenden Befehl aus:

sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys

Wenn der Fehler danach weiterhin auftritt, empfehlen wir, das Problem an die Organisation zu melden, die das Repository verwaltet. Bis ein Fix verfügbar ist, können Sie die /etc/apt/sources.list-Datei so bearbeiten, dass das Repository während des Patchvorgangs ausgelassen wird.

Öffnen Sie dazu die sources.list-Datei zur Bearbeitung, suchen Sie die Zeile für das Repository und fügen Sie am Anfang der Zeile ein #-Zeichen ein, um sie auszukommentieren. Speichern und schließen Sie dann die Datei.

Problem: Das Patchen schlägt fehl und es wird eine Meldung 'NoMoreMirrorsRepoError' angezeigt

Problem: Sie erhalten eine Fehlermeldung ähnlich der folgenden:

NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.

Ursache: Im Quell-Repository ist ein Fehler aufgetreten.

Lösung: Wir empfehlen, das Problem der Organisation zu melden, die das Repository verwaltet. Bis der Fehler behoben ist, können Sie das Repository auf Betriebssystemebene deaktivieren. Führen Sie dazu den folgenden Befehl aus und ersetzen Sie den Wert für repo-name durch Ihren Repository-Namen:

yum-config-manager --disable repo-name

Im Folgenden sehen Sie ein Beispiel.

yum-config-manager --disable pgdg94

Nachdem Sie diesen Befehl ausgeführt haben, führen Sie einen weiteren Patch-Vorgang aus.

Problem: Das Patchen schlägt mit der Meldung „Payload kann nicht heruntergeladen werden“ fehl

Problem: Sie erhalten eine Fehlermeldung ähnlich der folgenden:

Unable to download payload: 
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed  to run commands: exit status 156

Ursache: Die Konfiguration des verwalteten Knotens ist fehlerhaft oder unvollständig.

Lösung: Versichern Sie sich, dass der verwaltete Knoten wie folgt konfiguriert ist:

Problem: Das Patchen schlägt fehl und es wird die Meldung „Installationsfehler: dpkg: Fehler:dpkg-Frontend ist durch einen anderen Prozess gesperrt“ angezeigt

Problem: Das Patchen schlägt mit einem Fehler ähnlich dem folgenden fehl:

install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed

Ursache: Der Paketmanager führt bereits einen anderen Prozess auf einem verwalteten Knoten auf Betriebssystemebene aus. Wenn der Abschluss dieses anderen Prozesses viel Zeit in Anspruch nimmt, kann es bei der Patch-Operation von Patch Manager zu einem Timeout kommen und ein Fehler auftreten.

Lösung: Führen Sie nach Abschluss des anderen Prozesses, der den Paketmanager verwendet, einen neuen Patchvorgang aus.

Problem: Das Patchen auf Ubuntu Server schlägt fehl und es wird der Fehler „dpkg wurde unterbrochen“ angezeigt

Problem: Auf Ubuntu Server schlägt das Patchen mit einem Fehler ähnlich dem folgenden fehl:

E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.

Ursache: Ein oder mehrere Pakete sind falsch konfiguriert.

Lösung: Führen Sie die folgenden Schritte aus:

Problem: Das Paketmanager-Dienstprogramm kann eine Paketabhängigkeit nicht auflösen

Problem: Der native Paketmanager auf dem verwalteten Knoten kann eine Paketabhängigkeit nicht auflösen und das Patchen schlägt fehl. Das folgende Beispiel für eine Fehlermeldung weist auf diese Art von Fehler auf einem Betriebssystem hin, das yum als Paketmanager verwendet.

09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1, 
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3', 
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']

Ursache: Patch Manager verwendet auf Linux-Betriebssystemen den systemeigenen Paketmanager auf der Maschine, um Patch-Operationen wie yum, dnf, apt und zypper auszuführen. Die Anwendungen erkennen, installieren, aktualisieren oder entfernen abhängige Pakete bei Bedarf automatisch. Einige Bedingungen können jedoch dazu führen, dass der Paketmanager einen Abhängigkeitsvorgang nicht abschließen kann, wie zum Beispiel:

Lösung: Das Patchen kann aufgrund eines Abhängigkeitsproblems aus einer Vielzahl von Gründen fehlschlagen. Wir empfehlen Ihnen daher, sich an uns AWS -Support zu wenden, um Ihnen bei der Problembehebung behilflich zu sein.

Problem: Fehler bei der Abhängigkeit von Zypper-Paketsperren auf verwalteten SLES-Knoten

Problem: Wenn Sie AWS-RunPatchBaseline mit dem Install-Vorgang auf SUSE Linux Enterprise Server-Instances ausführen, schlägt das Patchen fehl und es treten Fehler bei der Abhängigkeitsprüfung auf, die mit Paketsperren zusammenhängen. Sie könnten Fehlermeldungen ähnlich der folgenden erhalten:

Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
  uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
 Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
 Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
 Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/c] (c): c

In diesem Beispiel ist das Paket mock-pkg-standalone gesperrt, was Sie überprüfen könnten, indem Sie sudo zypper locks ausführen und in der Ausgabe nach diesem Paketnamen suchen.

Oder Sie sehen möglicherweise Protokolleinträge, die auf Fehlschläge bei der Abhängigkeitsprüfung hinweisen:

Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')

Ursache: Dieser Fehler tritt auf, wenn Zypper-Paketsperren die Installation oder Aktualisierung von Paketen aufgrund von Abhängigkeitskonflikten verhindern. Paketsperren können aus verschiedenen Gründen vorhanden sein:

Lösung: Gehen Sie je nach Ursache folgendermaßen vor, um Probleme mit der Zypper-Paketsperre zu beheben:

Schritt 1: Identifizieren gesperrter Pakete

Verbinden Sie sich mit Ihrem verwalteten SLES-Knoten und führen Sie den folgenden Befehl aus, um alle derzeit gesperrten Pakete aufzulisten:

sudo zypper locks

Schritt 2: Ermitteln der Quelle der Sperren

Schritt 3: Entfernen von Sperren nach Notwendigkeit

Mit diesem Befehl können Sie bestimmte Paketsperren entfernen:

sudo zypper removelock package-name

Um alle Paketsperren zu entfernen (mit Vorsicht verwenden), führen Sie folgenden Befehl aus:

sudo zypper cleanlocks

Schritt 4: Aktualisieren Ihrer Patch-Baseline (falls zutreffend)

Wenn die Sperren durch abgelehnte Patches in Ihrer Patch-Baseline verursacht wurden:

Schritt 5: Wiederholen des Patch-Vorgangs

Nachdem Sie die problematischen Sperren entfernt und gegebenenfalls Ihre Patch-Baseline aktualisiert haben, führen Sie das AWS-RunPatchBaseline-Dokument erneut aus.

Prävention: Vermeiden Sie zukünftige Zypper-Sperrkonflikte wie folgt:

Fehler beim Ausführen von AWS-RunPatchBaseline unter Windows Server

Problem: Nicht übereinstimmende Produktpaare family/product

Problem: Wenn Sie eine Patch-Baseline in der Systems Manager-Konsole erstellen, geben Sie eine Produktfamilie und ein Produkt an. Beispiel:

Ursache: Wenn Sie versuchen, eine Patch-Baseline mit einem nicht übereinstimmenden family/product Produktpaar zu erstellen, wird eine Fehlermeldung angezeigt. Dies kann folgende Ursachen haben:

Lösung: Um dieses Problem in der Konsole zu vermeiden, wählen Sie immer Optionen aus den Unterlisten Currently available options (Derzeit verfügbare Optionen) aus.

Um diejenigen Produkte anzuzeigen, für die Patches verfügbar sind, können Sie auch den Befehl describe-patch-properties in der AWS CLI oder den API-Befehl DescribePatchProperties verwenden.

Problem: AWS-RunPatchBaseline-Ausgabe gibt einen HRESULT (Windows Server) zurück

Problem: Sie haben eine Fehlermeldung wie die folgende erhalten.

----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when 
attempting to search Windows Update.
Exception Level 1:
 Error Message: Exception from HRESULT: 0x80240437
 Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295

Ursache: Diese Ausgabe weist darauf hin, dass das systemeigene Windows Update die Patchvorgänge nicht ausführen APIs konnte.

Lösung: Überprüfen Sie den HResult-Code in den folgenden Themen auf microsoft.com, um Schritte zur Fehlerbehebung zum Beheben des Fehlers zu ermitteln:

Problem: Der verwaltete Knoten hat keinen Zugriff auf Windows Update Catalog oder WSUS

Problem: Sie haben eine Fehlermeldung wie die folgende erhalten.

Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.

Extracting PatchBaselineOperations zip file contents to temporary folder.

Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.

Successfully downloaded and installed the PatchBaselineOperations PowerShell module.

Patch Summary for

PatchGroup :

BaselineId :

Baseline : null

SnapshotId :

RebootOption : RebootIfNeeded

OwnerInformation :

OperationType : Scan

OperationStartTime : 1970-01-01T00:00:00.0000000Z

OperationEndTime : 1970-01-01T00:00:00.0000000Z

InstalledCount : -1

InstalledRejectedCount : -1

InstalledPendingRebootCount : -1

InstalledOtherCount : -1

FailedCount : -1

MissingCount : -1

NotApplicableCount : -1

UnreportedNotApplicableCount : -1

EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169

----------ERROR-------

Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.

Exception Level 1:

Error Message: Exception from HRESULT: 0x80072EE2

Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)

at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String

searchCriteria)

At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58

e3\PatchWindows\_script.ps1:230 char:13

+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv

oke-PatchBaselineOperation], Exception

+ FullyQualifiedErrorId : Exception Level 1:

Error Message: Exception Details: An error occurred when attempting to search Windows Update.

Exception Level 1:

Error Message: Exception from HRESULT: 0x80072EE2

Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)

at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc

---Error truncated----

Ursache: Dieser Fehler kann mit den Windows Update-Komponenten oder einer fehlenden Konnektivität zum Windows Update Catalog oder Windows Server Update Services (WSUS) zusammenhängen.

Lösung: Bestätigen Sie, dass der verwaltete Knoten über ein Internet-Gateway, ein NAT-Gateway oder eine NAT-Instance eine Verbindung zum Microsoft Update Catalog hergestellt hat. Wenn Sie WSUS verwenden, bestätigen Sie, dass der verwaltete Knoten eine Verbindung zum WSUS-Server in Ihrer Umgebung hat. Wenn Konnektivität für das beabsichtigte Ziel verfügbar ist, überprüfen Sie die Microsoft-Dokumentation auf andere mögliche Ursachen für HResult 0x80072EE2. Dies kann auf ein Problem auf Betriebssystemebene hinweisen.

Problem: PatchBaselineOperations PowerShell Das Modul kann nicht heruntergeladen werden

Problem: Sie haben eine Fehlermeldung wie die folgende erhalten.

Preparing to download PatchBaselineOperations PowerShell module from S3.
                    
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------

C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\

PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server

+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException

+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1

failed to run commands: exit status 4294967295

Lösung: Überprüfen Sie die Konnektivität und Berechtigungen für Amazon Simple Storage Service (Amazon S3) des verwalteten Knoten. Für die Rolle des verwalteten Knotens AWS Identity and Access Management (IAM) müssen die unter angegebenen Mindestberechtigungen verwendet werden. SSM Agent-Kommunikationen mit AWS -verwalteten S3-Buckets Der Knoten muss über den Amazon-S3-Gateway-Endpunkt, das NAT-Gateway oder das Internet-Gateway mit dem Amazon-S3-Endpunkt kommunizieren. Weitere Informationen zu den VPC-Endpunktanforderungen für AWS Systems Manager SSM Agent (SSM Agent) finden Sie unterVerbessern Sie die Sicherheit von EC2 Instanzen mithilfe von VPC-Endpunkten für Systems Manager.

Problem: fehlende Patches

Problem: AWS-RunPatchbaseline wurde erfolgreich abgeschlossen, aber es fehlen einige Patches.

Nachfolgend finden Sie einige häufige Auslöser und deren Lösungen.

Ursache 1: Die Baseline ist nicht effektiv.

Lösung 1: Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies die Ursache ist.

Ursache 2: Das Patch wurde ersetzt.

Lösung 2: Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies der Fall ist.

Ursache 3: Dasselbe Patch hat möglicherweise unterschiedliche KB-Nummern, da die WSUS- und Windows-Online-Updates von Microsoft als unabhängige Versionskanäle behandelt werden.

Lösung 3: Überprüfen Sie die Berechtigung des Patches. Wenn das Paket unter WSUS nicht verfügbar ist, installieren Sie OS Build 14393.3115. Wenn das Paket für alle Betriebssystem-Builds verfügbar ist, installieren Sie OS-Builds 18362.1256 und 18363.1256.

Verwenden von AWS -Support -Automation-Runbooks

AWS -Support stellt zwei Automation-Runbooks zur Verfügung, mit denen Sie bestimmte Probleme im Zusammenhang mit Patches beheben können.

Kontaktaufnahme mit AWS -Support

Wenn Sie Problembehandlungs-Lösungen in diesem Abschnitt oder im bschnitt zu Systems-Manager-Problemen in AWS re:Post nicht finden können und einen Developer-, Business- oder Enterprise- Support -Plan haben, können Sie unter AWS -Support einen technischen Supportfall erstellen.

Sammeln Sie die folgenden Artikel Support, bevor Sie Kontakt aufnehmen: