Quanto siete ‘affezionati’ alla vostra installazione Linux? Ci pensate due volte prima di reinstallare da zero?
Nonostante sia impossibile sapere con certezza se sia un record assoluto, un’installazione Debian del 1993 ha tutte le carte in regola per essere un buon candidato.
Stiamo parlando di chiark, un host protagonista di una sequenza di upgrade molto singolare e a cui probabilmente vi sarete connessi anche voi se avete mai scaricato PuTTY, il popolare client SSH e telnet open-source per Windows originariamente sviluppato da Simon Tatham.
I protagonisti di questa storia sono Debian, la versatilità di Linux e Ian Jackson, l’avventurierio esecutore materiale di una serie di upgrade a cui non capita tutti i giorni di assistere, ovvero dalla suddetta installazione fatta nel ’93 alla attuale Debian 11 (Bullseye).
A rendere tutto ancora più interessante, come se portarsi dietro per quasi trent’anni la stessa installazione Debian non fosse sufficiente, vi è un salto di architettura da 32 a 64 bit.
Sebbene il signor Jackson non sia esattamente un utente qualunque, essendo egli uno sviluppatore Debian di lunga data con un pedigree di tutto rispetto nonché, nel 1998, Project Leader del progetto Debian stesso, il fatto che un upgrade path del genere sia non solo stato tecnicamente possibile ma sia anche stato completato sempre con successo mantenendo la stessa installazione per 3 decenni è sicuramente cosa degna di nota.
Basta tutto ciò per catturare la vostra attenzione? Bene, sappiate che oltre ad avere una configurazione di raid + lvm decisamente poco convenzionale, tutto ciò è stato fatto da remoto, senza alcuna visita in loco.
Vi sono state difficoltà tecniche? Assolutamente si, ma niente è impossibile se ci si ostina a sufficienza, no? Mettetevi comodi perchè ,come immaginerete, se vi è stato dedicato un post su un blog, si è trattato di qualcosa di più di un semplice apt full-upgrade -y.
Come ci racconta Ian nel suo blog, la macchina in oggetto si trova in un data center a Londra su cui sono presenti all’incirca 200 account utente, diversi siti web e mailing list e altri servizi relativi a USENET. Quotando direttamente dal blog, la macchina fu configurata già dal principio per richiedere il minor intervento sistemistico esterno possibile:
chiark’s internal setup is designed to enable my users to do a maximum number of exciting things with a minimum of intervention from me. (Ian Jackson)
Il sistema operativo che Ian ha installato su quella macchina fu appunto Debian 0.93R5, ovvero la prima Debian che poteva essere aggiornata senza una reinstallazione completa. Da notare che non parliamo di una macchina fisica, in quanto l’hardware è stato cambiato più volte nel tempo (ricordiamo che nel 1993 i processori del momento erano fondamentalmente questi ed erano single core da 100 Mhz o meno), ma di un’istanza virtualizzata dello stesso ‘host’ la cui l’installazione è rimasta la stessa.
Il primo grosso upgrade fu nel 2016, quando venne portata a Debian 8 (Jessie), che è stata supportata ufficialmente fino al 2020 e che, tecnicamente, lo sarà ancora fino al 2025 grazie a Freexian, ma l’esigenza di spostarsi all’architettura a 64bit oltre che quella di avere una distro ‘fresca’, per quanto stiamo comunque parlando di Debian e non di Arch Linux, iniziavano a farsi sentire sempre di più.
Il successivo step fu, quindi, esattamente questo, saltando tutte le release di mezzo ed evitando di fare upgrade a versioni già obsolete. Questo approccio non era necessariamente il meno rischioso, in quanto l’upgrade path più testato è, generalmente, quello dalla versione direttamente precedente, ma fu scelto il male minore e si rivelò anche un notevole risparmio di tempo. Meno tempo impiegato, meno upgrade da fare, meno chance che qualcosa vada storto.
La parte di upgrade relativa all’architettura hardware, però, è stata meno ‘banale’, se così si può definire quanto appena detto. Il problema di fondo, a detta di Ian, è che, sebbene tool come dpkg supportino bene la cosa, non si può dire lo stesso per i frontend di più alto livello come apt, i quali possono portare non pochi problemi. Che si fa, allora?
The approach, generally, has been to set the system up to “want to” be the new architecture, run apt in a download-only mode, and do the package installation manually, with some fixing up and retrying, until the system is coherent enough for apt to work.
This is the approach I took.
Come ci spiega Ian, per aggirare il problema, si è dovuta percorrere la strada impervia del dover installare un bel pò di pacchetti a mano, almeno fino a che il gestore automatico di pacchetti apt non fosse in grado di riprendere il testimone.
Come immaginerete, gestire le dipendenze durante le installazioni manuali non è stata un’operazione semplice ma, alla fine, nulla è impossibile con un pò di pazienza e se si hanno le dovute risorse. Ian si è aiutato usando il suo laptop come seconda macchina su cui fare le prove, una volta portato lì il backup più recente di chiark e facendo ampio uso di chroot.
Ricordate che tutto ciò avveniva in remoto? Per avere un minimo di “piano B” durante gli upgrade, serviva una qualche immagine da cui fare il boot nel caso qualcosa andasse storto. Fortuna volle che, alla porta USB di quell’host, fosse ancora connessa una vecchia chiavetta da 2GB da cui si poteva fare un eventuale boot di un sistema alternativo. Dopo una verifica che tale installazione di emergenza su chiavetta USB funzionasse ancora e facesse ancora il boot (perchè, ricordiamo, avere un piano B non testato non è molto diverso dal non averlo proprio), si è proceduto a fare in live le operazioni che, sul laptop di cui parlavamo poco fa, erano state testate e andavano a buon fine.
Non sono mancati problemi con mdadm e RAID, su cui poggiava tutta l’installazione, ma dopo alcune ore Ian otteneva un sistema funzionante, con Debian 11 e architettura 64 bit.
Ogni upgrade, però, anche uno banale da una release alla successiva, può portare problemi inattesi con gli applicativi installati e, difatti, Ian descrive nel dettaglio problemi con exim4, python, usenet. Un’altra area critica sembrava essere la sua scelta di implementare LVM su RAID su LVM, la quale ha portato alla luce un caso limite di LVM che, di default, ha un approccio conservativo e non prova a utilizzare PV (volumi fisici) che risiedano a loro volta su un LVM perchè, verosimilmente, potrebbero essere i dischi di macchine virtuali.
La cosa, però, non era immediatamente chiara ed è risultata apparente solo dopo un aiuto provvidenziale ricevuto durante una chat su IRC, che è arrivato proprio mentre Ian stava per iniziare un lungo studio del file /etc/lvm/lvm.conf.
Vi sono stati altre difficoltà tecniche, principalmente legate agli applicativi specifici che girano su chiark e che potete leggere nel blog di Ian, ma supponiamo vi siate già fatti un’idea e, per oggi, ci fermiamo qui.
Oggi chiark gira con Debian 11 a 64bit e non tutti i problemi tecnici sono stati risolti. Il software, nel tempo, si evolve e non sempre è possibile garantire la compatibilità con applicativi legacy, tantomeno per lassi di tempo misurati in decenni. Anche qui, la coperta è corta e il compromesso è quello tra rimanere ancorati al passato pur di mantenere la compatibilità o accettare l’evoluzione, abbracciare altri paradigmi e approcci diversi di fare le cose e versioni recenti del software.
La coerenza, nel tempo, di un sistema operativo e la garanzia che applicativi vecchi di decenni funzionino ancora è sicuramente una virtù ma qual’è la soglia oltre il quale ciò diventa un ostacolo?
Lasciamo a voi la riflessione, per adesso. Almeno fino al prossimo upgrade di chiark.
English (US)