Vorbereiten der Anwendung von Updates auf Red Hat Linux

Objektiv

Unser Ziel ist es, dass das Update des Betriebssystems reibungslos und fehlerfrei abläuft.

Betriebssystem- und Softwareversionen

Betriebssystem: Red Hat Enterprise Linux 6+

Anforderungen

Privilegierter Zugriff auf die Systeme

Schwierigkeit

LEICHT

Konventionen

# – erfordert, dass bestimmte Linux-Befehle mit Root-Rechten ausgeführt werden, entweder direkt als Root-Benutzer oder mit dem Befehl sudo
$ – gegebene Linux-Befehle, die als normaler, nicht privilegierter Benutzer ausgeführt werden sollen

Einleitung

Das System auf dem neuesten Stand zu halten, ist sowohl für einen Systemadministrator als auch für einen Desktop-Benutzer eine alltägliche Aufgabe. Durch die Anwendung der neuesten (stabilen) verfügbaren Software auf dem System können wir die neuesten Funktionen nutzen und sind besser vor Sicherheitsproblemen geschützt und leiden hoffentlich weniger unter Fehlern. Um das System zu aktualisieren, benötigen Sie konfigurierte yum-Repositories, die als Quelle für die aktualisierte Software fungieren.

Wenn Sie neben dem Computer sitzen, auf dem das zu aktualisierende Betriebssystem ausgeführt wird, können Sie problemlos handeln, wenn während des Updates etwas schief geht, z. B. die Ausgabe auf dem Terminal überprüfen oder zu einem Live-System booten, wenn das aktualisierte System nicht nach dem Neustart zurückkehrt – aber das ist nicht immer der Fall. Stellen Sie sich ein Rechenzentrum mit Hunderten oder Tausenden von (virtuellen) Maschinen vor oder einfach einen physischen PC, den Sie remote aufrüsten müssen.

Es gibt einfache Schritte, die wir ausführen können, um das System für das Upgrade vorzubereiten und möglicherweise jedes Problem zu beheben, das ein erfolgreiches Update gefährden würde.

Update-Prozess

Wenn Sie eine bedingungslose Aktualisierung durchführen (d.h. "alle aktualisieren"), holt yum alle Metadaten aus den verfügbaren Projektarchiven und berechnet alle Pakete, die aktualisiert werden sollen, anhand der RPM-Datenbank, die alle Metadaten über die auf dem System installierten Pakete enthält.

Der Aktualisierungsprozess berechnet auch alle Abhängigkeiten der aktualisierten Pakete, kann alte Pakete ersetzen und alte Kernel-Images entsprechend seiner Konfiguration entfernen. Die Anzahl der zu behaltenden Kernel-Images wird in der Konfigurationsdatei /etc/yum.conf festgelegt und beträgt standardmäßig 3:

installonly_limit=3

Nachdem alle erforderlichen Änderungen berechnet wurden, bietet yum eine umfangreiche Liste aller Pakete, die aufgrund von Abhängigkeiten aktualisiert, entfernt oder installiert werden sollen, genau wie bei der Installation oder Aktualisierung bestimmter Pakete.

In einer interaktiven Update-Sitzung stellt yum eine Zusammenfassung der zu ändernden Pakete zur Verfügung, sowie eine Berechnung der Datengröße, die für das Upgrade heruntergeladen werden muss, wie unten gezeigt:

Zusammenfassung des interaktiven yum-Updates

Nachdem wir die Ergebnisse überprüft haben, können wir entscheiden, ob wir das Update starten oder abbrechen. Da yum alles aktualisiert, wofür es Updates finden kann, möchten wir vielleicht vorher nicht benötigte Pakete entfernen. Möglicherweise stellen wir auch fest, dass ein Paket, das als Update markiert ist, für das wir eine Versionssperre haben und das vom Upgrade ausgeschlossen werden muss.

Nach der Genehmigung lädt yum alle neuen Pakete herunter und installiert/aktualisiert sie nacheinander. Wenn es fertig ist, wird es die Integrität der installierten/aktualisierten Pakete überprüfen und nicht benötigte Dateien bereinigen. Es gibt auch Feedback während des Prozesses, indem es eine Textzeile für jeden Schritt sowie einen Exitcode bereitstellt, der angibt, ob das Upgrade erfolgreich war oder ob ein Problem aufgetreten ist. Der Update-Prozess wird auch abgebrochen, wenn ein Problem auftritt, das aus der Perspektive des konsistenten Systems kritisch erscheint – aber es gibt Zeiten, in denen es bereits zu spät ist, so dass es ein besserer Ansatz ist, Update-Probleme zu verhindern.

Speicherplatz

Leckerer Cache

Aus dem oben beschriebenen Prozess können wir erraten, dass wir für den Update-Prozess etwas Speicherplatz benötigen:

Die Metadaten aller konfigurierten Repositories müssen gespeichert werden, bis die Berechnung aller zu aktualisierenden Pakete (und ihrer Abhängigkeiten) abgeschlossen ist.
RPM-Pakete, aus denen das Update selbst besteht, müssen lokal gespeichert werden, bis es ordnungsgemäß installiert ist.

Diese Daten, die als yum-Cache bezeichnet werden, werden nur während des Updates benötigt, können aber erheblichen Speicherplatz beanspruchen. Der Standardspeicherort für diesen Cache befindet sich im Verzeichnis /var/cache/yum. Es versteht sich von selbst, dass der Aktualisierungsvorgang fehlschlägt, wenn nicht genügend Speicherplatz zum Speichern aller benötigten Daten vorhanden ist. Einige unvollendete Downloads werden verworfen, aber es kann sein, dass nicht der gesamte Speicherplatz freigegeben wird, was dazu führt, dass ein System das Update nicht bestanden hat und das Volume mit /var/cache fast voll ist.

Viele Installationen speichern ihr /var-Verzeichnis auf einem Volume, das für die Protokollierung vorgesehen ist, da der Standardort für Protokolldateien bei den meisten Distributionen /var/log ist und die meisten gut funktionierenden Anwendungen nicht mehr funktionieren oder sogar abstürzen, wenn sie ihre Protokolldateien nicht schreiben können. Es ist also eine schlechte Sache, das Volumen zu füllen, in das sie schreiben.

Je mehr Pakete aktualisiert werden müssen und je mehr Repositories wir haben, desto mehr Speicherplatz wird das Update temporär belegen. Diesen Platz von Update zu Update zu berechnen ist schwierig, kann aber mit der später beschriebenen Probelauflösung getestet werden, wenn wir eine Testmaschine mit dem exakten Softwareinhalt haben. Ein Echtzeitbeispiel: Das Update von RHEL 7.1 auf 7.5 (Desktopinstallation mit Gnome) kann 4 GB Cache-Speicherplatz beanspruchen, aber die Installation einiger Fixes auf einem System, das nur ein oder zwei Monate veraltet ist, nimmt nur wenige MB in Anspruch.

Um zu überprüfen, wie viel Speicherplatz wir haben, können wir den Befehl df verwenden:

df -h /var/
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/vg_sys-var  6.0G  1.7G  4.4G  28% /var

Im obigen Beispiel haben wir 4,4 GB freien Speicherplatz, was ausreicht, da der Server erst vor wenigen Monaten aktualisiert wurde. Um Speicherplatz freizugeben, wäre ein trivialer Schritt, den bereits gespeicherten Yum-Cache zu leeren (vielleicht beim letzten Update). Um zu überprüfen, wie viel Speicherplatz ein Cache gerade einnimmt, können wir du verwenden:

du -mcd 1 /var/cache/yum
1103    /var/cache/yum/x86_64
1103    /var/cache/yum
1103    total

Die obigen Zahlen sind in MB angegeben, sodass der Yum-Cache in diesem Beispiel etwa 1 GB Speicherplatz belegt und den größten Teil des Speicherplatzes auf dem /var-Volume belegt.

Löschen des Caches

Wir können den gesamten Cache mit dem folgenden Befehl leeren:

yum clean all

Aber wie yum uns in der Ausgabe des obigen Befehls auf RHEL 7-Versionen mitteilt, kann es verwaiste Daten aus entfernten oder deaktivierten Repositories geben, was höchstwahrscheinlich nach geringfügigen Release-Ugrades passieren wird, in diesem Fall können wir die Daten sicher von Hand löschen:

rm -rf /var/cache/yum/*

Wir erhalten möglicherweise mehr Speicherplatz für das Update, indem wir andere auf dem Volume gespeicherte Daten löschen, z. B. alte Protokolldateien komprimieren/löschen, große Dateien auf andere Volumes verschieben oder die Volume-Größe erweitern.

Verschieben des Caches

Um mit den Möglichkeiten von yum fortzuarbeiten, können wir, wenn wir wirklich wenig Speicherplatz haben, nichts weiter löschen können und dem Volume nicht mehr Speicherplatz hinzufügen können, den Speicherort des yum-Cache auf ein anderes Volume mit mehr freiem Speicherplatz verschieben. Wir können den Cache-Speicherort in der oben erwähnten Konfigurationsdatei yum.conf konfigurieren. Betrachten Sie die Standardeinstellung:

cachedir=/var/cache/yum/$basearch/$releasever

Wenn Sie den Pfad vor $basearch ändern, funktioniert die nächste yum-Operation mit der gleichen Verzeichnisstruktur, aber auf einem anderen Pfad – hoffentlich mit mehr freiem Speicherplatz für das Upgrade. Wir können den Cache auch auf ein anderes Volume verschieben, indem wir das gesamte Verzeichnis verschieben:

mv /var/cache/yum /extended_data_volume/

Und Erstellen eines symbolischen Links an der ursprünglichen Stelle, der auf die neue Stelle verweist:

ln -s /extended_data_volume/yum /var/cache/yum

Es ist ratsam zu wissen, dass das Update nicht bei einem trivialen Fehler wie zu wenig Speicherplatz fehlschlägt. Auf einem großen System setzen Systemadministratoren Überwachungstools wie Nagios ein, die wenig Speicherplatz auf allen Rechnern melden können, was diesen Schritt viel weniger zeitaufwändig und fehleranfällig macht.

Netzwerkfehler

Wenn es Probleme mit der Verbindung zwischen den Repositories und dem Computer gibt, der das Update ausführt, schlägt das Update möglicherweise fehl. Dies kann nur in der Metadaten- oder der neuen rpms-Download-Phase passieren und wird das System nicht beschädigen. Sie können den Aktualisierungsvorgang erneut starten, wenn das Netzwerkproblem behoben ist.

Auf der anderen Seite, wenn das Update aus einer interaktiven Sitzung initialisiert wird, kann es bei einem Netzwerkausfall zu einer Unterbrechung der Verbindung kommen, sodass der Aktualisierungscomputer keinen Administrator mehr hat, um die Fragen zu beantworten, die Yum möglicherweise stellt. Wenn die Installations-/Aktualisierungsphase des Pakets bereits gestartet wurde, wird sie unbeaufsichtigt fortgesetzt und kann fehlschlagen oder abgeschlossen werden, wenn dies andernfalls der Fall wäre. Nach der Wiederherstellung der Verbindung kann der Vorgang in der Datei /var/log/yum.log verfolgt werden.

Leckerer Trockenlauf

Abgesehen von unzureichendem Speicherplatz und Netzwerkproblemen kann das Update in vielen Fällen aufgrund ungelöster Paketabhängigkeiten fehlschlagen. Diese müssen mit Tools gelöst werden, die Paketabhängigkeiten berechnen und handhaben können, aber es wäre nützlich zu wissen, dass es vor dem eigentlichen Update Probleme geben wird (und daher die immer zu kurze Ausfallzeit des Systems nicht verschwendet wird). Um diese wertvollen Informationen zu erhalten, können wir den Aktualisierungsprozess so ausführen, wie er das eigentliche Update ausführen würde, aber stoppen, bevor das eigentliche Herunterladen, Installieren oder Aktualisieren von Paketen stattgefunden hat.

Um Redhat 6.6 herum wurde eine neue Option eingeführt, die dazu führt, dass yum bei jeder Frage, die während des Updates auftaucht, ein "Nein" annimmt – einschließlich der Genehmigung vor der eigentlichen Phase der Paketmanipulation, und als Konsequenz ist keine tatsächliche Interaktion erforderlich, um einen Probelauf durchzuführen:

yum update --assumeno

Dies kann das ideale Tool sein, um einen Probelauf des kommenden Updates bereitzustellen, einschließlich der zu aktualisierenden Pakete und aller Fehler, die auftreten können. Betrachten Sie das folgende einfache Bash-Skript:

#!/bin/bash
yum update --assumeno &> $(hostname).yum.dryrun.$(date '+%Y-%m-%d').out
exit $?

Das obige Skript kann automatisch ausgeführt werden und liefert einen Textbericht über den Probelauf sowie einen allgemeinen Exit-Code, der auf eventuelle Probleme hinweist. Die Ausgabe muss nicht auf dem lokalen Dateisystem gespeichert werden. Das Ziel der Ausgabeumleitung kann ein Netzwerkdateisystem sein, oder der Bericht kann an einen zentralen Berichtsserver gesendet werden, der von anderen Skripts oder Anwendungen erfasst werden kann. Die Berichte können veröffentlicht und zur Genehmigung an andere IT-Abteilungen verteilt werden, so dass alle Beteiligten genau sehen können, welche Pakete auf welche Version aktualisiert werden.

Der Probelauf kann so geplant werden, dass er in einem bestimmten Zeitrahmen (vielleicht nachts, um die Leistung des Systems weniger zu beeinträchtigen) mit cron ausgeführt wird, oder von einer zentralen Quelle mit einem Marionetten-Setup ausgeführt werden. Der Exit-Code kann auch von Monitoring oder Facter gespeichert und verarbeitet werden, um die möglichen Ergebnisse des bevorstehenden Upgrades zu aggregieren, bevor fortgefahren wird.

Schlussfolgerung

Auch bei einem oder wenigen Rechnern sollten wir uns sicherheitshalber vor dem Start eines Updates des gesamten Betriebssystems informieren. Eines Tages wird es ein Problem geben, und es ist viel weniger stressig, wenn Sie es lösen können, bevor es Auswirkungen auf die eigentliche Arbeit einer bestimmten Maschine hat. In größerem Maßstab ist es einfach nicht möglich, neben jedem Server oder Desktop zu sitzen und ihn mit Ihrer Anwesenheit zu unterstützen, in der Hoffnung, dass dies dazu beiträgt, dass das Update einwandfrei läuft.

Die Kenntnis der Phasen des Update-Prozesses, der Fallstricke sowie der Lösung für diese ist für erfolgreiche Updates unerlässlich. Wenn Sie die nächste Aktualisierungsphase Ihrer gesamten Infrastruktur mit der Gewissheit beginnen, dass es keine Probleme geben wird, müssen Sie dies mit Stil tun.