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

Dieses Thema beschreibt wichtige Unterschiede zwischen Linux und Windows Server einpatchen Patch Manager, ein Werkzeug rein AWS Systems Manager.

Anmerkung

Um verwaltete Linux-Knoten zu patchen, müssen Ihre Knoten laufen SSM Agent Version 2.0.834.0 oder höher.

Eine aktualisierte Version von SSM Agent wird immer dann veröffentlicht, wenn neue Tools zu Systems Manager hinzugefügt oder bestehende Tools aktualisiert werden. Wenn Sie nicht die neueste Version des Agenten verwenden, kann Ihr verwalteter Knoten verschiedene Systems Manager Manager-Tools und -Funktionen nicht verwenden. Aus diesem Grund empfehlen wir Ihnen, den Prozess der Aufbewahrung zu automatisieren SSM Agent auf Ihren Maschinen auf dem neuesten Stand. Weitere Informationen finden Sie unter Automatisieren von Updates für SSM Agent. Abonnieren Sie den SSM AgentSeite mit den Versionshinweisen auf GitHub um Benachrichtigungen zu erhalten über SSM Agent Aktualisierungen.

Unterschied 1: Patch-Bewertung

Patch Manager verwendet unterschiedliche Prozesse auf verwalteten Windows-Nodes und Linux-Managed Nodes, um zu evaluieren, welche Patches vorhanden 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 anzuwenden, macOS, und Windows Server Verwaltete Knoten, das empfohlene SSM-Dokument lautet. AWS-RunPatchBaseline 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 ist das Anwenden von Patches auf Betriebssysteme. Sie können jedoch auch Folgendes verwenden Patch Manager um Patches auf einige Anwendungen auf Ihren verwalteten Knoten anzuwenden.

Linux

Auf Linux-Betriebssystemen Patch Manager verwendet die konfigurierten Repositorys für Updates und unterscheidet nicht zwischen Betriebssystemen und Anwendungspatches. Sie können Folgendes verwenden … Patch Manager um zu definieren, aus welchen Repositorys Updates abgerufen werden sollen. Weitere Informationen finden Sie unter So geben Sie ein alternatives Patch-Quell-Repository an (Linux).

Windows

Ein Windows Server Mit verwalteten Knoten können Sie Genehmigungsregeln sowie Patch-Ausnahmen für genehmigte und abgelehnte Patches für von Microsoft veröffentlichte Anwendungen wie Microsoft Word 2016 und Microsoft Exchange Server 2016 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 hinzufügen Windows Server, aber das Ergebnis hängt 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 unter 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 Patch für Windows Server Diese Microsoft-Versionen enthalten in der Regel alle Informationen, die für eine erfolgreiche Installation erforderlich sind. Gelegentlich kann jedoch ein erforderliches 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.