Das Patchen und Aktualisieren von Systemen ist ein wichtiger Schritt zur Reduzierung möglicher Angriffsvektoren auf Ihre Infrastruktur. Wenn es Systeme in Ihrer Umgebung gibt, die mit Patches nicht auf dem neuesten Stand sind, kann es Angriffsvektoren geben, von denen Sie nicht wissen, dass sie möglicherweise Ihr gesamtes Unternehmen betreffen. Welche Maßnahmen ergreifen Sie jedoch, wenn ein Patch-Ereignis nicht wie erwartet verläuft?
[ Den Lesern gefiel auch: Sichern eines geerbten Linux-Systems ]
Zum Beispiel könnten Abhängigkeiten nicht erfüllt werden, es könnte nicht übereinstimmende Versionen zwischen i686- und x86_64-RPMs geben, neue Paketversionen könnten nicht wie erwartet funktionieren oder etwas anderes könnte schief gehen. Wenn etwas schief geht, ist es wichtig, einen Plan zu haben, wie es weitergehen soll. Dies reduziert den Stresspegel und stellt sicher, dass jeder, der an der Aufgabe arbeitet, weiß, was die anderen tun.
Testpatches
Beim Patchen ist es wichtig, die Patches zuerst in einer Testumgebung zu testen die zu Ihrer Produktionsumgebung passt . Wenn Sie die Patches auf anderer Hardware, mit anderen Softwareversionen oder mit anderen Workloads oder Prozessen als in Ihrer Produktionsumgebung testen, gibt es keine Garantie dafür, dass die Patching-Testergebnisse das widerspiegeln, was in der Produktion passieren wird. Sobald Sie über eine Testumgebung verfügen, in der Sie überprüfen können, ob ein bestimmtes Patch-Bundle installiert werden sollte, verringern Sie die Wahrscheinlichkeit von Problemen bei der Installation der Updates erheblich.
Fehlgeschlagene Patches
Wenn Updates nicht installiert werden können, müssen Sie zunächst alle Ausgaben auf der Konsole oder in den Protokollen erfassen. Dies kann einfach das Kopieren einer Protokolldatei an einen anderen Speicherort oder das Kopieren des auf dem Konsolenbildschirm angezeigten Textes sein. Je nachdem, wie das Patchen versucht wurde, sollten Sie versuchen, die Updates erneut auszuführen, diesmal mit aktivierter ausführlicher Ausgabe. Sobald Sie die Fehlerausgabe haben, sollten Sie alle Unterschiede zwischen Ihrer Testumgebung und Ihrer Produktionsumgebung sehen. Sie müssen auch sicherstellen, dass alle Patches beim Testen angewendet wurden und dass keine Patches oder Fehler versehentlich übersehen wurden. Ein wichtiges Element, das Sie überprüfen sollten, ist die Liste der installierten RPMs auf Ihrem Testserver, um sie mit den Versionen auf Ihrem Produktionsserver zu vergleichen.
Zum Beispiel auf dem Produktionsserver:
# rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'| sort &> /tmp/rpm-qa.prod.output.txt
Sie könnten das dann mit der Ausgabe vergleichen, die auf Ihrem Testserver in seiner /tmp/rpm-qa.dev.output.txt gesammelt wurde .
Sie sollten auch überprüfen, ob der verfügbare yum Die Repositorys sind auf beiden Systemen gleich. Sie können dies in drei einfachen Schritten tun.
Löschen Sie zuerst den Cache:
# yum clean all
# rm /var/cache/yum/* -rf Aktualisieren Sie als Nächstes den Abonnement-Manager:
# subscription-manager refresh
Drittens listen Sie die Repositories in yum auf mit dem -v -Argument, damit Sie zusätzliche Informationen wie repodate sehen können und die Anzahl der Pakete in den Repositories:
# yum repolist -v Im folgenden Beispiel betrachten wir die rhel-8-for-x86_64-appstream-rpms -Repository, das von einem Client für meinen Red Hat Satellite-Server verwendet wird:
Repo-id : rhel-8-for-x86_64-appstream-rpms
Repo-name : Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Repo-revision: 1605844838
Repo-updated : Thu 19 Nov 2020 11:02:03 PM EST
Repo-pkgs : 13,502
Repo-size : 31 G
Repo-baseurl : https://opendemo.usersys.redhat.com/pulp/repos/opendemoorg/Library/content/dist/rhel8/8/x86_64/appstream/os
Repo-expire : 1 second(s) (last: Wed 31 Dec 1969 07:00:00 PM EST)
Repo-filename: /etc/yum.repos.d/redhat.repo Die Schlüsselzeilen hier sind repo-id , repo-aktualisiert , Repo-Pakete und repo-baseurl . Wenn meine Test- und Produktionssysteme unterschiedliche Informationen für ihre Upstream-Repositorys anzeigen, besteht die Möglichkeit, dass Abhängigkeiten nicht erfüllt werden oder etwas anderes fehlschlägt. Wenn dies der Fall ist, müssen Sie untersuchen, warum die Systeme unterschiedliche Informationen sehen.
Andere Einstellungen
Angenommen, die Test- und Produktionssysteme haben die erwarteten RPMs und die gleichen Repositories, aber das Patchen schlägt immer noch fehl. In diesem Fall könnten andere mögliche Ursachen eine falsch angewendete Sicherheitseinstellung, wenig Speicherplatz oder möglicherweise falsche Benutzerberechtigungen sein. Um diese zu untersuchen, überprüfen Sie Protokolle wie /var/log/messages , /var/log/secure und /var/log/audit/audit.log hilfreich sein, ebenso wie die Verwendung des Befehls df -h Speicherplatz zu überprüfen. Außerdem können Red Hat-Kunden gerne ein Support-Ticket eröffnen, um Unterstützung bei der Lösung des Problems zu erhalten.
[ Kostenloser Online-Kurs:Technischer Überblick zu Red Hat Enterprise Linux. ]
Abschluss
Es gibt viele mögliche Ursachen für Patches, die nicht korrekt installiert werden, aber die Möglichkeit, Ihre Testumgebung mit Ihrer Produktionsumgebung zu vergleichen, wird die Fehlerbehebung erheblich vereinfachen. Konfigurationen, Abhängigkeiten, Workloads und Repositories sollten in den beiden Umgebungen alle gleich sein.