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.
So geben Sie ein alternatives Patch-Quell-Repository an (Linux)
Wenn Sie die auf einem verwalteten Knoten konfigurierten Standard-Repositorys für Patching-Operationen verwenden, Patch Manager, ein Tool in AWS Systems Manager, sucht nach sicherheitsrelevanten Patches oder installiert diese. Dies ist das Standardverhalten für Patch Manager. Für vollständige Informationen darüber, wie Patch Manager wählt Sicherheitspatches aus und installiert sie, sieheWie Sicherheitspatches ausgewählt werden.
Auf Linux-Systemen können Sie jedoch auch Folgendes verwenden Patch Manager um Patches zu installieren, die nichts mit der Sicherheit zu tun haben oder die sich in einem anderen Quell-Repository als dem auf dem verwalteten Knoten konfigurierten Standard-Repository befinden. 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.
Nehmen wir zum Beispiel an, dass Ihr Ubuntu Server Die Flotte umfasst beide Ubuntu Server 14.04 und Ubuntu Server 16.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: Verwendung des 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.
Themen
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 wie Amazon Linux 1 oder Amazon Linux 2 angeben, Red Hat Enterprise Linux, oder CentOS, das Patch-Verhalten hängt davon ab, ob das Repository ein Aktualisierungsmanifest in Form einer vollständigen 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.xmlangegeben sind, wird das Paket nicht in Filter aufgenommen. Dies bedeutet auch, dass Pakete ohne eineupdateinfo.xml-Datei werden nicht in das Patching eingeschlossen werden. -
Wenn Sie nach filtern ApprovalAfterDays, aber das Veröffentlichungsdatum des Pakets nicht im Format Unix Epoch ist (oder kein Veröffentlichungsdatum angegeben ist), wird das Paket nicht in den 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 — Unsicherheitsrelevante Updates für Ubuntu Server
Sie verwenden bereits Patch Manager um Sicherheitspatches auf einer Flotte von zu installieren Ubuntu Server verwaltete Knoten unter Verwendung der AWS bereitgestellten vordefinierten Patch-BaselineAWS-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 Archive (PPA) für Ubuntu Server
Ihre Ubuntu Server Auf verwalteten Knoten wird Software ausgeführt, die über ein Personal Package Archive (PPA) für Ubuntu
Beispiel 3: Interne Firmenanwendungen auf Amazon Linux
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. Danach können Sie verwenden Run Command um das AWS-RunPatchBaseline Dokument mit der Scan Option auszuführen, zu überprüfen, ob das Unternehmenspaket unter den installierten Paketen aufgeführt ist 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.
