Fehlerbehebung für Patch Manager - AWS Systems Manager
Problem: Fehler „Invoke-PatchBaselineOperation : Zugriff verweigert“ oder Fehler „Datei kann nicht von S3 heruntergeladen werden“ für baseline_overrides.jsonProblem: Das Patchen schlägt fehl, ohne dass eine offensichtliche Ursache oder Fehlermeldung vorliegtProblem: Unerwartete Patch-Compliance-ErgebnisseFehler beim Ausführen von AWS-RunPatchBaseline unter LinuxFehler beim Ausführen von AWS-RunPatchBaseline unter Windows ServerKontaktaufnahme mit AWS Support

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

Verwenden Sie die folgenden Informationen, um Probleme mit Patch Manager einer Funktion von zu beheben 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 Instanzprofilen hinzufügen, die an Ihre Instanzen angehängt sind, nicht aktiviert, wie in der folgenden Abbildung dargestellt.

Das Kontrollkästchen Erforderliche IAM Richtlinien zu vorhandenen Instanzprofilen hinzufügen.

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 vorhandenen Instanzprofilen hinzufügen, die an Ihre Instanzen angehängt sind, nicht aktivieren, werden die IAM Richtlinien und Ressourcen-Tags, die für den Zugriff auf baseline_overrides.json den S3-Bucket erforderlich sind, nicht automatisch zu Ihren vorhandenen IAM Instanzprofilen und Servicerollen hinzugefügt.

Lösung 1: Löschen Sie die bestehende Patch-Richtlinienkonfiguration und erstellen Sie dann einen Ersatz. Achten Sie darauf, das Kontrollkästchen Erforderliche IAM Richtlinien zu vorhandenen Instanzprofilen hinzufügen, die an Ihre Instanzen angehängt sind, zu aktivieren. Diese Auswahl wendet die mit dieser Quick Setup Konfiguration erstellten IAM Richtlinien auf Knoten an, denen bereits ein Instanzprofil oder eine Dienstrolle 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 Instanzprofil und jeder IAM Servicerolle hinzu, die Sie mit verwendenQuick Setup. 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 inRun Command, eine Funktion von. 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 mit der 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.

Wenn Sie feststellen, dass widersprüchliche Patching-Operationen in diesem Szenario nicht die Ursache für den Ausfall waren, empfehlen wir Ihnen, sich an AWS Support zu wenden.

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:

  • Eine in Quick Setup konfigurierte Patch-Richtlinie

  • Eine in Quick Setup konfigurierte Host-Management-Option

  • Ein Wartungsfenster zum Ausführen eines Patch-Scans oder einer Install-Aufgabe

  • Eine On-Demand Patch now-Operation (Jetzt patchen)

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 Vermeiden von unbeabsichtigtem Überschreiben von Patch-Compliance-Daten.

Fehler beim Ausführen von AWS-RunPatchBaseline unter Linux

Themen

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 IDs werden. Wenn dies der Fall ist, ordnen Sie die Priorität neu an. Run Command ist eine Funktion von 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 eine Funktion von 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, Raspberry Pi OS oder Ubuntu Server installiert.

Lösung: Installieren Sie eine unterstützte Version von python3 (3.0–3.10) auf dem Server, die für verwaltete Debian Server-, Raspberry Pi OS- 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: Das Patchen schlägt fehl und es wird Patch Manager gemeldet, dass die Erweiterung „Server Name Indication“ für nicht TLS 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 es eine Warnung, dass die ältere Version von Python, die mit dem Betriebssystem ausgeliefert wird, die TLS Servernamenanzeige nicht unterstützt. Das Systems Manager Manager-Patch-Payload-Skript gibt diese Warnung aus, wenn eine Verbindung zu AWS APIs diesem Support 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:

  • Das yum-Cache ist beschädigt.

  • Ein Repository URL kann aufgrund von Netzwerkproblemen nicht erreicht werden.

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/2023 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: 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 GNU Privacy Guard-Schlüssel (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 die Meldung 'NoMoreMirrorsRepoError' wird 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 dabei den Wert für repo-name mit Ihrem 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:

  • Regel TCP 443 für ausgehende Nachrichten in der Sicherheitsgruppe.

  • Regel TCP 443 für ausgehenden Ausgang. NACL

  • Ingress TCP 1024-65535-Regel in. NACL

  • NAT/IGWin der Routentabelle, um Konnektivität zu einem S3-Endpunkt bereitzustellen. Wenn die Instance keinen Internetzugang hat, stellen Sie ihr Konnektivität mit dem S3-Endpunkt zur Verfügung. Fügen Sie dazu einen S3-Gateway-Endpunkt hinzu VPC und integrieren Sie ihn in die Routentabelle des verwalteten Knotens.

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:

  1. Prüfen Sie, welche Pakete betroffen sind und welche Probleme bei den einzelnen Paketen bestehen, indem Sie nacheinander die folgenden Befehle ausführen:

    sudo apt-get check
    sudo dpkg -C
    dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]

  2. Korrigieren Sie die fehlerhaften Pakete, indem Sie den folgenden Befehl ausführen:

    sudo dpkg --configure -a

  3. Wenn der vorherige Befehl das Problem nicht vollständig behoben hat, führen Sie den folgenden Befehl aus:

    sudo apt --fix-broken install

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:

  • Auf dem Betriebssystem sind mehrere widersprüchliche Repositorys konfiguriert.

  • Auf ein Remote-Repository URL kann aufgrund von Netzwerkproblemen nicht zugegriffen werden.

  • Im Repository wurde ein Paket für die falsche Architektur gefunden.

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 Hilfe bei der Fehlerbehebung zu erhalten.

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

Problem: Nicht übereinstimmende Produktfamilien/Produktpaare

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

  • Product Family (Produktfamilie): Office

    Produkt: Office 2016

Ursache: Wenn Sie versuchen, eine Patch-Baseline mit nicht übereinstimmender Produktfamilie/Produkt zu erstellen, wird eine Fehlermeldung angezeigt. Dies kann folgende Ursachen haben:

  • Sie haben eine gültige Kombination aus Produktfamilie und Produktpaar ausgewählt, dann jedoch die Auswahl der Produktfamilie entfernt.

  • Sie haben ein Produkt aus der Unterliste Obsolete or mismatched options (Veraltete oder nicht übereinstimmende Optionen) statt aus der Unterliste Available and matching options (Verfügbare und übereinstimmende Optionen) ausgewählt.

    Artikel in der Produktunterliste Veraltete oder nicht übereinstimmende Optionen wurden möglicherweise fälschlicherweise mit dem Befehl SDK oder AWS Command Line Interface ()AWS CLI eingegeben. create-patch-baseline Dadurch kann es zu einem Schreibfehler oder einer falschen Zuordnung eines Produkts zu einer Produktfamilie kommen. Ein Produkt kann auch in der Unterliste Obsolete or mismatched options (Veraltete oder nicht übereinstimmende Optionen) enthalten sein, wenn es für eine vorherige Patch-Baseline angegeben wurde, aber keine Patches für das Produkt von Microsoft verfügbar sind.

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.

Sie können die Produkte, für die Patches verfügbar sind, auch anzeigen, indem Sie den describe-patch-properties Befehl im AWS CLI oder dem Befehl verwenden. DescribePatchProperties API

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 den Windows Update-Katalog 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 könnte mit den Windows Update-Komponenten oder mit mangelnder Konnektivität zum Windows Update-Katalog oder zu Windows Server Update Services (WSUS) zusammenhängen.

Lösung: Stellen Sie sicher, dass der verwaltete Knoten über ein Internet-Gateway, NAT -Gateway oder eine NAT Instanz mit dem Microsoft Update-Katalog verbunden ist. Wenn Sie verwendenWSUS, stellen Sie sicher, dass der verwaltete Knoten mit dem WSUS Server in Ihrer Umgebung verbunden ist. 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 SSM Agent-Kommunikationen mit AWS -verwalteten S3-Buckets werden. Der Knoten muss über den Amazon S3 S3-Gateway-Endpunkt, NAT das Gateway oder das Internet-Gateway mit dem Amazon S3 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, indem Sie VPC Endpunkte für Systems Manager verwenden.

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.

  1. Öffnen Sie die AWS Systems Manager Konsole unter https://console.aws.amazon.com/systems-manager/.

  2. Wählen Sie im Navigationsbereich Run Command aus.

  3. Wählen Sie die Registerkarte Befehlsverlauf und dann den Befehl aus, dessen Baseline Sie überprüfen möchten.

  4. Wählen Sie den verwalteten Knoten aus, dem Patches fehlen.

  5. Wählen Sie Schritt 1 – Ausgabe aus und finden Sie den BaselineId-Wert.

  6. Aktivieren Sie die zugewiesene Patch-Baseline-Konfiguration, d. h. Betriebssystem, Produktname, Klassifizierung und Schweregrad für die Patch-Baseline.

  7. Rufen Sie den Microsoft Update Catalog auf.

  8. Suchen Sie im Artikel der Microsoft Knowledge Base IDs (KB) (z. B.KB3216916).

  9. Stellen Sie sicher, dass der Wert unter Product (Produkt) dem Ihres verwalteten Knotens entspricht, und wählen Sie den entsprechenden Title (Titel) aus. Ein neues Fenser Details aktualisieren wird geöffnet.

  10. Auf der Registerkarte „Übersicht“ müssen die Klassifizierung und der MSRCSchweregrad mit der Patch-Baseline-Konfiguration übereinstimmen, die Sie zuvor gefunden haben.

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.

  1. Rufen Sie den Microsoft Update Catalog auf.

  2. Suchen Sie im Artikel der Microsoft Knowledge Base IDs (KB) (z. B.KB3216916).

  3. Stellen Sie sicher, dass der Wert unter Product (Produkt) dem Ihres verwalteten Knotens entspricht, und wählen Sie den entsprechenden Title (Titel) aus. Ein neues Fenser Details aktualisieren wird geöffnet.

  4. Gehen Sie zur Registerkarte Paketdetails. Suchen Sie nach einem Eintrag unter dem Header Dieses Update wurde durch die folgenden Updates ersetzt:.

Ursache 3: Derselbe Patch hat möglicherweise unterschiedliche KB-Nummern, da die Online-Updates 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 nicht unter verfügbar istWSUS, 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.

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- AWS Support -Plan haben, können Sie unter AWS Support einen technischen Supportfall erstellen.

Sammeln Sie die folgenden Gegenstände AWS Support, bevor Sie Kontakt aufnehmen:

  • SSMAgentenprotokolle

  • Run Command-Befehls-ID, Wartungsfenster-ID oder Automatisierungsausführungs-ID

  • Sammeln Sie für von Windows Server verwaltete Knoten auch Folgendes:

    • %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs, wie auf der Windows-Registerkarte von Wie Patches installiert werden beschrieben

    • Windows Update-Protokolle: Für Windows Server 2012 R2 und älter verwenden Sie %windir%/WindowsUpdate.log. Führen Sie für Windows Server 2016 und neuere Versionen zuerst den PowerShell Befehl aus, Get-WindowsUpdateLogbevor Sie %windir%/WindowsUpdate.log

  • Sammeln Sie für Linux-verwaltete Knoten auch Folgendes:

    • Der Inhalt des Verzeichnisses /var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux