So geben Sie ein alternatives Patch-Quell-Repository an (Linux) - AWS Systems Manager
Wichtige Überlegungen für alternative RepositorysAnwendungsbeispiele für alternative Patch-Quell-Repositorys

So geben Sie ein alternatives Patch-Quell-Repository an (Linux)

Wenn Sie die Standard-Repositorys verwenden, die in einem verwalteten Knoten für Patch-Operationen konfiguriert sind, sucht Patch Manager, ein Tool in AWS Systems Manager, nach sicherheitsbezogenen Patches oder installiert sie. Dies ist das Standardverhalten für Patch Manager. Ausführliche Informationen darüber, wie Patch Manager Sicherheits-Patches auswählt und installiert, finden Sie unter Wie Sicherheitspatches ausgewählt werden.

Sie können auf Linux-Systemen jedoch auch mithilfe von Patch Manager Patches installieren, die nicht auf Sicherheit bezogen sind oder die sich in einem anderen als dem Standard-Quell-Repository befinden, das in dem verwalteten Knoten konfiguriert ist. Sie können beim Erstellen einer benutzerdefinierten Patch-Baseline alternative Patch-Quell-Repositorys angeben. Für jede benutzerdefinierte Patch-Baseline können Sie Patch-Quellkonfigurationen für bis zu 20 Versionen eines unterstützten Linux-Betriebssystems angeben.

Angenommen, Ihre Ubuntu Server-Flotte beinhaltet Ubuntu Server 25.04-verwaltete Knoten. In diesem Fall können Sie alternative Repositorys für jede Version in derselben benutzerdefinierten Patch-Baseline angeben. Geben Sie für jede Version einen Namen, die Version und den Typ des Betriebssystems (Produkt) und eine Repository-Konfiguration an. Sie können auch ein einziges alternatives Quell-Repository angeben, das für alle Versionen eines unterstützten Betriebssystems gilt.

Anmerkung

Wenn Sie eine benutzerdefinierte Patch-Baseline ausführen, die alternative Patch-Repositorys für einen verwalteten Knoten angeben, werden diese Repositorys dadurch nicht zum neuen Standard-Repository auf dem Betriebssystem. Nach Abschluss der Patching-Operation bleiben die zuvor definierten Standard-Repositorys für das Betriebssystem des Knoten als Standard erhalten.

Eine Liste mit Beispielszenarien zur Verwendung dieser Option finden Sie weiter Anwendungsbeispiele für alternative Patch-Quell-Repositorys unten in diesem Thema.

Weitere Informationen zu Standard- und benutzerdefinierten Patch-Baselines finden Sie unter Vordefinierte und benutzerdefinierte Patch-Baselines.

Beispiel: Verwenden der Konsole

Um alternative Patch-Quell-Repositorys anzugeben, wenn Sie in der Systems Manager-Konsole arbeiten, verwenden Sie den Abschnitt Patch sources auf der Seite Create patch baseline. Weitere Informationen zur Verwendung der Optionen in Patch sources (Patch-Quellen) finden Sie unter So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux.

Beispiel: Verwenden der AWS CLI

Ein Beispiel für die Verwendung der Option --sources mit der AWS Command Line Interface (AWS CLI) finden Sie in Erstellen einer Patch-Baseline mit benutzerdefinierten Repositorys für verschiedene Betriebssystemversionen.

Wichtige Überlegungen für alternative Repositorys

Beachten Sie die folgenden Punkte, wenn Sie planen, in Ihrer Patching-Strategie alternative Patch-Repositorys zu verwenden.

Nur angegebene Repositorys werden für das Einspielen von Patches verwendet.

Angeben von alternativen Repositorys bedeutet nicht das Angeben zusätzlicher Repositorys. Sie können wählen, andere Repositorys als die auf einem verwalteten Knoten als Standardwerte konfigurierten festzulegen. Sie müssen jedoch auch die Standard-Repositorys als Teil der alternativen Patch-Quell-Konfiguration angeben, wenn Sie möchten, dass deren Updates übernommen werden.

Beispielsweise sind die Standard-Repositorys auf von Amazon Linux 2 verwalteten Knoten amzn2-core und amzn2extra-docker. Wenn Sie das Repository "Extra Packages for Enterprise Linux (EPEL)" in Ihre Patching-Operationen einschließen möchten, müssen Sie alle drei Repositorys als alternative Repositorys angeben.

Anmerkung

Wenn Sie eine benutzerdefinierte Patch-Baseline ausführen, die alternative Patch-Repositorys für einen verwalteten Knoten angeben, werden diese Repositorys dadurch nicht zum neuen Standard-Repository auf dem Betriebssystem. Nach Abschluss der Patching-Operation bleiben die zuvor definierten Standard-Repositorys für das Betriebssystem des Knoten als Standard erhalten.

Das Patching-Verhalten für YUM-basierte Distributionen hängt vom updateinfo.xml-Manifest ab

Wenn Sie alternative Patch-Repositorys für YUM-basierte Distributionen festlegen, z. B. Amazon Linux 2 oder Red Hat Enterprise Linux, hängt das Patching-Verhalten davon ab, ob das Repository ein Update-Manifest in Form einer vollständig und korrekt formatierten updateinfo.xml-Datei enthält. Diese Datei gibt das Release-Datum, Klassifizierungen und Schweregrade der verschiedenen Pakete an. Jede der folgenden Optionen wirkt sich auf das Patching-Verhalten aus:

  • Wenn Sie nach Klassifizierung und Schweregrad filtern, diese aber nicht in updateinfo.xml angegeben sind, wird das Paket nicht in Filter aufgenommen. Dies bedeutet auch, dass Pakete ohne eine updateinfo.xml-Datei werden nicht in das Patching eingeschlossen werden.

  • Wenn Sie nach ApprovalAfterDays filtern, aber das Veröffentlichungsdatum des Pakets nicht im Unix-Epoch-Format ist (oder kein Veröffentlichungsdatum angegeben ist), wird das Paket nicht vom Filter aufgenommen.

  • Eine Ausnahme besteht, wenn Sie das Kontrollkästchen Genehmigte Patches umfassen nicht sicherheitsrelevante Updates auf der Seite Patch-Baseline erstellen aktivieren. In diesem Fall werden Pakete ohne eine updateinfo.xml-Datei (oder die diese Datei ohne ordnungsgemäß formatierte Werte für Klassifizierung, Schweregrad und Datum enthalten) in die vorgefilterte Liste der Patches aufgenommen. (Diese müssen nach wie vor die übrigen Anforderungen Patch-Baseline Regel erfüllen, damit sie installiert werden.)

Anwendungsbeispiele für alternative Patch-Quell-Repositorys

Beispiel 1: Nicht sicherheitsrelevante Updates für Ubuntu Server

Sie verwenden Patch Manager bereits zum Installieren von Sicherheits-Patches auf einer Flotte von Ubuntu Server-verwalteten Knoten mit der von AWS bereitgestellten vordefinierten Patch-Baseline AWS-UbuntuDefaultPatchBaseline. Sie können eine neue Patch-Baseline erstellen, die auf diesem Standard basiert, aber in den Genehmigungsregeln angeben, dass nicht auf die Sicherheit bezogene Updates, die Teil der Standardverteilung sind, ebenfalls installiert werden sollen. Wenn diese Patch-Baseline für Ihre Knoten ausgeführt wird, werden sowohl sicherheitsbezogene als auch nicht-sicherheitsbezogene Patches angewendet. Sie können auch auswählen, dass nicht sicherheitsbezogene Patches in den Patch-Ausnahmen, die Sie für eine Baseline angeben, genehmigt werden.

Beispiel 2: Personal Package Archives (PPA) für Ubuntu Server

Auf Ihren von Ubuntu Server verwalteten Knoten wird Software ausgeführt, die über ein Personal Package Archives (PPA) für Ubuntu verteilt wird. In diesem Fall erstellen Sie eine Patch-Baseline, die ein PPA-Repository angibt, das Sie auf dem verwalteten Knoten als das Quell-Repository für die Patch-Operation konfiguriert haben. Führen Sie anschließend mithilfe von Run Command das Patch-Baseline-Dokument auf den Knoten aus.

Beispiel 3: Interne Firmenanwendungen in unterstützten Amazon-Linux-Versionen

Sie müssen auf Ihren von Amazon Linux verwalteten Knoten einige Anwendungen ausführen, die für die Compliance gesetzlicher Vorschriften und Branchenstandards erforderlich sind. Sie können ein Repository für diese Anwendungen auf den Knoten konfigurieren, mit YUM die Anwendungen erstmals installieren und eine neue Patch-Baseline aktualisieren oder erstellen, um dieses neue Unternehmens-Repository hinzuzufügen. Anschließend können Sie mit Run Command das Dokument AWS-RunPatchBaseline mit der Option Scan ausführen, um zu prüfen, ob das Unternehmenspaket unter den installierten Paketen aufgelistet und auf dem verwalteten Knoten aktuell ist. Wenn es nicht aktuell ist, können Sie das Dokument mithilfe der Option Install erneut ausführen, um die Anwendungen zu aktualisieren.