Sabato sono andato ad aiutare con un po’ di manutenzione di un laboratorio di una scuola dotato di computer vecchiotti riportati in vita con Linux Mint.
In base alle mie esperienze avute finora con le diverse distribuzioni Linux, fare l’aggiornamento da Linux Mint Rosa a Linux Mint Sarah mi è sembrata una buona idea.
In effetti su due-tre macchine è andato tutto liscio, ma in una si è verificato un problema: l’aggiornamento si è interrotto, non so ancora il motivo preciso, e il successivo riavvio non si è mai completato, a causa di un Kernel Panic.
A peggiorare la situazione poi c’era un altro mix di fattori:
- non mi ero portato la mia attrezzatura solita (computer, chiavette varie etc…), quindi non avevo alcun modo di avviare un ambiente di rispristino
- era sabato alle 10:30 di mattina, un’ora dopo avevo un impegno e lunedì sarei stato a decine di km di distanza
- in quel computer c’erano dei dati che sarebbero serviti ad inizio della settimana.
La soluzione allora è stata di sfruttare il server SSH della mia Raspberry Pi, accessibile da Internet, e una live dotata di server e client SSH configurati in modo da fare reverse SSH - la live della salvezza per l’appunto. Avendo una shell nel PC guasto, il recupero dei file diventa triviale e far ripartire la postazione non è più un miraggio.
La mia distribuzione preferita è Debian e, grazie al progetto Debian Live, crearne un’immagine live personalizzata non è troppo difficile.
Se usate Debian stessa, o una sua derivata (compresa Ubuntu e discendenti), l’unico pacchetto richiesto è live-build, che può essere installato come al solito in un modo molto semplice:
apt install --no-install-recommends live-build
A questo punto, da utente, creiamo l’ambiente di lavoro con il seguente comando:
mkdir directory-target cd directory-target lb config
Il primo passo della nostra personalizzazione è l’installazione di SSH: creiamo il file config/package-lists/ssh.list.chroot, con questo contenuto:
autossh openssh-server openssh-client
autossh è un programma che avvia e monitora un processo di SSH in modo che riavvii la sessione in caso essa venga interrotta, cosa assolutamente necessaria per il nostro scopo.
Su GitHub esiste poi uno script per demonizzare il tutto, che tra l’altro è anche già configurato per il nostro identico scopo. Scarichiamolo e adattiamolo alle nostre esigenze! Dalla directory base della live diamo:
mkdir -p config/includes.chroot/etc/init.d # Creiamo le directory dove salvare il tutto cd config/includes.chroot/etc/init.d wget https://gist.github.com/suma/8134207/raw/8248dff3c572d25782039e55e15856e5bbd4179b/_etc_init.d_autosshd -O autossh chmod 755 autossh
Il file autossh va innanzitutto modificato per inserire il nostro host e una porta valida per il port forward (la 90022 specificata a linea 35 va oltre il limite dei 16 bit destinati alle porte).
Poi dobbiamo creare una coppia chiave pubblica-privata priva di passphrase per permettere il login passwordless al server SSH ponte (quello della Raspberry Pi, per intenderci).
Io, per esempio, ho creato la cartella config/includes.chroot/etc/autosshpiero e lì ho creato con le solite modalità una chiave RSA:
mkdir config/includes.chroot/etc/autosshpiero cd config/includes.chroot/etc/autosshpiero ssh-keygen -t rsa -b 4096 -C "live_salvezza" chmod 644 id_rsa* # Altamente insicuro, in questo caso lo facciamo solo per praticità
Il file sarà visto dalla live come /etc/autosshpiero/id_rsa. Dobbiamo andare a inserirle nella variabile DAEMON_ARGS, come parametro -i.
Manca però anche un altro parametro, che potrebbe far subdolamente fallire il nostro demone: la live non conosce la fingerprint del nostro server SSH ponte. Le alternative sono due: o creiamo in qualche modo un known hosts, oppure, come ho fatto io, aggiungiamo alla DAEMON_ARGS un parametro che dica a SSH di ignorare il problema.
DAEMON_ARGS=" -M 0 [...] -i /etc/autosshpiero/id_rsa [...] -o StrictHostKeyChecking=no"
Col prossimo passo aggiungiamo il demone allo startup.
La “buona pratica” prevederebbe la creazione di un hook usato da lb, tuttavia ci ho provato e ho sprecato invano 3 costruzioni di live. Quindi la mia strategia è stata la creazione manuale dei collegamenti simbolici al file autossh:
cd config/includes.chroot/etc # dalla directory racide della live
mkdir rc{0,1,2,3,4,5,6}.d
for i in 0 1 6; do ln -s ../init.d/autossh rc$i.d/K01autossh; done
for i in 2 3 4 5; do ln -s ../init.d/autossh rc$i.d/S50autossh; done
Se doveste riuscire invece a usare gli hook fatemi sapere nei commenti 😊 .
Siamo quasi pronti alla costruzione. Il penultimo passo richiede la copia di una nostra chiave pubblica di SSH, in quanto la configurazione di default della live abilita solo questo tipo di autenticazione.
La cartella che ci viene in aiuto in questo caso e dobbiamo creare noi è config/includes.chroot/etc/skel.
Tutti i file e le directory presenti in questa directory verranno copiati automaticamente nella home degli utenti al momento della loro creazione, compresa l’eventuale directory .ssh e il suo file authorized_keys. Andiamolo dunque a creare e a metterci dentro la nostra chiave pubblica:
mkdir -p config/includes.chroot/etc/skel/.ssh cp ~/.ssh/id_rsa.pub config/includes.chroot/etc/skel/.ssh/authorized_keys # Usa la chiave pubblica (già esistente) dell'utente che crea la live
Infine, copiando spudoratamente dal manuale, abilitiamo alcune configurazioni standard di Debian Live: la creazione dell’utente, il suo login automatico alla console tty1 e sudo.
Creiamo il file config/package-lists/recommends.list.chroot con il seguente contenuto:
live-tools user-setup sudo
Non dobbiamo più creare altri file, adesso basta che costruiamo l’immagine vera e propria. Questo passo deve essere eseguito da root:
lb build
La procedura ci impiegherà un po’, a seconda della velocità della vostra connessione, dell’unità su cui create la live (SSD o HDD) e del processore (per le installazioni e la creazione del filesystem squash).
Se il procedimento avrà successo verrà creato il file live-image-amd64.hybrid.iso (o eventualmente al posto di amd64 ci sarà un’altra architettura da voi scelta). Vi consiglio caldamente di provarlo in una macchina virtuale prima di provarlo su una macchina reale: nel mio caso ha evidenziato diversi problemi che hanno portato alla stesura di quest’articolo.
Se avete QEMU/KVM è molto semplice:
kvm -m 1G -cdrom live-image-amd64.hybrid.iso # Con la RAM si può scendere fino ad un minimo di 300MB
Ottenuta un’immagine funzionante, potremo masterizzarla o scriverla direttamente su una chiavetta USB con dd o con tool grafici più user friendly, come il gestore dischi di GNOME.