Da quando sono esistiti i sistemi GNU/Linux, gli amministratori di sistema hanno dovuto eseguire il ripristino dal danneggiamento del filesystem di root, da modifiche accidentali alla configurazione o da altre situazioni che impedivano al sistema di avviarsi in uno stato "normale".
Le distribuzioni Linux in genere offrono una o più opzioni di menu all'avvio (ad esempio, nel menu di GRUB) che possono essere utilizzate per salvare un sistema danneggiato; in genere avviano il sistema in modalità utente singolo con la maggior parte dei servizi di sistema disabilitati. Nel peggiore dei casi, l'utente potrebbe modificare la riga di comando del kernel nel bootloader per utilizzare la shell standard come processo init (PID 1). Questo metodo è il più complesso e irto di complicazioni, che possono portare a frustrazione e perdita di tempo quando un sistema deve essere salvato.
Più risorse Linux
- Comandi Linux cheat sheet
- Cheat sheet sui comandi avanzati di Linux
- Corso online gratuito:Panoramica tecnica RHEL
- Cheat sheet della rete Linux
- Cheat sheet di SELinux
- Cheat sheet dei comandi comuni di Linux
- Cosa sono i container Linux?
- I nostri ultimi articoli su Linux
Ancora più importante, questi metodi presuppongono tutti che il sistema danneggiato abbia una console fisica di qualche tipo, ma questo non è più scontato nell'era del cloud computing. Senza una console fisica, ci sono poche (se presenti) opzioni per influenzare il processo di avvio in questo modo. Anche le macchine fisiche possono essere piccoli dispositivi incorporati che non offrono una console di facile utilizzo, trovano i cavi e gli adattatori della porta seriale appropriati e configurano un emulatore di terminale seriale, il tutto per utilizzare una porta della console seriale mentre si ha a che fare con un emergenza, è spesso complicato.
Quando è disponibile un altro sistema (della stessa architettura e configurazione generalmente simile), una tecnica comune per semplificare il processo di riparazione consiste nell'estrarre i dispositivi di archiviazione dal sistema danneggiato e collegarli al sistema funzionante come dispositivi secondari. Con i sistemi fisici, questo è generalmente semplice, ma anche la maggior parte delle piattaforme di cloud computing può supportarlo poiché consentono di montare il volume di archiviazione radice dell'istanza danneggiata su un'altra istanza.
Una volta che il filesystem di root è stato collegato a un altro sistema, affrontare il danneggiamento del filesystem è semplice utilizzando fsck e altri strumenti. Affrontare errori di configurazione, pacchetti danneggiati o altri problemi può essere più complesso poiché richiedono il montaggio del filesystem e l'individuazione e la modifica dei file di configurazione o dei database corretti.
Utilizzo di systemd
Prima di sistemato , la modifica dei file di configurazione con un editor di testo era un modo pratico per correggere una configurazione. Individuare i file necessari e comprenderne il contenuto può essere una sfida separata, che va oltre lo scopo di questo articolo.
Quando il sistema GNU/Linux usa systemd tuttavia, è meglio apportare molte modifiche alla configurazione utilizzando gli strumenti che fornisce:l'abilitazione e la disabilitazione dei servizi, ad esempio, richiede la creazione o la rimozione di collegamenti simbolici in varie posizioni. Il systemctl strumento viene utilizzato per apportare queste modifiche, ma il suo utilizzo richiede un systemd istanza in esecuzione e in ascolto (su D-Bus) per le richieste. Quando il filesystem di root viene montato come filesystem aggiuntivo su un'altra macchina, il systemd in esecuzione l'istanza non può essere utilizzata per apportare queste modifiche.
Avvio manuale del systemd del sistema di destinazione non è nemmeno pratico, poiché è progettato per essere il processo PID 1 su un sistema e gestire tutti gli altri processi, che sarebbero in conflitto con l'istanza già in esecuzione sul sistema utilizzato per le riparazioni.
Per fortuna, sistema di sistema ha la capacità di avviare container, sistemi GNU/Linux completamente incapsulati con il proprio PID 1 e un ambiente che utilizza varie funzionalità dello spazio dei nomi offerte dal kernel Linux. A differenza di strumenti come Docker e Rocket, systemd non richiede un'immagine del contenitore per avviare un contenitore; può avviarne uno rootato in qualsiasi punto del filesystem esistente. Questo viene fatto utilizzando systemd-nspawn strumento, che creerà gli spazi dei nomi di sistema necessari e avvierà il processo iniziale nel contenitore, quindi fornirà una console nel contenitore. In contrasto con chroot , che cambia solo la radice apparente del filesystem, questo tipo di contenitore avrà uno spazio dei nomi di filesystem separato, filesystem adatti montati su /dev , /corri e /proc e uno spazio dei nomi di processo separato e spazi dei nomi IPC. Consulta systemd-nspawn pagina man per saperne di più sulle sue capacità.
Un esempio per mostrare come funziona
In questo esempio, il dispositivo di archiviazione contenente il filesystem radice del sistema danneggiato è stato collegato a un sistema in esecuzione, dove appare come /dev/vdc . Il nome del dispositivo varia in base al numero di dispositivi di archiviazione esistenti, al tipo di dispositivo e al metodo utilizzato per collegarlo al sistema. Il filesystem di root potrebbe utilizzare l'intero dispositivo di archiviazione o trovarsi in una partizione all'interno del dispositivo; poiché la configurazione più comune (semplice) colloca il filesystem di root nella prima partizione del dispositivo, questo esempio utilizzerà /dev/vdc1. Assicurati di sostituire il nome del dispositivo nei comandi seguenti con il nome del dispositivo corretto del tuo sistema.
Il filesystem radice danneggiato può anche essere più complesso di un singolo filesystem su un dispositivo; può essere un volume in un set di volumi LVM o su un set di dispositivi combinati in un dispositivo RAID software. In questi casi, i passaggi necessari per comporre e attivare il dispositivo logico che contiene il filesystem devono essere eseguiti prima che sia disponibile per il montaggio. Anche in questo caso, questi passaggi esulano dallo scopo di questo articolo.
Prerequisiti
Innanzitutto, assicurati che il systemd-nspawn strumento è installato:la maggior parte delle distribuzioni GNU/Linux non lo installa per impostazione predefinita. È fornito dal systemd-container pacchetto sulla maggior parte delle distribuzioni, quindi usa il gestore di pacchetti della tua distribuzione per installare quel pacchetto. Le istruzioni in questo esempio sono state testate utilizzando Debian 9 ma dovrebbero funzionare in modo simile su qualsiasi distribuzione GNU/Linux moderna.
L'uso dei comandi seguenti richiederà quasi sicuramente i permessi di root, quindi dovrai accedere come root, utilizzare sudo per ottenere una shell con permessi di root o anteporre a ciascuno dei comandi sudo .
Verifica e monta il fileystem
Per prima cosa, usa fsck per verificare le strutture e il contenuto del filesystem di destinazione:
$ fsck /dev/vdc1Se rileva problemi con il filesystem, rispondi alle domande in modo appropriato per correggerli. Se il filesystem è sufficientemente danneggiato, potrebbe non essere riparabile, nel qual caso dovrai trovare altri modi per estrarne il contenuto.
Ora, crea una directory temporanea e monta il filesystem di destinazione su quella directory:
$ mkdir /tmp/target-rescue
$ mount /dev/vdc1 /tmp/target-rescue
Con il filesystem montato, avvia un contenitore con quel filesystem come filesystem radice:
$ systemd-nspawn --directory /tmp/target-rescue --boot -- --unit rescue.targetGli argomenti della riga di comando per avviare il contenitore sono:
- --directory /tmp/target-rescue fornisce il percorso del filesystem radice del contenitore.
- --avvio cerca un programma init adatto nel filesystem radice del contenitore e lo lancia, passandogli i parametri dalla riga di comando. In questo esempio, il sistema di destinazione utilizza anche systemd come processo PID 1, quindi i parametri rimanenti sono destinati a tale processo. Se il sistema di destinazione che stai riparando utilizza qualsiasi altro strumento come processo PID 1, dovrai regolare i parametri di conseguenza.
- -- separa i parametri per systemd-nspawn da quelli destinati al processo PID 1 del contenitore.
- --unit rescue.target dice a systemd nel contenitore il nome della destinazione che dovrebbe cercare di raggiungere durante il processo di avvio. Per semplificare le operazioni di salvataggio nel sistema di destinazione, avvialo in modalità "rescue" anziché nella sua normale modalità multiutente.
Se tutto va bene, dovresti vedere un output simile a questo:
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 questo output, puoi vedere systemd avviandosi come processo init nel contenitore e rilevando che viene eseguito all'interno di un contenitore in modo da poter regolare il proprio comportamento in modo appropriato. Vengono avviati vari file di unità per portare il contenitore a uno stato utilizzabile, quindi viene richiesta la password di root del sistema di destinazione. Puoi inserire la password di root qui se vuoi un prompt della shell con i permessi di root, oppure puoi premere Ctrl+D per consentire la continuazione del processo di avvio, che visualizzerà una normale richiesta di accesso alla console.
Dopo aver completato le modifiche necessarie al sistema di destinazione, premi Ctrl+] tre volte in rapida successione; questo terminerà il contenitore e ti riporterà alla shell originale. Da lì, puoi ripulire smontando il filesystem del sistema di destinazione e rimuovendo la directory temporanea:
$ umount /tmp/target-rescue
$ rmdir /tmp/target-rescue
Questo è tutto! Ora puoi rimuovere i dispositivi di archiviazione del sistema di destinazione e restituirli al sistema di destinazione.
L'idea di utilizzare systemd-nspawn in questo modo, in particolare il --boot parametro , proveniva da una domanda pubblicata su StackExchange. Grazie a Shibumi e kirbyfan64sos per aver fornito risposte utili a questa domanda!