[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home] [volume] [parte]


Capitolo 314.   Introduzione all'uso di elaboratori senza disco con un sistema GNU/Linux

Una caratteristica importante del sistema di condivisione dei file system attraverso la rete, l'NFS, è quella che permette l'utilizzo di macchine senza disco: diskless.

Nel passaggio da una macchina autonoma a una senza disco, ci sono varie fasi intermedie, in cui si possono sfruttare più o meno intensivamente le risorse NFS di altri serventi. La macchina senza disco, perché non ha fisicamente il disco fisso, oppure perché non lo adopera per contenere dati o programmi, ha comunque un certo fascino, che si avverte particolarmente quando si deve allestire un gruppo di macchine uniformi e amministrate in modo centralizzato.

A differenza del terminale remoto che utilizza telnet o un programma di comunicazione su linea seriale o dedicata, la macchina senza disco ha il vantaggio di poter utilizzare la grafica con il sistema X. In questo senso, una macchina senza disco è normalmente ben dotata dal punto di vista del processore e della memoria centrale.

314.1   Principio di funzionamento

L'idea alla base della macchina senza disco è molto semplice:

  1. viene caricato il kernel in qualche modo, con tutte le informazioni necessarie ad accedere alla rete e al servente NFS;

  2. viene eseguito l'innesto del file system principale (dalla rete) in lettura e scrittura;

  3. viene eseguita la procedura di inizializzazione del sistema (Init).

Il vero problema di tutto questo è il primo punto, ovvero l'avvio del kernel con le informazioni necessarie, specialmente quelle sull'indirizzo IP dell'interfaccia di rete utilizzata.

Volendo predisporre una vera macchina senza disco, occorrerebbe un firmware appropriato, in mancanza del quale sarebbe necessario realizzare, o procurarsi, una ROM speciale da applicare alla scheda di rete. Questo firmware (già previsto nella scheda madre, o contenuto in una ROM aggiuntiva), attraverso vari protocolli, dovrebbe permettere all'interfaccia di rete di ottenere il proprio indirizzo IP e subito dopo di ricevere il kernel da avviare.

Figura 314.1. Esempio di configurazione di un BIOS per l'avvio attraverso la rete. Non essendo specificato, occorre leggere la documentazione della scheda madre per conoscere che tipo di protocollo viene usato effettivamente.

.------------------------.
| First boot device      |
|------------------------|
| Floppy .......... [ ]  |
| CD/DVD-ROM ...... [ ]  |
| HDD-0 ........... [ ]  |
| HDD-1 ........... [ ]  |
| HDD-2 ........... [ ]  |
| HDD-3 ........... [ ]  |
| USB ............. [ ]  |
| LAN/PXE ......... [X]  |
| Disabled ........ [ ]  |
`------------------------'

Figura 314.2. Una vecchia scheda di rete dove si vede lo zoccolo libero per l'alloggiamento di una memoria ROM aggiuntiva.

nic

A meno di disporre di una scheda madre con interfaccia di rete incorporata e firmware appropriato, oppure di avere il sostegno di persone qualificate, in grado di predisporre la ROM necessaria, ci si accontenta solitamente di preparare un dischetto con un kernel adatto, assieme a tutte le informazioni necessarie sulla rete locale e il servente NFS da raggiungere. Questa è la soluzione che viene presa in considerazione nel capitolo.

314.2   Preparazione del cliente GNU/Linux

La preparazione del cliente cioè del dischetto necessario ad avviare l'elaboratore senza disco fisso, è la parte più semplice, pertanto viene mostrata per prima.

314.2.1   Kernel

Prima di tutto, occorre preparare un kernel adatto alla stazione senza disco che si vuole utilizzare. Di sicuro, occorre attivare la gestione della rete (sezione 67.2.7), la gestione necessaria per l'interfaccia di rete che si utilizza e la gestione relativa all'NFS, indicando eventualmente la necessità di innestare il file system principale attraverso il protocollo NFS (67.2.21).

Naturalmente, tali funzionalità devono essere incluse come elementi del kernel monolitico, perché non disponendo di un disco locare sarebbe complicato caricare dei moduli.

Date le difficoltà che comporta la preparazione di un sistema senza disco è il caso di consigliare l'utilizzo di soli kernel monolitici, anche per i dispositivi che potrebbero essere caricati in un secondo momento.

La stazione senza disco potrebbe, nonostante il nome, dover accedere anche a unità a disco locali, come un dischetto o un lettore CD-ROM. Nel momento in cui si predispone un kernel per tale scopo, è bene tenere presente anche queste esigenze.

314.2.2   Parametri di avvio

All'avvio, il kernel deve ottenere alcuni parametri che gli permettano di configurare l'interfaccia di rete, di definire l'instradamento e di innestare il file system principale attraverso il protocollo NFS.

root=/dev/nfs

Si tratta di un messaggio con cui si informa il kernel di voler utilizzare come file system principale ciò che viene fornito attraverso il protocollo NFS. Il dispositivo /dev/nfs non esiste in realtà.

nfsroot=[ip_del_servente:]directory_radice[,opzione_nfs[,...]]

Serve a definire le informazioni necessarie all'innesto della directory del servente che viene utilizzata come radice del file system. L'indirizzo IP del servente è facoltativo, perché viene indicato nuovamente nel parametro nfsaddrs.

Le opzioni finali, indicate dalla voce opzione_nfs, sono facoltative e, in ogni caso, si tratta delle stesse opzioni utilizzabili in condizioni normali con i file system NFS.

nfsaddrs=[ip_del_cliente]:[ip_del_servente]:[ip_del_router]:[maschera_di_rete]:\
  \[nome_del_nodo]:[dispositivo_di_rete]:[auto_configurazione]

Il parametro nfsaddrs permette di definire tutte le informazioni necessarie a stabilire il collegamento nella rete. Tutte le informazioni possono essere determinate in modo predefinito, ma non tutte contemporaneamente. Come si può intuire: le informazioni sugli indirizzi del cliente e del servente possono essere ottenute automaticamente in base ai protocolli RARP o BOOTP; l'indirizzo di un router non è necessario nel caso tutto si svolga in una rete locale; la maschera di rete può essere determinata automaticamente in base alla classe di indirizzi utilizzati; il nome del nodo di rete potrebbe corrispondere allo stesso numero IP attribuitogli; infine l'interfaccia di rete potrebbe essere semplicemente la prima a essere individuata.

Almeno le prime volte, non è una buona idea lasciare che i valori vengano determinati automaticamente.

L'ultima opzione, permette di definire il metodo di configurazione automatica. Si possono utilizzare le parole chiave rarp o bootp per indicare che si vuole sia utilizzato il protocollo RARP oppure BOOTP, rispettivamente. In alternativa si può indicare la parola chiave both per fare sì che vengano gestiti entrambi, oppure none per non utilizzarne alcuno. Se non viene indicato nulla nell'ultimo campo, si intende che non si deve utilizzare alcun protocollo.

Se non viene utilizzato alcun protocollo per la configurazione automatica, è chiaro che occorre specificare necessariamente gli indirizzi IP del cliente e del servente.

314.2.3   Un esempio

Prima di proseguire con la descrizione di ciò che serve per predisporre un cliente senza disco, conviene introdurre una situazione di esempio, che poi viene utilizzata nelle spiegazioni successive.

Si suppone di disporre di un servente nella stessa rete locale in cui si vuole collocare il cliente. In tal caso, pur non essendo necessario, viene indicato ugualmente un router che in pratica corrisponde allo stesso indirizzo del servente. La tabella 314.3 mostra questa situazione.

Tabella 314.3. Configurazione di esempio.

Elemento Valore
servente 192.168.1.1
cliente 192.168.1.7
router 192.168.1.1
maschera di rete 255.255.255.0
nome del cliente diskless7
interfaccia di rete eth0
directory remota /tftpboot/192.168.1.7

In questa situazione, i parametri del kernel devono essere quelli indicati qui di seguito:

root=/dev/nfs
nfsroot=192.168.1.1:/tftpboot/192.168.1.7
nfsaddrs=192.168.1.7:192.168.1.1:192.168.1.1:255.255.255.0:diskless7:eth0:

La scelta della directory remota da utilizzare come file system principale non è casuale; si tratta di una convenzione diffusa:

/tftpboot/indirizzo_del_cliente/

314.2.4   File di dispositivo «/dev/boot255»

Esistono diversi modi per avviare un kernel. Dovendo fare in modo che il kernel si avvii innestando il file system principale dalla rete, si utilizza il parametro root=/dev/nfs, dove /dev/nfs non esiste in realtà.

Quando si utilizza LILO per l'avvio, ma anche in altre situazioni, è necessario fare riferimento a un dispositivo esistente realmente, almeno nel momento in cui si «installa» il sistema di avvio. Per questo si deve creare il dispositivo denominato /dev/boot255, con numero primario zero e numero secondario 255.

mknod /dev/boot255 c 0 255[Invio]

314.2.5   Avvio del kernel dal dischetto

L'avvio del kernel da un dischetto è un problema semplice da risolvere, descritto eventualmente nel capitolo 49. Qui si intende solo riepilogare in che modo configurare i vari sistemi di avvio.

314.3   Preparazione del servente GNU/Linux

Il servente richiede una preparazione più complessa e delicata, da studiare prima a tavolino in funzione delle cose che si vogliono fare con le macchine senza disco. Il problema, a questo proposito, risiede nel fatto che ogni distribuzione GNU/Linux ha una sua impostazione, dove sono proprio queste diversità che richiedono lo sforzo maggiore nello studio necessario ad arrivare a un servente per questo scopo.

Ogni distribuzione GNU/Linux dovrebbe fornire gli strumenti necessari ad automatizzare la creazione e la gestione del servente; in realtà solo poche fanno tanto.

314.3.1   Pianificare gli obiettivi da raggiungere

È importante decidere prima quali sono le attività per le quali devono essere utilizzate le stazioni senza disco e quindi quali programmi si intendono utilizzare. Ciò serve per stabilire quali componenti devono essere predisposti nella gerarchia utilizzata come directory radice NFS.

È bene chiarire in mente che i clienti dovrebbero avere una configurazione uniforme e che su quelle stazioni non ci dovrebbero essere utenti root, a parte l'amministratore del servente. Se non fosse così, i vantaggi nell'utilizzo di macchine senza disco sarebbero troppo pochi per giustificare lo sforzo necessario a predisporle.

Se si intende utilizzare il sistema grafico X, anche l'uniformità delle schede video sarebbe auspicabile.

Le parole d'ordine oscurate non dovrebbero essere utilizzate.

Come ultima considerazione, i clienti non dovrebbero offrire servizi di rete.

314.3.2   Directory radice NFS

La cosa più delicata da organizzare è la directory radice dei clienti senza disco. Queste directory, per tradizione (e per stare fuori dai guai), vanno collocate a partire da /tftpboot/indirizzo/. Per fare un esempio, il cliente individuato dall'indirizzo IP 192.168.1.7, dovrebbe trovare la sua directory radice a partire dalla directory /tftpboot/192.168.1.7/ del servente.

Generalmente se ne prepara una per un cliente particolare; una volta verificato che tutto funziona come si vuole, si preparano le altre utilizzando dei collegamenti fisici. Se tutto va bene, non ci dovrebbe essere bisogno di modificare la configurazione riferita a un cliente particolare, rispetto agli altri.

La directory radice NFS di ogni cliente deve contenere il necessario a permettere l'avvio del cliente stesso, lasciando che il resto venga innestato durante la fase di inizializzazione del sistema. In pratica, sono necessarie le directory bin/, dev/, etc/, home/, lib/, mnt/, opt/, proc/, root/, sbin/, tmp/, usr/ e var/. Alcune di queste vanno copiate, così come sono le directory corrispondenti del file system principale del servente, altre servono vuote, altre vanno copiate solo parzialmente.

Nella spiegazione seguente si fa l'esempio della predisposizione della directory radice NFS per il cliente 192.168.1.7; tutte le directory degli altri clienti vengono poi ottenute attraverso l'uso di collegamenti fisici, a partire dall'esempio di partenza.

Si inizia creando la directory /tftpboot/ e quindi la directory /tftpboot/192.168.1.7/.

mkdir /tftpboot[Invio]

mkdir /tftpboot/192.168.1.7[Invio]

Si prosegue copiando alcune directory così come sono nel servente (è meglio non fare collegamenti ai file utilizzati dal sistema del servente) e creando altre directory vuote.

cp -dpRv /bin /tftpboot/192.168.1.7[Invio]

cp -dpRv /dev /tftpboot/192.168.1.7[Invio]

cp -dpRv /etc /tftpboot/192.168.1.7[Invio]

mkdir /tftpboot/192.168.1.7/home[Invio]

cp -dpRv /lib /tftpboot/192.168.1.7[Invio]

mkdir /tftpboot/192.168.1.7/mnt[Invio]

mkdir /tftpboot/192.168.1.7/opt[Invio]

mkdir /tftpboot/192.168.1.7/proc[Invio]

mkdir /tftpboot/192.168.1.7/root[Invio]

cp -dpRv /sbin /tftpboot/192.168.1.7[Invio]

mkdir /tftpboot/192.168.1.7/tmp[Invio]

chmod 1777 /tftpboot/192.168.1.7/tmp[Invio]

mkdir /tftpboot/192.168.1.7/usr[Invio]

cp -dpRv /var /tftpboot/192.168.1.7[Invio]

A questo punto si rifinisce un po'.

Dopo quanto descritto sulla directory var/, potrebbe essere utile proporre una struttura di esempio, come guida per la scelta su cosa sia da eliminare o meno.

var
|-- cache/
|-- catman/
|   |-- X11/
|   |   |-- cat1/
|   |   |-- cat2/
|   |   ...
|   |-- cat1/
|   |-- cat2/
|   ...
|   `-- local/
|       |-- cat1/
|       |-- cat2/
|       ...
|-- dhcpd/
|-- lib/
|   `-- texmf/
|       |-- fonts/
|       `-- texfonts/
|-- local/
|-- lock/
|   `-- subsys/
|-- log/
|   |-- cron/
|   |-- dmesg/
|   |-- maillog/
|   |-- messages/
|   |-- secure/
|   `-- spooler/
|-- nis/
|-- preserve/
|-- run/
|   `-- netreport/
|-- spool
|   |-- at/
|   |   `-- spool/
|   |-- cron/
|   |-- lpd/
|   |   |-- lp/
|   |   |   |
|   |   ...  ...  (dipende se si vuole gestire la stampa)
|   |-- mail/
|   |-- mqueue/
|   `-- rwho/
`-- tmp -> /tmp

Come si può osservare nell'esempio, si è scelto di fare in modo che var/tmp sia un collegamento simbolico alla directory tmp/, per non perdere il controllo sulla proliferazione dei file temporanei.

314.3.3   Directory radice NFS da usare come base di partenza

È stato indicato che basta predisporre una directory radice per un cliente senza disco e poi le altre per gli altri clienti possono essere ottenuti a partire da quella, con una serie di collegamenti fisici. Questo è vero in parte. Quando si utilizza anche una sola volta il cliente di esempio, vengono creati una serie di file amministrativi, temporanei, nella directory var/ (e nelle sue sottodirectory). Questi file vengono cancellati quando non servono più, oppure vengono sostituiti, ma questo non avviene regolarmente alla conclusione dell'attività. Questi file non possono essere condivisi tra i vari clienti e quindi non se ne può fare il collegamento.

Ecco quindi che diviene necessario predisporre una directory radice NFS standard che non sia utilizzata direttamente da alcun cliente e che serva per generare le altre.

La directory standard va preparata congiuntamente a quella del primo cliente utilizzato come prova del buon funzionamento della directory radice NFS. Quando si cambia qualcosa nella directory del cliente, lo si deve fare anche in quella standard, se questa modifica non si riflette già automaticamente per effetto di eventuali collegamenti fisici.

Per avere un riferimento con gli esempi, si stabilisce che la directory radice NFS standard sia /tftpboot/standard/.

314.3.4   Procedura di inizializzazione del sistema

Il problema più grosso da risolvere è la procedura di inizializzazione del sistema. A partire dal file etc/inittab è necessario analizzare tutto quello che succede nella propria distribuzione GNU/Linux e intervenire in modo da permettere l'avvio dei clienti senza disco.

Prima di farlo, si deve fare mente locale alla situazione che si ha di fronte: il kernel dei clienti provvede da solo a definire l'indirizzo dell'interfaccia di rete e a instradarsi verso il servente; inoltre innesta da solo il file system principale attraverso il protocollo NFS. Quindi, la procedura di inizializzazione del sistema non ha alcuna necessità, né la possibilità di eseguire un controllo del file system principale e nemmeno di altri dischi; inoltre non deve configurare la rete, che è già configurata.

A questo si può aggiungere il fatto che sarebbe meglio eliminare la gestione dei moduli del kernel, in modo da avere un problema in meno a cui badare; inoltre, è meglio evitare l'uso di memoria virtuale.

314.3.5   Servizi e demoni

Un'altra cosa a cui fare attenzione, sono i demoni avviati nei clienti. Bisogna ridurli al minimo indispensabile, anche in considerazione del fatto che è improbabile l'attivazione di servizi su dei clienti senza disco.

314.3.6   Configurazione di «etc/fstab»

Il file etc/fstab utilizzato dai clienti senza disco va predisposto in modo da innestare ciò che manca dopo il file system principale di tipo NFS. Si tratta delle directory proc/, usr/, opt/ e home/; la prima in modo predefinito, la seconda e la terza in sola lettura, mentre la quarta anche in scrittura. Se si vogliono utilizzare dischetti e CD-ROM nei clienti, è il caso di predisporre i punti di innesto rispettivi. L'esempio seguente dovrebbe essere chiaro a sufficienza, tenendo conto che si riferisce al nodo di rete identificato dall'indirizzo IP 192.168.1.7.

192.168.1.1:/tftpboot/192.168.1.7   /            nfs     defaults        0 0
none                                /proc        proc    defaults        0 0
192.168.1.1:/usr                    /usr         nfs     ro              0 0
192.168.1.1:/opt                    /opt         nfs     ro              0 0
192.168.1.1:/home                   /home        nfs     defaults        0 0
/dev/fd0                            /mnt/floppy  ext2    user,noauto     0 0
/dev/fd0                            /mnt/a       vfat    user,noauto     0 0
/dev/cdrom                          /mnt/cdrom   iso9660 user,noauto,ro  0 0

Si può intendere quindi che anche la directory mnt/ deve essere organizzata opportunamente.

L'indicazione esplicita del file system principale va fatta per permettere la chiusura corretta del funzionamento quando si avvia la procedura di arresto del sistema. Infatti, il file system principale è già innestato quando il sistema legge questo file all'avvio.

314.3.7   Esportazione del file system nel servente

Perché la gestione degli elaboratori clienti senza disco possa funzionare, occorre evidentemente che il servente consenta l'accesso al proprio file system attraverso il protocollo NFS. Si tratta, in pratica, di configurare correttamente il file /etc/exports e quindi di riavviare i demoni che ne permettono l'uso.

Seguendo gli esempi già visti, il modo più corretto per configurare tale file dovrebbe essere il seguente:

/tftpboot       192.168.1.0/255.255.255.0(rw,no_root_squash)
#
/usr    192.168.1.0/255.255.255.0(ro,squash_uids=0-100,squash_gids=1-80)
/opt    192.168.1.0/255.255.255.0(ro,squash_uids=0-100,squash_gids=1-80)
/home   192.168.1.0/255.255.255.0(rw,no_root_squash)
#
/lib    192.168.1.0/255.255.255.0(ro,squash_uids=0-100,squash_gids=1-80)
/bin    192.168.1.0/255.255.255.0(ro,squash_uids=0-100,squash_gids=1-80)
/sbin   192.168.1.0/255.255.255.0(ro,squash_uids=0-100,squash_gids=1-80)
/etc    192.168.1.0/255.255.255.0(ro,squash_uids=0-100,squash_gids=1-80)
/mnt    192.168.1.0/255.255.255.0(ro,squash_uids=0-100,squash_gids=1-80)
/var    192.168.1.0/255.255.255.0(ro,squash_uids=0-100,squash_gids=1-80)

Dagli esempi mostrati in questo capitolo, è indispensabile la condivisione delle sole directory /tftpboot/, /usr/, /opt/ e /home/. Tuttavia, le altre directory indicate potrebbero essere utili, ed è meglio prevederne subito la condivisione.

Purtroppo, i demoni che gestiscono il servizio NFS potrebbero non essere in grado di interpretare correttamente la sintassi dell'esempio mostrato, per quanto questa sia corretta. Se si notano difficoltà, si può rimediare accontentandosi della configurazione seguente, dove il dominio brot.dg corrisponde a quello utilizzato nella rete 192.168.1.0/255.255.255.0.

/tftpboot       *.brot.dg(rw,no_root_squash)
#
/usr    *.brot.dg(ro)
/opt    *.brot.dg(ro)
/home   *.brot.dg(rw,no_root_squash)
#
/lib    *.brot.dg(ro)
/bin    *.brot.dg(ro)
/sbin   *.brot.dg(ro)
/etc    *.brot.dg(ro)
/mnt    *.brot.dg(ro)
/var    *.brot.dg(ro)

314.3.8   Attivazione di un nuovo cliente

Per attivare un nuovo cliente basta riprodurre la directory radice NFS standard, creando solo collegamenti fisici, come nell'esempio seguente, in cui si suppone di aggiungere il cliente 192.168.1.77.

cp -ldpR /tftpboot/standard /tftpboot/192.168.1.77[Invio]

In questo modo vengono copiate le directory, mentre i file vengono riprodotti come collegamenti.

314.3.9   Memoria virtuale

In questo capitolo è stato ignorato volutamente il problema della memoria virtuale. Per attivare la sua gestione, le macchine usate come cliente dovrebbero avere un disco fisso e in tal senso dovrebbe essere modificata la procedura di inizializzazione del sistema.

314.4   Riferimenti


Appunti di informatica libera 2008 --- Copyright © 2000-2008 Daniele Giacomini -- <appunti2 (ad) gmail·com>


Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome introduzione_all_x0027_uso_di_elaboratori_senza_disco_con_un.htm

[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home]

Valid ISO-HTML!

CSS validator!

Gjlg Metamotore e Web Directory