<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Diskless Nodes HOW-TO document for Linux: Introduzione al boot via rete e all'Etherboot</TITLE>
<LINK HREF="Diskless-HOWTO-8.html" REL=next>
<LINK HREF="Diskless-HOWTO-6.html" REL=previous>
<LINK HREF="Diskless-HOWTO.html#toc7" REL=contents>
</HEAD>
<BODY>
<A HREF="Diskless-HOWTO-8.html">Avanti</A>
<A HREF="Diskless-HOWTO-6.html">Indietro</A>
<A HREF="Diskless-HOWTO.html#toc7">Indice</A>
<HR>
<H2><A NAME="s7">7. Introduzione al boot via rete e all'Etherboot</A></H2>
<P>Questo capitolo è stato scritto da Ken Yap
<A HREF="mailto:ken.yap@acm.org">ken.yap@acm.org</A> e spiega come avviare
il proprio computer da un programma immagazzinato in una memoria
non volatile senza accedere al proprio disco rigido. È una tecnica
ideale per gestire e configurare una "fattoria" di macchine linux.
<H2><A NAME="ss7.1">7.1 Cos'è il boot via rete?</A>
</H2>
<P>Il boot via rete è una vecchia idea; l'idea di base è che il computer
abbia un qualche codice di bootstrap nella memoria non volatile, cioè un
chip ROM, che gli permetterà di contattare un server per ottenere i file
di sistema attraverso un collegamento di rete.
<H2><A NAME="ss7.2">7.2 Come funziona</A>
</H2>
<P>Perché sia possibile un boot attraverso la rete il computer deve ricevere:
<OL>
<LI>un'identità,</LI>
<LI>un'immagine del sistema operativo e,</LI>
<LI>di solito, un file system funzionante.</LI>
</OL>
<P>Consideriamo un computer diskless (DC) che abbia una ROM per il boot via
rete. Potrebbe essere uno di vari DC identici, come possiamo distinguere
questo computer dagli altri? C'è una informazione che è unica per quel
computer (in realtà per il suo adattatore di rete) ed è il suo indirizzo
Ethernet. Ogni adattatore Ethernet nel mondo ha un indirizzo Ethernet
univoco di 48 bit; ciò perché ad ogni costruttore di hardware Ethernet
sono stati assegnati dei blocchi di indirizzi. Per convenzione tali
indirizzi sono scritti con cifre esadecimali, con i due punti che separano
ogni gruppo di due cifre; ad esempio: <B>00:60:08:C7:A3:D8</B>.
<P>I protocolli usati per ottenere un indirizzo IP, dato un indirizzo
Ethernet, sono chiamati <B>Boot Protocol (BOOTP)</B> e <B>Dynamic Host
Configuration Protocol</B> (<B>DHCP</B>, protocollo di configurazione
dinamica dell'host). DHCP è una evoluzione di BOOTP. Nella nostra
discussione, salvo ove diversamente specificato, tutto ciò che si applica
a BOOTP vale anche per DHCP (in realtà dire che BOOTP e DHCP traducono
solo indirizzi Ethernet è una piccola bugia; nella loro lungimiranza, i
progettisti hanno dato a BOOTP e DHCP la possibilità di funzionare con
qualsiasi tipo di indirizzo hardware, ma Ethernet è quello che verrà
usato nella maggioranza dei casi).
<P>Un esempio di scambio BOOTP funziona così:
<P><B>DC:</B> Salve, il mio indirizzo hardware è <B>00:60:08:C7:A3:D8</B>,
per favore dammi il mio indirizzo IP.
<P><B>server BOOTP:</B> (guardando nel database degli indirizzi) Il tuo nome
è aldebaran, il tuo indirizzo IP è 192.168.1.100, il tuo server è
192.168.1.1, il file da cui effettuare il boot è /tftpboot/vmlinux.nb (più
qualche altra informazione).
<P>Ci si potrebbe chiedere come ha fatto il DC a trovare l'indirizzo del
server BOOTP la prima volta. La risposta è che non l'ha fatto; la
richiesta BOOTP è stata diffusa in broadcast sulla rete locale e
qualsiasi server BOOTP in grado di rispondere lo ha fatto.
<P>Dopo aver ottenuto un indirizzo IP, il DC deve scaricare l'immagine di
un sistema operativo ed eseguirlo. Qui viene usato un altro protocollo
Internet chiamato <B>Trivial File Transfer Protocol</B> (<B>TFTP</B> -
protocollo elementare per il trasferimento file). Il TFTP è una specie di
versione ridotta dell'FTP --- non c'è autenticazione e funziona sullo User
Datagram Protocol (UDP) invece che sul Transmission Control Protocol (TCP).
È stato scelto l'UDP al posto del TCP per via della sua semplicità;
l'implementazione dell'UDP sul DC può essere abbastanza piccola da
riuscire facilmente a farne entrare il codice in una ROM.
Visto che l'UDP è un codice orientato ai blocchi, al contrario di uno
orientato al protocollo, il trasferimento avviene blocco per blocco, in
questo modo:
<P>
<BLOCKQUOTE><CODE>
<PRE>
DC: Dammi il blocco 1 di /tftpboot/vmlinux.nb.
server TFTP: Eccolo.
DC: Dammi il blocco 2.
</PRE>
</CODE></BLOCKQUOTE>
<P>...e così via, finché non viene trasferito l'intero file. L'handshaking è
basato su una semplice conferma di ogni blocco e la perdita di pacchetti
è gestita ritrasmettendo dopo un timeout. Quando sono stati ricevuti tutti
i pacchetti la ROM di boot della rete passa il controllo all'entry point
dell'immagine del sistema operativo.
<P>Concludendo, per poter eseguire un sistema operativo deve essere fornito
un filesystem principale. Il protocollo usato da Linux e da altri Unix di
solito è il <B>Network File System</B> (<B>NFS</B> - file system di
rete), sebbene siano possibili altre scelte. In questo caso il codice non
deve risiedere nella ROM ma può essere parte del sistema operativo che si
è appena scaricato. Comunque il sistema operativo deve essere capace di
girare con un file system principale che sia un NFS invece che un vero
disco. Linux ha le variabili di configurazione necessarie per compilare
una versione che possa farlo.
<P>
<H2><A NAME="ss7.3">7.3 Il boot via rete in pratica</A>
</H2>
<P>Il Net Loader è un programmino che gira come estensione del BIOS, di
solito su una EPROM nel NIC. Esso gestisce le richieste BOOTP e i
caricamenti TFTP e poi trasferisce il controllo all'immagine caricata.
Usa i protocolli TCP/IP ma l'immagine caricata non deve necessariamente
essere Linux; può essere qualunque cosa, anche DOS.
Possono anche essere caricate da un floppy per effettuare delle prove
o per provare impostazioni temporanee.
<P>Oltre alle ROM di boot commerciali ci sono <B>DUE</B> fonti di pacchetti
per il boot via rete.
Implementazioni libere (free) di loader per reti TCP/IP sono:
<OL>
<LI><B>ETHERBOOT</B>
<A HREF="http://www.slug.org.au/etherboot">http://www.slug.org.au/etherboot</A> e</LI>
<LI><B>NETBOOT</B>
<A HREF="http://www.han.de/~gero/netboot.html">http://www.han.de/~gero/netboot.html</A></LI>
</OL>
<P>Etherboot usa driver interni, Etherboot invece usa packet driver.
Innanzi tutto bisogna accertarsi che la propria scheda di rete sia
supportata da Etherboot o da Netboot.
Eventualmente bisognerà trovare una persona disposta a mettere il codice
in una EPROM (Erasable Programmable Read Only Memory) al posto proprio,
ma all'inizio si può effettuare il <B>boot via rete da un floppy</B>.
<P>Per creare un floppy di boot nella distribuzione viene fornito uno
speciale blocco di boot. Questo piccolo programma di 512 byte carica
in memoria i blocchi del disco che lo seguono nel floppy e inizia
l'esecuzione. Quindi, per fare un floppy di boot, uno deve solo
concatenare il blocco di boot con il binario Etherboot contenente il
driver per una scheda di rete, in questo modo:
<P>
<HR>
<PRE>
# cat floppyload.bin 3c509.lzrom > /dev/fd0
</PRE>
<HR>
<P>Si prenda il pacchetto nfdboot (disponibile presso il proprio sito mirror
Linux preferito nella directory /pub/Linux/system/Linux-boot).
Esso contiene una immagine bootprom per le schede di rete (come la wd8013)
che può essere scritta direttamente. Vedere anche il sito LTSP presso
<A HREF="http://www.ltsp.org">http://www.ltsp.org</A>.
<P>Prima di inserire il floppy per il boot via rete bisogna preparare tre
servizi su Linux:
<OL>
<LI>BOOTP (o DHCP)</LI>
<LI>TFTP e</LI>
<LI>NFS.</LI>
</OL>
<P>Non è necessario prepararli tutti e tre contemporaneamente, si può farlo
un passo alla volta, accertandosi che ogni passo funzioni prima di passare
al successivo.
<P>
<P>
<H3>Bootp</H3>
<P>Si installi Bootp. Vedere bootp*.rpm sul cdrom Redhat Linux.
Vedere anche i pacchetti RPM sul sito LTSP presso
<A HREF="http://www.ltsp.org">http://www.ltsp.org</A>.
Vedere anche le pagine di manuale unix 'man 5 bootptab', 'man 8 bootpd',
'man 8 bootpef', 'man 8 bootptest'.
Bisogna poi assicurarsi che il server stia aspettando richieste bootp.
Il demone può essere lanciato direttamente col comando
<P>
<HR>
<PRE>
bootpd -s
</PRE>
<HR>
<P>oppure usando inetd; si editi il file /etc/inetd.conf e si inserisca
una riga come la seguente:
<P>
<HR>
<PRE>
bootps dgram udp wait root /usr/sbin/in.bootpd bootpd
</PRE>
<HR>
<P>Inserire o togliere il commento dalle seguenti due righe in /etc/services:
<P>
<HR>
<PRE>
bootps 67/tcp # server BOOTP
tftp 69/udp # server TFTP
</PRE>
<HR>
<P>Se si è dovuto modificare /etc/inetd.conf allora è necessario far
ripartire inetd inviando al processo il segnale HUP.
<P>
<HR>
<PRE>
kill -HUP <id del processo inetd>
</PRE>
<HR>
<P>Poi, bisogna dare a bootp un database per mappare gli indirizzi Ethernet
con indirizzi IP. Questo database è in /etc/bootptab.
Bisogna modificarlo inserendo gli indirizzi IP del proprio gateway,
del server dns e gli indirizzi ethernet delle proprie macchine diskless.
Il database contiene righe aventi la forma:
<P>
<HR>
<PRE>
aldebaran.foo.com:ha=006008C7A3D8:ip=192.168.1.100:bf=/tftpboot/vmlinuz.nb
</PRE>
<HR>
<P>Possono essere specificate altre informazioni, ma cominceremo nel modo
facile.
<P>Un altro esempio di /etc/bootptab è:
<P>
<HR>
<PRE>
global.prof:\
:sm=255.255.255.0:\
:ds=192.168.1.5:\
:gw=192.168.1.19:\
:ht=ethernet:\
:bf=linux:
machine1:hd=/export/root/machine1:tc=global.prof:ha=0000c0863d7a:ip=192.168.1.140:
machine2:hd=/export/root/machine2:tc=global.prof:ha=0800110244e1:ip=192.168.1.141:
machine3:hd=/export/root/machine3:tc=global.prof:ha=0800110244de:ip=192.168.1.142:
</PRE>
<HR>
<P>global.prof è una generica traccia per le voci di host, in cui:
<P>
<UL>
<LI>il campo sm contiene la maschera di sottorete</LI>
<LI>il campo ds contiene l'indirizzo del Domain Name Server</LI>
<LI>il campo gw contiene l'indirizzo predefinito del gateway</LI>
<LI>il campo ht contiene il tipo di hardware del supporto di rete</LI>
<LI>il campo bf contiene il nome del file di boot</LI>
</UL>
<P>Dopo di che, ogni macchina deve avere una riga in cui:
<P>
<UL>
<LI>il primo campo contiene il nome dell'host</LI>
<LI>il campo hd contiene la directory del file di boot</LI>
<LI>la traccia globale può essere inclusa nel campo tc</LI>
<LI>il campo ha contiene l'indirizzo hardware della scheda ethernet</LI>
<LI>il campo ip contiene l'indirizzo ip assegnato</LI>
</UL>
<P>Ora si faccia il boot del DC col floppy e questi dovrebbe rilevare la
propria scheda Ethernet e diffondere una richiesta BOOTP. Se tutto va
bene il server dovrebbe rispondere al DC con l'informazione richiesta.
Poiché /tftpboot/vmlinux.nb ancora non esiste, quando proverà a caricare
il file fallirà. Ora occorre compilare un kernel speciale, uno in cui sia
abilitata l'opzione per montare il filesystem principale dal NFS.
Bisogna anche abilitare l'opzione per prendere l'indirizzo IP del kernel
dalla risposta BOOTP originale. Si deve compilare il driver Linux per
il proprio adattatore di rete dentro al kernel, invece che caricarlo come
modulo. È possibile scaricare un ramdisk iniziale di modo che il
caricamento dei moduli funzioni, ma questo è qualcosa che si può fare
in seguito.
<P>Non si può installare direttamente la zImage risultante dalla compilazione
del kernel, deve essere prima convertita in una immagine marcata. Una
immagine marcata è una normale immagine del kernel con un header speciale
che dice al bootloader di rete dove vanno i byte nella memoria e da
quale indirizzo iniziare il programma. Per creare tale immagine marcata
va usato un programma chiamato mknbi-linux. Questa utility si trova nella
distribuzione Etherboot. Dopo che è stata generata l'immagine la si metta
nella directory /tftpboot col nome specificato in /etc/bootptab. Si renda
tale file leggibile da tutti perché il server tftp non ha privilegi
speciali.
<P>
<P>
<H3>Tftp</H3>
<P>Riguardo TFTP, vedere tftp*.rpm sul cdrom Redhat Linux.
Il TFTP (Trivial File Transfer Protocol) è un protocollo per il
trasferimento di file, come ftp ma molto più semplice, il che è
d'aiuto per codificarlo nelle EPROM. TFTP può essere usato in due modi:
<P>
<UL>
<LI><B>tftp semplice:</B> significa che il client può accedere al vostro
intero file system. È il più semplice ma è anche un grosso buco di
sicurezza (chiunque può prendere il vostro file con le password via tftp).</LI>
<LI><B>tftp sicuro:</B> il server tftp usa una chiamata di sistema
chroot.2 per cambiare la sua directory di root. Qualsiasi cosa al di
fuori della nuova directory di root sarà completamente inaccessibile.
Visto che la directory chroot diventa la nuova directory di root, l'hd
indicato in bootptab deve riflettere la nuova situazione. Ad esempio:
quando si usa il tftp insicuro, il campo hd conterrà il path completo
per la directory di boot, cioè /export/root/machine1. Quando si usa il
tftp sicuro con /export come directory di root, allora /export diventa
/ e il campo hd dovrà essere /root/machine1.</LI>
</UL>
<P>Tftpd viene di solito avviato da inetd con una riga in /etc/inetd.conf
simile alla seguente:
<P>
<HR>
<PRE>
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd -s /tftpboot
#tftp dgram udp wait root /usr/sbin/in.tftpd tftpd /export
</PRE>
<HR>
<P>Di nuovo, si riavvii inetd con un segnale HUP e si riprovi il boot;
stavolta dovrebbe scaricare l'immagine del kernel ed eseguirla.
Si otterrà che il boot va avanti fino al punto in cui prova a montare un
filesystem principale. A questo punto per procedere bisogna configurare
ed esportare le partizioni NFS.
<P>
<P>
<H3>Filesystem principale NFS</H3>
<P>Per vari motivi, non è una buona idea usare il filesystem principale del
server come filesystem principale dei DC. Il primo semplicemente è che lì
ci sono diversi file di configurazione e in quel modo il DC prenderà
l'informazione sbagliata. Un altro è la sicurezza; è pericoloso
permettere l'accesso in scrittura alla root del server (e, per diversi
motivi, l'accesso in scrittura al filesystem principale è indispensabile).
Comunque la buona notizia è che un filesystem principale per il DC non è
molto grande, solo 30 MB circa, e buona parte di esso può essere
condiviso fra più DC.
<P>Idealmente, per costruire un filesystem principale bisogna sapere quali
file si aspetta di vedere lì la vostra distribuzione del sistema operativo.
Per il boot sono cruciali i file di device, quelli in /sbin e in /etc.
È possibile evitare gran parte del lavoraccio copiando un filesystem
principale esistente e modificando alcuni file per il DC.
Nella distribuzione Etherboot c'è un tutorial ed alcuni link ad un paio
di script di shell che servono per creare un tale filesystem principale
per il DC partendo da un filesystem principale esistente su un server.
Nella documentazione di Etherboot ci sono anche dei suggerimenti su come
risolvere i problemi, visto che questa è spesso la parte più insidiosa
della preparazione.
<P>Il kernel Linux fatto su misura per il DC si aspetta di vedere il
filesystem principale in /tftpboot/(indirizzo IP del DC), ad esempio:
/tftpboot/192.168.1.100 nel suddetto caso. Ciò, volendo, può essere
modificato durante la configurazione del kernel.
<P>Ora si crei, o si modifichi, /etc/exports sul server e si aggiunga una
riga così fatta:
<P>
<HR>
<PRE>
/tftpboot/192.168.1.100 aldebaran.foo.com(rw,no_root_squash)
</PRE>
<HR>
<P>L'accesso rw è necessario per vari servizi di sistema. L'attributo
no_root_squash impedisce al sistema NFS di mappare l'ID del root
su un altro. Se questi non è specificato vari demoni e generatori
di log non saranno contenti.
<P>Si avviino, o riavviino, i servizi NFS (rpc.portmap e rpc.mountd) e
si riprovi il boot senza dischi. Se va tutto bene il kernel dovrebbe
essere in grado di montare un filesystem principale e proseguire il boot
fino al prompt di login. Più probabilmente ci si accorgerà che ci sono
diverse cose non configurate a dovere. La maggior parte delle
distribuzioni Linux sono orientate verso le operazioni su disco e
necessitano di un po' di modifiche per andar bene per un boot diskless.
La più comune causa di fallimento è dovuta al fatto che il processo di
boot fa affidamento ai file sotto /usr, che di solito viene importata da
un server più tardi nel processo di boot. Due possibili soluzioni sono:
<P>
<OL>
<LI>Fornire i pochi file richiesti sotto una piccola directory /usr sul
filesystem principale, che verrà poi sovrascritta quando verrà importato
/usr;</LI>
<LI>Modificare il path in modo che cerchi i file nel filesystem principale.
I file da modificare sono sotto /tftpboot/192.168.1.100 (si ricordi che
questa è la directory principale del DC).</LI>
</OL>
<P>Si potrebbero voler montare altre directory dal server, come /usr (che
può essere esportata in sola lettura).
<P>
<P>
<H3>Scrivere la EPROM</H3>
<P>Quando si è riusciti ad effettuare il boot dalla rete senza nessun
problema, si potrebbe voler mettere il codice in una EPROM.
<H2><A NAME="ss7.4">7.4 Utilizzi del boot via rete</A>
</H2>
<P>I terminali X sono un naturale utilizzo del boot via rete. La mancanza
di dischi sul terminale lo rende più silenzioso e contribuisce a rendere
piacevole l'ambiente di lavoro. La macchina idealmente dovrebbe avere
16MB o più di memoria e la miglior scheda video che si riesce a trovargli.
Questo è l'utilizzo ideale per un 486 di fascia alta, o un Pentium di
fascia bassa, che è diventato obsoleto a causa dell'evoluzione dell'hardware.
Altri usano il boot via rete per cluster di macchine in cui l'uso del DC
è leggero e non giustifica la presenza di un disco; ad esempio un cluster
di macchine in un'aula scolastica.
<H2><A NAME="ss7.5">7.5 Per maggiori informazioni</A>
</H2>
<P>Il primo posto in cui fermarsi è la home page di Etherboot:
<A HREF="http://www.slug.org.au/etherboot">http://www.slug.org.au/etherboot</A><P>Lì si troveranno link ad altre risorse, inclusa una mailing list a cui
iscriversi, in cui vengono discussi problemi e soluzioni.
<P>Documenti correlati:
<P>
<UL>
<LI>NFS-root Mini Howto, in /usr/doc/HOWTO/mini o sul cdrom Linux.</LI>
<LI>Linux Networking-HOWTO di Terry Dawson, in /usr/doc/HOWTO o sul cdrom
Linux
<A HREF="mailto:94004531@postoffice.csu.edu.au">94004531@postoffice.csu.edu.au</A></LI>
<LI>NET-3-Howto, in /usr/doc/HOWTO o sul cdrom Linux.</LI>
<LI>/usr/src/linux/README riguardo la configurazione e la compilazione
di nuovi kernel.</LI>
</UL>
<HR>
<A HREF="Diskless-HOWTO-8.html">Avanti</A>
<A HREF="Diskless-HOWTO-6.html">Indietro</A>
<A HREF="Diskless-HOWTO.html#toc7">Indice</A>
</BODY>
</HTML>
