Unterschiede beim Patchvorgang zwischen Linux und Windows Server - AWS Systems Manager

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.

Unterschiede beim Patchvorgang zwischen Linux und Windows Server

In diesem Thema werden wichtige Unterschiede zwischen Linux- und Windows Server-Patching in Patch Manager, einem Tool in AWS Systems Manager, beschrieben.

Anmerkung

Um von Linux verwaltete Knoten zu patchen, müssen Ihre Knoten SSM Agent der Version 2.0.834.0 oder höher ausführen.

Wenn Systems Manager neue Tools hinzugefügt oder Aktualisierungen an den vorhandenen Tools vorgenommen werden, wird eine neue Version von SSM Agent veröffentlicht. Wenn Sie nicht die neueste Version des Agenten verwenden, kann dies dazu führen, dass der verwaltete Knoten nicht die zahlreichen Tools und Features von Systems Manager verwendet. Aus diesem Grund empfehlen wir, dass Sie den Prozess zur Aktualisierung von SSM Agent in Ihren Maschinen automatisieren. Weitere Informationen finden Sie unter Automatisieren von Updates für SSM Agent. Abonnieren Sie die SSM Agent-Versionshinweise-Seite in GitHub, um Benachrichtigungen über SSM Agent-Updates zu erhalten.

Unterschied 1: Patch-Bewertung

Patch Manager verwendet auf Windows-verwalteten Knoten und Linux-verwalteten Knoten jeweils andere Prozesse, um zu ermitteln, welche Patches installiert sein sollten.

Linux

Bei Linux-Patches wertet Systems Manager auf jedem verwalteten Knoten einzeln zuerst die Patch-Baseline-Regeln und dann die Liste der genehmigten bzw. abgelehnten Patches aus. Systems Manager muss die Patches auf jedem Knoten gesondert auswerten, weil der Service die Liste der bekannten Patches und Updates von den Repositorys abruft, die auf dem verwalteten Knoten konfiguriert sind.

Windows

Für Windows-Patches wertet Systems Manager direkt im Service zuerst die Patch-Baseline-Regeln und dann die Liste der genehmigten bzw. abgelehnten Patches aus. Dies ist möglich, weil Windows-Patches aus einem einzigen Repository (Windows Update) abgerufen werden.

Unterschied 2: Not Applicable-Patches

Aufgrund der großen Anzahl der verfügbaren Pakete für Linux-Betriebssysteme, meldet Systems Manager keine Details zu Patches mit dem Status Nicht anwendbar. Ein Not Applicable-Patch ist beispielsweise ein Patch für Apache-Software, wenn auf der Instance Apache nicht installiert ist. Systems Manager meldet zwar die Anzahl der Not Applicable Patches in der Zusammenfassung, aber wenn Sie die DescribeInstancePatchesAPI für einen verwalteten Knoten aufrufen, enthalten die zurückgegebenen Daten keine Patches mit dem Status vonNot Applicable. Dieses Verhalten unterscheidet sich von dem bei Windows.

Unterschied 3: Unterstützung von SSM-Dokumenten

Das Systems-Manager-Dokument (SSM-Dokument) AWS-ApplyPatchBaseline unterstützt keine Linux-verwalteten Knoten. Um Patch-Baselines auf Linux-, macOS- und Windows Server-verwalteten Knoten anzuwenden, wird das SSM-Dokument AWS-RunPatchBaseline empfohlen. Weitere Informationen erhalten Sie unter SSM-Befehlsdokumente zum Patchen verwalteter Knoten und SSM-Befehlsdokument zum Patchen: AWS-RunPatchBaseline.

Unterschied 4: Anwendungspatches

Der Hauptfokus von Patch Manager liegt auf dem Patchen von Betriebssystemen. Sie können mit Patch Manager jedoch auch Patches für bestimmte Anwendungen auf Ihren verwalteten Knoten anwenden.

Linux

Auf Linux-Betriebssystemen verwendet Patch Manager die konfigurierten Repositorys für Updates und unterscheidet dabei nicht zwischen Betriebssystem- und Anwendungs-Patches. Sie können mit Patch Manager festlegen, aus welchen Repositorys Updates abgerufen werden. Weitere Informationen finden Sie unter So geben Sie ein alternatives Patch-Quell-Repository an (Linux).

Windows

Auf von Windows Server verwaltete Knoten können Sie für Microsoft-Anwendungen wie Microsoft Word 2016 und Microsoft Exchange Server 2016 Genehmigungsregeln sowie die Patch-Ausnahmen Approved (Freigegeben) und Rejected (Abgelehnt) anwenden. Weitere Informationen finden Sie unter Arbeiten mit benutzerdefinierten Patch-Baselines.

Unterschied 5: Optionen für abgelehnte Patch-Listen in benutzerdefinierten Patch-Baselines

Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für eine Liste Abgelehnte Patches einen oder mehrere Patches angeben. Bei verwalteten Linux-Knoten können Sie auch festlegen, dass sie installiert werden dürfen, wenn es sich um Abhängigkeiten für einen anderen Patch handelt, der laut Baseline zulässig ist.

Windows Server unterstützt jedoch das Konzept der Patch-Abhängigkeiten nicht. Sie können einen Patch zur Liste der abgelehnten Patches in einer benutzerdefinierten Baseline für Windows Server hinzufügen. Das Ergebnis hängt jedoch davon ab, (1) ob der abgelehnte Patch bereits auf einem verwalteten Knoten installiert ist oder nicht, und (2) welche Option Sie für die Aktion Abgelehnte Patches wählen.

In der folgenden Tabelle finden Sie Einzelheiten zu den Optionen für abgelehnte Patches in Windows Server.

Status der installation Option: „Als Abhängigkeit zulassen“ Option: „Blockieren“
Der Patch ist bereits installiert Gemeldeter Status: INSTALLED_OTHER Gemeldeter Status: INSTALLED_REJECTED
Der Patch ist noch nicht installiert Patch übersprungen Patch übersprungen

Jeder von Microsoft veröffentlichte Patch für Windows Server enthält normalerweise alle Informationen, die für eine erfolgreiche Installation erforderlich sind. Gelegentlich kann jedoch ein Paket erforderlich sein, das Sie manuell installieren müssen. Patch Manager meldet keine Informationen zu diesen Voraussetzungen. Weitere Informationen finden Sie auf der Microsoft-Website unter Problembehandlung bei Windows Update.