Eine Übersetzung des Artikels wurde speziell für Studenten des Linux Administrator- Kurses erstellt.
Wir beschäftigen uns mit der Fähigkeit von systemd , Container auszuführen, um das Root-Dateisystem eines beschädigten Systems wiederherzustellen.
Solange GNU / Linux-Systeme vorhanden sind, müssen sich Systemadministratoren von Schäden am Root-Dateisystem, versehentlichen Konfigurationsänderungen oder anderen Situationen erholen, die verhindern, dass das System in einen „normalen“ Zustand geladen wird.In der Regel bieten Linux-Distributionen beim Booten eine oder mehrere Menüoptionen (z. B. im GRUB-Menü), mit denen ein beschädigtes System repariert werden kann. Oft booten sie das System im Einzelbenutzermodus, wobei die meisten Systemdienste heruntergefahren werden. Im schlimmsten Fall kann der Benutzer die Kernel-Befehlszeile im Bootloader ändern, um die Standard-Shell als Init-Prozess (PID 1) zu verwenden. Diese Methode ist die komplexeste und mit Schwierigkeiten behaftete, die zu Zeitverlust und Frustration führen kann, während das System wiederhergestellt werden muss.
Vor allem gehen alle diese Methoden davon aus, dass das beschädigte System über eine Art physische Konsole verfügt, auf die man sich im Zeitalter des Cloud Computing jedoch nicht mehr verlassen kann. Ohne physische Konsole gibt es nur wenige Optionen (sofern diese noch verfügbar sind), um den Startvorgang auf diese Weise zu beeinflussen. Sogar physische Maschinen können sich als kleine integrierte Geräte herausstellen, die keine einfach zu bedienende Konsole haben. Wenn Sie die richtigen Kabel und Adapter für die serielle Schnittstelle finden und einen Terminalemulator einrichten, ist alles für die Verwendung der Konsole an einer seriellen Schnittstelle im Notfall oft recht kompliziert.
Wenn ein anderes System verfügbar ist (mit derselben Architektur und im Allgemeinen ähnlicher Konfiguration), besteht eine allgemeine Möglichkeit zur Vereinfachung des Wiederherstellungsprozesses darin, die Speichergeräte aus dem beschädigten System zu entfernen und sie als sekundäre Geräte mit dem Arbeitssystem zu verbinden. Auf physischen Systemen ist dies normalerweise unkompliziert, und die meisten Cloud-Computing-Plattformen können dies auch unterstützen, da Sie das Root-Volume der beschädigten Instanz in einer anderen Instanz bereitstellen können.
Nachdem das Root-Dateisystem mit einem anderen System verbunden wurde, wird das Problem mit der Beschädigung des Dateisystems mithilfe von
fsck und anderen Tools behoben. Die Fehlerbehebung bei Konfigurationsfehlern, beschädigten Paketen oder anderen Problemen kann schwieriger sein, da Sie das Dateisystem bereitstellen und die richtigen Konfigurationsdateien oder Datenbanken suchen und ändern müssen.
Verwenden von systemd
Vor dem Aufkommen von
systemd bestand die Möglichkeit, Konfigurationen in der Praxis zu korrigieren, darin, Konfigurationsdateien mit einem Texteditor zu bearbeiten. Das Finden der erforderlichen Dateien und das Verstehen ihres Inhalts ist eine separate Aufgabe, die den Rahmen dieses Artikels sprengt.
Wenn das GNU / Linux-System
systemd verwendet , lassen sich viele Konfigurationsänderungen am besten mit den von ihm bereitgestellten Tools vornehmen. Zum Aktivieren oder Deaktivieren von Diensten müssen beispielsweise an verschiedenen Stellen symbolische Links erstellt oder gelöscht werden. Das
systemctl- Tool
wird verwendet, um diese Änderungen vorzunehmen. Für seine Verwendung muss die
systemd- Instanz jedoch arbeiten und auf Anforderungen
warten (über D-Bus). Wenn das Root-Dateisystem als zusätzliches Dateisystem auf einem anderen Computer bereitgestellt wird, kann eine Arbeitsinstanz von systemd nicht verwendet werden, um diese Änderungen vorzunehmen.
Der manuelle Start des Systems des Zielsystems ist ebenfalls unpraktisch, da es als PID 1-Prozess zur Steuerung aller anderen Prozesse ausgelegt ist, die mit einer bereits laufenden Instanz in dem zur Korrektur verwendeten System in Konflikt stehen können.
Glücklicherweise kann
systemd Container ausführen - vollständig gekapselte GNU / Linux-Systeme mit eigener PID 1 und Umgebung, die verschiedene Namespace-Funktionen des Linux-Kernels verwenden. Im Gegensatz zu Tools wie Docker und Rocket benötigt
systemd kein Container-Image, um den Container auszuführen. Er kann es mit Root-Rechten überall im vorhandenen Dateisystem ausführen. Dies erfolgt mit dem
Tool systemd-nspawn , das die erforderlichen Systemnamespaces erstellt, den ersten Prozess im Container startet und dann die Konsole bereitstellt. Im Gegensatz zu
chroot , das nur das sichtbare Stammverzeichnis des Dateisystems ändert, verfügt dieser Containertyp über einen separaten Dateisystem-Namespace, geeignete Dateisysteme in
/ dev ,
/ run und
/ proc sowie einen separaten Prozess-Namespace und IPC. Besuchen Sie die
Hauptressource systemd-nspawn , um mehr über die Funktionen zu erfahren.
Ein Beispiel, um zu demonstrieren, wie dies funktioniert
In diesem Beispiel ist ein Speichergerät, das das Root-Dateisystem des beschädigten Systems enthält, mit einem laufenden System verbunden, auf dem es als
/ dev / vdc angezeigt wird . Der Name des Geräts hängt von der Anzahl der vorhandenen Speichergeräte, dem Gerätetyp und der Methode zum Verbinden mit dem System ab. Das Root-Dateisystem kann das gesamte Speichergerät verwenden oder sich in einer Partition im Gerät befinden. Da die häufigste (einfache) Konfiguration das Root-Dateisystem in der ersten Partition des Geräts platziert, wird in diesem Beispiel
/ dev / vdc1 verwendet.
Stellen Sie sicher, dass Sie den Gerätenamen in den folgenden Befehlen durch den richtigen Gerätenamen Ihres Systems ersetzen .
Ein beschädigtes Root-Dateisystem kann auch komplexer sein als ein separates Dateisystem auf einem Gerät. Dies kann ein Volume in LVM oder auf einer Reihe von Geräten sein, die in einem RAID-Array kombiniert sind. In diesen Fällen müssen Sie die erforderlichen Schritte ausführen, um ein logisches Gerät mit dem Dateisystem zu erstellen und zu aktivieren, bevor es zum Mounten verfügbar ist. Auch diese Schritte gehen über den Rahmen dieses Artikels hinaus.
Notwendige Vorbereitungen
Stellen Sie zunächst sicher, dass das Tool systemd-nspawn installiert ist. Die meisten GNU / Linux-Distributionen installieren es nicht standardmäßig. Es wird auf den meisten Distributionen vom systemd-container-Paket bereitgestellt. Verwenden Sie daher den Paketmanager Ihrer Distribution, um es zu installieren. Die Anweisungen in diesem Beispiel wurden mit Debian 9 getestet, sollten jedoch auf jeder modernen GNU / Linux-Distribution ähnlich funktionieren.
Für die Verwendung der folgenden Befehle sind mit ziemlicher Sicherheit Root-Berechtigungen erforderlich. Sie müssen sich also entweder als Root anmelden, mit sudo eine Shell mit Root-Berechtigungen abrufen oder jedem Befehl das Präfix sudo hinzufügen.
Überprüfen und mounten Sie das Dateisystem
Verwenden Sie zuerst fsck, um die Strukturen und Inhalte des Zieldateisystems zu überprüfen:
$ fsck /dev/vdc1
Wenn er Probleme mit dem Dateisystem feststellt, beantworten Sie die Fragen entsprechend, um sie zu beheben. Wenn das Dateisystem ernsthaft beschädigt ist, kann es nicht repariert werden. In diesem Fall müssen Sie nach anderen Möglichkeiten suchen, um den Inhalt zu extrahieren.
Erstellen Sie nun ein temporäres Verzeichnis und hängen Sie das Zieldateisystem darin ein:
$ mkdir /tmp/target-rescue $ mount /dev/vdc1 /tmp/target-rescue
Wenn das Dateisystem bereitgestellt ist, führen Sie den Container mit ihm als Root-Dateisystem aus:
$ systemd-nspawn --directory /tmp/target-rescue --boot -- --unit rescue.target
Befehlszeilenargumente zum Starten des Containers:
- --directory / tmp / target-retten liefert den Pfad zum Container-Root-Dateisystem.
- --boot sucht im Root-Dateisystem des Containers nach einem geeigneten Initialisierungsprogramm, startet es und übergibt ihm Parameter über die Befehlszeile. In diesem Beispiel verwendet das Zielsystem auch systemd als PID 1 des Prozesses, sodass die restlichen Parameter dafür bestimmt sind. Wenn das Zielsystem, das Sie wiederherstellen, ein anderes Tool als PID 1 des Prozesses verwendet, müssen Sie die Einstellungen entsprechend konfigurieren.
- - Trennt Parameter für systemd-nspawn von denen, die für PID 1 des Containerprozesses vorgesehen sind.
- --unit recovery.target teilt systemd im Container den Namen des Ziels mit, das während des Startvorgangs erreicht werden soll. Um die Wiederherstellungsvorgänge auf dem Zielsystem zu vereinfachen, starten Sie es im "Wiederherstellungsmodus" und nicht im normalen Mehrbenutzermodus.
Wenn alles gut geht, sollten Sie eine Ausgabe sehen, die ungefähr so aussieht:
Spawning container target-rescue on /tmp/target-rescue. Press ^] three times within 1s to kill container. systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) Detected virtualization systemd-nspawn. Detected architecture arm. Welcome to Debian GNU/Linux 9 (Stretch)! Set hostname to <test>. Failed to install release agent, ignoring: No such file or directory [ OK ] Reached target Swap. [ OK ] Listening on Journal Socket (/dev/log). [ OK ] Started Dispatch Password Requests to Console Directory Watch. [ OK ] Reached target Encrypted Volumes. [ OK ] Created slice System Slice. Mounting POSIX Message Queue File System... [ OK ] Listening on Journal Socket. Starting Set the console keyboard layout... Starting Restore / save the current clock... Starting Journal Service... Starting Remount Root and Kernel File Systems... [ OK ] Mounted POSIX Message Queue File System. [ OK ] Started Journal Service. [ OK ] Started Remount Root and Kernel File Systems. Starting Flush Journal to Persistent Storage... [ OK ] Started Restore / save the current clock. [ OK ] Started Flush Journal to Persistent Storage. [ OK ] Started Set the console keyboard layout. [ OK ] Reached target Local File Systems (Pre). [ OK ] Reached target Local File Systems. Starting Create Volatile Files and Directories... [ OK ] Started Create Volatile Files and Directories. [ OK ] Reached target System Time Synchronized. Starting Update UTMP about System Boot/Shutdown... [ OK ] Started Update UTMP about System Boot/Shutdown. [ OK ] Reached target System Initialization. [ OK ] Started Rescue Shell. [ OK ] Reached target Rescue Mode. Starting Update UTMP about System Runlevel Changes... [ OK ] Started Update UTMP about System Runlevel Changes. You are in rescue mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to boot into default mode. Give root password for maintenance (or press Control-D to continue):
In dieser Ausgabe sehen Sie, dass
systemd als Init-Prozess im Container gestartet wird und feststellt, dass es im Container ausgeführt wird, damit es sein Verhalten entsprechend anpassen kann. Um den Container in einen funktionsfähigen Zustand zu versetzen, werden verschiedene Gerätedateien gestartet und anschließend das Root-Passwort des Zielsystems angefordert. Sie können hier das Root-Passwort eingeben, wenn Sie eine Shell mit Root-Rechten anfordern möchten, oder Sie können
Strg + D drücken, um den Startvorgang fortzusetzen. Daraufhin wird die übliche Eingabeaufforderung für die Konsolenanmeldung angezeigt.
Wenn Sie die erforderlichen Änderungen am Zielsystem vornehmen, drücken Sie dreimal hintereinander
Strg +] . Dadurch wird der Container heruntergefahren und Sie kehren zur ursprünglichen Hülle zurück. Von dort aus können Sie die Bereinigung durchführen, indem Sie das Dateisystem des Zielsystems aushängen und das temporäre Verzeichnis löschen:
$ umount /tmp/target-rescue $ rmdir /tmp/target-rescue
Das ist alles! Jetzt können Sie die Speichergeräte des Zielsystems entfernen und zurückgeben.
Die Idee,
systemd-nspawn auf diese Weise zu verwenden, insbesondere
die Option --boot , kam von einer
Frage, die auf StackExchange veröffentlicht wurde. Vielen Dank an Shibumi und kirbyfan64sos für die hilfreichen Antworten auf diese Frage!Weitere Linux-Ressourcen