[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]

Capitolo 351.   Diskless: elaboratori senza disco

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 certo numero 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.

351.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 il montaggio 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, sarebbe necessario realizzare, o procurarsi, una ROM speciale da applicare alla scheda di rete. Questa, con il software contenuto al suo interno, attraverso vari protocolli, dovrebbe permettere alla scheda di rete di ottenere il proprio indirizzo IP e subito dopo di ricevere il kernel da avviare.

A meno di avere il sostegno di persone qualificate, in grado di predisporre una macchina senza disco a tutti gli effetti, 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.

351.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.

351.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 29.2.9), la gestione necessaria per l'interfaccia di rete che si utilizza (sezione 29.2.12) e la gestione relativa all'NFS, indicando eventualmente la necessità di montare il file system principale attraverso il protocollo NFS (29.2.9).

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.

351.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 montare 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 al montaggio della directory del servente che verrà utilizzata come radice del file system. L'indirizzo IP del servente è facoltativo, perché viene indicato nuovamente nel parametro nfsaddrs.

Le opzioni_NFS sono facoltative e, in ogni caso, si tratta delle stesse opzioni utilizzabili in condizioni normali con i file system NFS (il modello sintattico viene spezzato in due per mancanza di spazio).

nfsaddrs=[ip_del_cliente]:[ip_del_servente]:[ip_del_router]:[maschera_di_rete]:<-'
`->[nome_dell'host]:[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 potrà 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 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.

351.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 verrà 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 351.1 mostra questa situazione.

Tabella 351.1. 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 dovranno 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/

351.2.4   /dev/boot255

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

Quando si utilizza LILO, 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

351.2.5   Avvio del kernel dal dischetto

L'avvio del kernel da un dischetto è un problema che è stato già descritto a sufficienza in questo documento, in particolare nel capitolo 16. Qui si intende solo riepilogare in che modo configurare i vari sistemi di avvio.

351.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.

In queste sezioni si fa riferimento a un servente realizzato su una distribuzione Red Hat, ma senza porre un accento eccessivo sulle particolarità di questa distribuzione.

351.3.1   Pianificare gli obiettivi da raggiungere

È importante decidere prima quali sono le attività per le quali verranno utilizzate le stazioni senza disco e quindi quali programmi verranno utilizzati. Ciò servirà 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 password shadow non dovrebbero essere utilizzate.

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

351.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 sarà 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 montato 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 verranno 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

# mkdir /tftpboot/192.168.1.7

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

# cp -dpRv /dev /tftpboot/192.168.1.7

# cp -dpRv /etc /tftpboot/192.168.1.7

# mkdir /tftpboot/192.168.1.7/home

# cp -dpRv /lib /tftpboot/192.168.1.7

# mkdir /tftpboot/192.168.1.7/mnt

# mkdir /tftpboot/192.168.1.7/opt

# mkdir /tftpboot/192.168.1.7/proc

# mkdir /tftpboot/192.168.1.7/root

# cp -dpRv /sbin /tftpboot/192.168.1.7

# mkdir /tftpboot/192.168.1.7/tmp

# chmod 1777 /tftpboot/192.168.1.7/tmp

# mkdir /tftpboot/192.168.1.7/usr

# cp -dpRv /var /tftpboot/192.168.1.7

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.

351.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ù, o sostituiti, ma questo non avviene regolarmente alla conclusione dell'attività, ma solo quando serve. 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 verrà utilizzata direttamente da alcun cliente e che servirà 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, stabiliamo che la directory radice NFS standard sia /tftpboot/standard/.

351.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 monta 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.

Nel caso della distribuzione Red Hat, si può modificare il file etc/rc.d/rc.sysinit nel modo seguente:

#! /bin/sh

# Set the path
PATH=/bin:/sbin:/usr/bin:/usr/sbin
export PATH

# Clear mtab
>/etc/mtab

mount -av

if grep -i nopnp /proc/cmdline >/dev/null ; then
    PNP=
else
    PNP=yes
fi

# set up pnp 
if [ -x /sbin/isapnp -a -f /etc/isapnp.conf ]; then
    if [ -n "$PNP" ]; then
        echo "Setting up ISA PNP devices"
        /sbin/isapnp /etc/isapnp.conf
    else
        echo "Skipping ISA PNP configuration at users request"
    fi
fi

# Clean out /etc.
rm -f /etc/mtab~ /fastboot /fsckoptions
>/var/run/utmp

# Delete UUCP lock files.
rm -f /var/lock/LCK*

# Delete stale subsystem files.
rm -f /var/lock/subsys/*

# Delete stale pid files
rm -f /var/run/*.pid

# Delete X locks
rm -f /tmp/.X*-lock

# Set the system clock.
echo -n "Setting clock"

ARC=0
UTC=0
if [ -f /etc/sysconfig/clock ]; then
    . /etc/sysconfig/clock

    # convert old style clock config to new values
    if [ "${CLOCKMODE}" = "GMT" ]; then
            UTC=true
    elif [ "${CLOCKMODE}" = "ARC" ]; then
            ARC=true
    fi
fi

if [ -x /sbin/hwclock ]; then
    CLOCKFLAGS="--hctosys"
    CLOCK=/sbin/hwclock
else
    CLOCKFLAGS="-a"
    CLOCK=/sbin/clock
fi

if [ $UTC = "true" ]; then
    CLOCKFLAGS="$CLOCKFLAGS -u";
    echo -n " (utc)"
fi
if [ $ARC = "true" ]; then
    CLOCKFLAGS="$CLOCKFLAGS -A";
    echo -n " (arc)"
fi
echo -n ": "
$CLOCK $CLOCKFLAGS

date

# Initialize the serial ports.
if [ -f /etc/rc.d/rc.serial ]; then
        . /etc/rc.d/rc.serial
fi

# Now that we have all of our basic modules loaded and the kernel going,
# let's dump the syslog ring somewhere so we can find it later
dmesg > /var/log/dmesg

# Feed entropy into the entropy pool
/etc/rc.d/init.d/random start

La cosa più importante da osservare in questo esempio è il fatto che il montaggio dei file system elencati nel file etc/fstab viene fatto quasi subito; tutta la gestione del controllo dei dischi, l'attivazione della memoria virtuale e dei moduli del kernel sono stati eliminati.

Eventualmente, è anche possibile l'attivazione della memoria virtuale utilizzando per questo il disco fisso dei clienti senza disco, ammesso che ce ne sia uno nella realtà, cosa che comunque appare un po' come un controsenso: che motivo ci sarebbe di montare il file system principale dalla rete, se si dispone di un disco fisso, per quanto piccolo possa essere.

Dal momento che la gestione della rete non è più compito della procedura di inizializzazione del sistema, nel caso della distribuzione Red Hat è opportuno eliminare i file etc/sysconfig/network, etc/sysconfig/static-routes e tutta la directory etc/sysconfig/network-scripts/.

351.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.

351.3.6   Configurazione di etc/fstab

Il file etc/fstab utilizzato dai clienti senza disco va predisposto in modo da montare 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, sarà il caso di predisporre i punti di innesto rispettivi. L'esempio seguente dovrebbe essere chiaro a sufficienza, tenendo conto che si riferisce al nodo 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à montato quando il sistema legge questo file all'avvio.

351.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)

351.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

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

351.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.

351.4   Riferimenti

Appunti di informatica libera 2003.01.01 --- Copyright © 2000-2003 Daniele Giacomini -- daniele @ swlibero.org

1) Questa soluzione non è «sicura», ma dovrebbe servire per centralizzare la gestione degli utenti senza la presenza di un sistema NIS. Tuttavia, potrebbe essere inutile, dal momento che programmi come useradd rinominano i file passwd e group e poi ne generano sempre di nuovi: in questo caso conviene fare uno script per ricopiare questi file nelle directory relative ai sistemi senza disco ogni volta che si fa una modifica.

Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome diskless_elaboratori_senza_disco.html

[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]