Siete tranquilli e beati a letto che sognate per i fatti vostri quando squilla il telefono: è il vostro capo ed è nel panico perché l'ufficio non ha la connessione ad internet. Impossibile, direte voi, mica tanto ribatto io: il mio capo è famoso per lavorare ad orari assurdi.
Cosa fare? Sapete da prove fatte in remoto che il vostro ISP va che è una bellezza, solo l'indirizzo pubblico del vostro gateway è irragiungibile. Dovete approntare in fretta un gateway alternativo, caricarlo in auto e installarlo in ufficio mentre cercate di capire cos'ha che non va il gateway abituale.
Ora mi direte che basta prendere un quasiasi PC di recupero, un CD di una distribuzione live, un po' di magia con iptables e tutto è risolto. E avreste ragione, ma proviamo a complicare un po' le cose: invece di un PC prendiamo una Sun Ultra 1 (http://en.wikipedia.org/wiki/Ultra_1) con due schede di rete ma senza monitor e aggiungiamoci un servizio di DHCP con un DNS aggiornato da questo e mettiamoci pure un disco rigido SCSI da 300 Megabyte.
A questo punto gli adepti di Ubuntu sbattono le palpebre e piegano la testa di lato cercando di ponderare l'imponderabile (ovvero che esistano processori diversi da quelli di intel o compatibili e che c'è stata un'era in cui l'USB non esisteva) mentre gli adepti di Debian scaricheranno il CD per l'installazione su SPARC salvo poi scoprire che non hanno un lettore CD esterno SCSI per la Ultra 1...
So cosa state pensando: "costui è più pazzo del suo capo". Non lo negherò, ma vi dico che una simile situazione disperata ha una soluzione ed è pure una soluzione elegante! Si tratta del boot da rete unito ad un'installazione testuale effettuata mediante link seriale. Il sistema operativo che useremo per operare questo piccolo miracolo sarà OpenBSD (http://www.openbsd.org).
"Cos'è? Un'altra distribuzione Linux? Perché io uso $DISTRO che è la migliore di tutte: ha sempre tutto aggiornato, non si rompe mai e con il suo gestore di pacchetti..." e lo sappiamo che $DISTRO è bella, $DISTRO è figa, $DISTRO è l'unica Vera Via. Installala su una piattaforma non supportata e poi ne parliamo. C'è una buona probabilità che la tua distribuzione preferita non supporti ufficialmente niente che non sia un PC con processori intel o compatibili. "Ma Linux gira su tutte le architetture! C'è anche sui cellulari!". Linux, il kernel, probabilmente sì (dubito che ci sia un port di Linux su VAX, ma potrei sbagliarmi) ma un kernel da solo non basta: occorre la libreria standard di C, un compilatore che giri nativamente e poi si potrà cominciare a compilare le utility standard. Un lavoraccio che la maggiorparte delle distribuzioni non si sobbarca: hanno già abbastanza problemi con i PC.
OpenBSD non è Linux: non si tratta una distribuzione che impacchetta il kernel, le utility di sistema di GNU, qualche server grafico (X.org di solito, ma ultimamente mi dicono sia di moda usare qualcos'altro) qualche window manager e propone il tutto come la Soluzione Definitiva a Tutti i Problemi della fascia di utenza a cui è rivolta. OpenBSD è un sistema operativo realizzato da estremisti che privilegiano le cose fatte bene rispetto a quelle che semplicemente funzionano ("It Just Works!(tm)"). Questo vuol dire che se potranno scegliere tra un software GPL e un software con licenza MIT/ISC/3BSD sceglieranno il software non-GPL e si daranno da fare per migliorarlo perché sono convinti che la licenza GPL sia troppo restrittiva, questo vuol dire che hanno un ciclo di rilascio semestrale che è REALMENTE semestrale (senza sgarrare: se quella feature non è pronta la si elimina dal branch della release e la si rimanda alla prossima), questo vuol dire che se ci sono dei grossi cambiamenti da fare vengono fatti nel corso di diverse release, oppure vengono annunciati per tempo e viene documentato cosa cambierà per gli utenti che migreranno da una release alla successiva e in ogni caso non ci saranno cambiamenti apportati per il solo gusto di cambiare le cose. Inoltre OpenBSD è self-hosted su TUTTE architetture supportate, questo vuol dire che il sistema è attivamente sviluppato e compilato sulle piattaforme supportate che si tratti di i386, x86-64, VAX, SUN SHARP Zaurus, appliance di rete basate su processori ARM o PPC... Molti progetti multipiattaforma ricorrono alla cross-compilation (che spesso è l'unica maniera di ottenere immagini eseguibili in tempi ragionevoli) ma secondo il fondatore del progetto, Theo DeRaadt, non c'è maniera migliore di verificare la robustezza e la solidità del sistema che metterlo sotto sforzo ricompilando la base di codice del sistema operativo nella sua interezza. Caricare un'immagine compilata su un'altra piattaforma e lasciare una vecchia macchina "ferma" a fare da router/firewall non stressa abbastanza i sottosistemi del kernel e non espone alcuni bug che potrebbero essere causa di cadute di servizio, se non peggio.
"Cosa intendi dire con 'OpenBSD è un Sistema Operativo'? Linux non è già un OS?". Linux è un kernel, ovvero la parte di un Sistema Operativo che si interfaccia con hardware e firmware, che enumera le risorse che questi ultimi mettono a disposizione, che le arbitra tra le varie applicazioni e che offre ad esse numerosi servizi (come l'astrazione dei dati mediante file system oppure la possibilità di creare nuovi processi, avviare altre applicazioni e comunicare con esse). Un kernel fa molte cose ma, ad esempio, non scarica e non visualizza una pagina web direttamente. Un kernel non estrae un file contenente un'immagine BMP da un altro file codificato come un archivio ZIP. Un kernel non si mette direttamente in ascolto sulla porta TCP 22, non interroga il database degli utenti a seguito di una richiesta di connessione, non apre un nuovo terminale per l'utente remoto. C'è bisogno di altro software per fare queste cose, software che non ha bisogno di accedere direttamente all'hardware e che può compiere operazioni anche complesse con la garanzia che ci sono dei meccanismi sottostanti che, si spera, eviteranno le catastrofi peggiori.
Un semplice utente può tranquillamente ignorare tutto questo e vivere felice, uno sviluppatore dovrà, prima o poi, approfondire la sua conoscenza di questi meccanismi o avrà una vita grama durante il debug dei suoi software. Per un amministratore di sistema questo è pane quotidiano.
"Vuoi dire che un amministratore di sistema è un Semidio prossimo all'Onniscenza?". Assolutamente NO! Ma il lavoro di un amministratore di sistema è PREVENIRE e RISOLVERE i problemi e più ne sa del sistema meglio saprà svolgere il suo lavoro.
Mi rendo conto di essermi dilungato un po' troppo (e di aver buttato abbastanza secchiate di escrementi su abbastanza gente) per cui vi rimando al prossimo articolo in cui riprenderemo la storia del nostro eroe alle prese con la Sun Ultra 1.
Nessun commento: