[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


244. Diskless: elaboratori senza disco

Una caratteristica importante del sistema di condivisione dei filesystem 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, e lo 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.

244.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 filesystem 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. In questo capitolo, è questa la soluzione che viene presa in considerazione.

244.2 Preparazione del cliente

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

244.2.1 Kernel

Prima di tutto, occorre preparare un kernel adatto alla stazione senza disco che si vuole utilizzare. Di sicuro, occorre attivare le voci seguenti.

I punti elencati, che rappresentano l'essenziale per ottenere un kernel in grado di attivare una stazione senza disco, devono essere inclusi come elementi del kernel monolitico. In pratica, non è possibile lasciare che vengano inclusi come moduli, e questo perché non è tanto facile caricare moduli quando non si dispone di un disco locale.

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 questo scopo, è bene tenere presente anche queste esigenze.

244.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 filesystem principale attraverso il protocollo NFS.

root=/dev/nfs

Si tratta di un messaggio con cui si informa il kernel di voler utilizzare come filesystem 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 filesystem. 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 filesystem NFS.

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

244.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 244.1 mostra questa situazione.

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

Tabella 244.1: Configurazione di esempio.

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 filesystem principale non è casuale; si tratta di una convenzione diffusa:

/tftpboot/<indirizzo-del-cliente>/

244.2.4 /dev/boot255

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

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

244.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 10. Qui si intende solo riepilogare in che modo configurare i vari sistemi di avvio.

244.3 Preparazione del servente

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 maggiore, a questo proposito, risiede nel fatto che ogni distribuzione GNU/Linux ha una sua impostazione, e sono 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.

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

244.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, e 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 filesystem 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.

244.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/'.

244.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 filesystem principale attraverso il protocollo NFS. Quindi, la procedura di inizializzazione del sistema non ha alcuna necessità, né la possibilità di eseguire un controllo del filesystem 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 filesystem 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 filesystem 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/'.

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

244.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 filesystem 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/' va organizzata opportunamente.

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

244.3.7 Esportazione del filesystem nel servente

Perché la gestione dei clienti senza disco possa funzionare, occorre evidentemente che il servente consenta l'accesso al proprio filesystem 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)

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

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

244.4 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


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.


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]