Centralizzare le risorse e distribuirle attraverso la rete. Con questa soluzione free è possibile.
Un server Linux dà la possibilità di sperimentare e provare le situazioni più diverse a costi contenuti o, se si esclude l’hardware, praticamente nulli, comprese applicazioni di rete relativamente oscure e poco diffuse che però possono avere diversi aspetti interessanti e utili.
Il boot in remoto di macchine diskless per esempio è una di queste applicazioni che, pur essendo fondamentalmente un’idea per certi versi datata, può tornare utile per particolari soluzioni, come la realizzazione di terminali X a basso costo utilizzando hardware di riciclo, o la gestione e il mantenimento di reti di macchine omogenee centralizzando tutto il carico di lavoro derivante dall’amministrazione del sistema e del software su un singolo server principale.
L’univocità
del boot remoto
Ma cosa significa boot in remoto di un computer? Per effettuare il boot via rete un pc diskless deve avere, e quindi ottenere sempre via rete, un’identità univoca, un sistema operativo e un filesystem funzionante.
Come? Andiamo con ordine e consideriamo in prima istanza una singola workstation diskless sul nostro segmento di rete, equipaggiata quindi con una scheda Ethernet e, di conseguenza, univocamente riconoscibile dal suo mac-address. All’accensione tale macchina, non equipaggiata di hard disk, può solo accedere in qualche modo ai servizi di rete per ottenere quanto necessario per il boot.
La prima informazione che deve ricavare è un indirizzo di rete IP che la identifichi, cosi da poter successivamente richiedere l’immagine del kernel e l’accesso al suo filesystem; per far ciò, in fase di accensione, istruita o con una ROM installata sulla scheda di rete, o con un’analoga immagine su floppy, la workstation effettua un broadcast notificando a un qualsiasi server BOOTP (BOOTstrap Protocol) o DHCP presente nel segmento di rete il suo mac-address.
A questo broadcast il server BOOTP, dopo aver consultato una tabella interna, risponde fornendo alla workstation diskless un nome simbolico, un indirizzo IP, l’indirizzo IP del server da cui effettuare il boot e il nome di un’immagine del kernel che dovrà caricare.
Una volta ottenute queste informazioni il client deve scaricare il kernel indicatogli ed eseguirlo: in questa fase entra in gioco il TFTP (Trivial File Transfer Protocol), una versione ridotta del più conosciuto FTP, priva di autenticazione, controlli e funzionalità complesse. Proprio utilizzando il protocollo TFTP il client scarica dal server fornitogli dal BOOTP il suo kernel.
Eseguito il kernel cosi ottenuto ora non resta che montare un filesystem via rete, solitamente un filesystem NFS per sistemi operativi unix-like, e terminare la sequenza di boot del sistema.
Etherboot per gestire
le immagini
Esistono diversi software per la creazione delle immagini per il boot di macchine diskless, siano esse da installare sulla ROM della scheda ethernet o semplicemente copiare su floppy; per il nostro scopo abbiamo scelto di utilizzare etherboot, un pacchetto free che supporta buona parte delle schede Ethernet in commercio. Una volta decompresso e compilato, editando eventualmente il makefile nel caso siano necessarie configurazioni particolari, si deve identificare il modulo adatto alla scheda di rete del pc diskless, e creare il floppy di boot con il comando:
cat floppyload.bin 3c509.lzrom > /dev/fd0
in questo modo, oltre all’immagine vera e propria (in questo caso per una scheda 3com 509), viene copiato sul floppy un piccolo loader di 512 byte nel blocco di boot.
Se ora si prova ad effettuare il boot dal floppy appena creato con le due macchine (client e server) in rete, è possibile vedere, utilizzando un analizzatore di traffico di rete sul server come tcpdump o ethereal, i broadcast periodici che il pc diskless invia in attesa di una risposta da un server di boot.
Resta quindi da configurare correttamente il server di boot di modo risponda alle richieste del client, via BOOTP, e successivamente gli fornisca il kernel in TFTP. Dando per già installati sul server entrambi i demoni di rete necessari, si edita quindi il file /etc/inetd.conf inserendo, o decommentando, le seguenti righe:
bootps dgram udp wait root /usr/sbin/tcpd bootpd
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd -s /tftpboot
cosi che a una richiesta di uno dei due servizi, il super server inetd possa richiamare il giusto demone.
Ora occorre creare il file /etc/bootptab, il database con cui il BOOTP associa a ogni macchina, riconoscendola dal suo mac-address, e quindi univocamente, un insieme minimo di attributi, come il nome, l’indirizzo IP che dovrà venirle assegnato e il kernel che dovrà caricare ed eseguire. Un’entry minimale del bootptab per associare a un terminale diskless con macaddress 006108C7A3D8 l’indirizzo IP 192.168.0.100 e il nome term.mio.org, indicandogli inoltre di utilizzare il kernel vmlinuz.term avrà la seguente forma:
term.mio.org:ha=006108C7A3D8:ip=192.168.0.100:bf=/tftpboot/vmlinuz.term
Abbiamo cosi definito come il server di boot deve identificare, in realtà “creare l’identità”, il client, e quale kernel deve richiedere via TFTP; naturalmente questo kernel non sarà lo stesso del server, anzi, oltre a dover per forza avere il supporto per filesystem NFS, così da poter montare in remoto un filesystem di root funzionante, dovrà avere attiva l’opzione per ricevere l’IP da un server BOOTP e avere un immagine del kernel particolare, detta tagged image. Questa è un’immagine con un particolare header che indica al netloader dove caricare in memoria il kernel che sta ricevendo e a che indirizzo di memoria deve cominciarne l’esecuzione; per crearla si utilizza un utility di nome mknbi-linux, anch’essa contenuta nel package di etherboot.
Il filesystem
arriva alla fine
A questo punto l’unico componente che resta da fornire al client è un filesystem di root, filesystem che il kernel, una volta in esecuzione, si aspetta di trovare via NFS in /tftpboot/192.168.0.100. Si crea quindi il file /etc/exports sul server contenente la riga:
/tftpboot/192.168.0.100 term.mio.org(rw,no_root_squash)
che associa al nome simbolico della macchina client la directory da esportare come root, in modalità lettura-scrittura, prevenendo il rimappaggio dell’Id di root (attributo no_root_squash). Attivando ora tutti i demoni necessari sul server, facendo ripartire l’inetd e assicurandosi di aver attivi i servizi NFS (rpc.mountd, rpc.portmap), e provando a reboottare il client, il kernel dovrebbe esser in grado di montare il filesystem di root, in cui si saranno precedentemente copiate tutte le dir necessarie (/bin /sbin /etc /var), e mostrare il prompt di login.
