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 server. 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.
L'idea alla base della macchina senza disco è molto semplice:
viene caricato il kernel in qualche modo, con tutte le informazioni necessarie ad accedere alla rete e al server NFS;
viene eseguito il montaggio del filesystem principale (dalla rete) in lettura e scrittura;
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 server NFS da raggiungere. In questo capitolo, è questa la soluzione che viene presa in considerazione.
La preparazione del client cioè del dischetto necessario ad avviare l'elaboratore senza disco fisso, è la parte più semplice, e quindi viene mostrata per prima.
Prima di tutto, occorre preparare un kernel adatto alla stazione senza disco che si vuole utilizzare. Di sicuro, occorre attivare le voci seguenti.
Networking support ( 19.2.4) Y
TCP/IP networking ( 19.2.7) Y
Network device support ( 19.2.9) Y
In questa sezione andranno aggiunte le interfacce di rete che si vogliono gestire, incorporandole, senza lasciare che vengano incluse come moduli.
NFS filesystem support ( 19.2.15) Y
Root file system on NFS ( 19.2.15) Y
|
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.
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-server>:]<directory-radice>[,<opzione-nfs>[,...]] |
Serve a definire le informazioni necessarie al montaggio della directory del server che verrà utilizzata come radice del filesystem. L'indirizzo IP del server è 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-client>]:[<ip-del-server>]:[<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 client e del server 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 client e del server.
Prima di proseguire con la descrizione di ciò che serve per predisporre un client senza disco, conviene introdurre una situazione di esempio, che poi verrà utilizzata nelle spiegazioni successive.
Si suppone di disporre di un server nella stessa rete locale in cui si vuole collocare il client. In tal caso, pur non essendo necessario, viene indicato ugualmente un router che in pratica corrisponde allo stesso indirizzo del server. La tabella 203.1 mostra questa situazione.
| Elemento | Valore |
| server | 192.168.1.1 |
| client | 192.168.1.7 |
| router | 192.168.1.1 |
| maschera di rete | 255.255.255.0 |
| nome del client | 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 filesystem principale non è casuale; si tratta di una convenzione diffusa:
/tftpboot/<indirizzo-del-client>/ |
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
L'avvio del kernel da un dischetto è un problema che è stato già descritto a sufficienza in questo documento, in particolare nel capitolo 9. Qui si intende solo riepilogare in che modo configurare i vari sistemi di avvio.
Se si intende avviare il kernel copiandolo in un dischetto senza filesystem, utilizzando quindi dd (o anche cp), non è possibile fornire alcun parametro, tranne l'indicazione del dispositivo attraverso il programma rdev. In pratica, se il dischetto immagine del kernel si trova nella prima unità, si utilizza il comando seguente:
# rdev /dev/fd0 /dev/boot255
Tutte le altre informazioni, devono provenire dal protocollo RARP o BOOTP. Pertanto, questo tipo di avvio non è consigliabile in generale.
Se si realizza un dischetto contenente il kernel, avviato attraverso LILO, si possono dare i parametri necessari attraverso la configurazione del file /etc/lilo.conf. Segue il pezzo significativo, relativo all'esempio proposto in precedenza (la direttiva append appare spezzata su più righe per motivi tipografici, ma dovrebbe occupare una riga sola).
image=/vmlinuz label=diskless root=/dev/boot255 append="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:" |
SYSLINUX si configura in modo simile a LILO, con la differenza che basta collocare i file necessari nel dischetto, senza creare collegamenti tra loro. In questo senso è particolarmente comodo, e decisamente preferibile quando si deve avviare un kernel da dischetto. Segue un pezzo della configurazione del file SYSLINUX.CFG (anche in questo caso, la direttiva APPEND appare spezzata su più righe per motivi tipografici, ma dovrebbe occupare una riga sola).
LABEL diskless KERNEL LINUX APPEND "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:" |
Si osservi il fatto che qui non viene utilizzato il dispositivo /dev/boot255.
Loadlin richiede la preparazione di un dischetto con un sistema Dos minimo, dal quale poter avviare (di solito attraverso il file AUTOEXEC.BAT) il programma LOADLIN.EXE. Segue l'esempio di questo comando, separato su più righe per motivi tipografici.
LOADLIN vmlinuz 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: |
Il server 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 server per questo scopo.
Ogni distribuzione GNU/Linux dovrebbe fornire gli strumenti necessari ad automatizzare la creazione e la gestione del server; in realtà solo poche fanno tanto.
In queste sezioni si fa riferimento a un server realizzato su una distribuzione Red Hat, ma senza porre un accento eccessivo sulle particolarità di questa distribuzione.
È 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 client dovrebbero avere una configurazione uniforme e che su quelle stazioni non ci dovrebbero essere utenti root, a parte l'amministratore del server. 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 client non dovrebbero offrire servizi di rete.
La cosa più delicata da organizzare è la directory radice dei client senza disco. Queste directory, per tradizione (e per stare fuori dai guai), vanno collocate a partire da /tftpboot/<indirizzo>/. Per fare un esempio, il client individuato dall'indirizzo IP 192.168.1.7, dovrebbe trovare la sua directory radice a partire dalla directory /tftpboot/192.168.1.7/ del server.
Generalmente se ne prepara una, per un client 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 client particolare, rispetto agli altri.
La directory radice NFS di ogni client deve contenere il necessario a permettere l'avvio del client 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 server, altre servono vuote, altre vanno copiate solo parzialmente.
Nella spiegazione seguente si fa l'esempio della predisposizione della directory radice NFS per il client 192.168.1.7; tutte le directory degli altri client 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 server (è meglio non fare collegamenti ai file utilizzati dal sistema del server), 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'.
Nella directory lib/ si potrebbero eliminare i moduli, se si è deciso che i kernel dei client non ne faranno uso.
Nella directory etc/ si potrebbero eliminare tutti i file e le sottodirectory riferite a programmi, inclusi i demoni, che non verranno utilizzati.
Nella directory etc/, i file passwd e group potrebbero essere dei collegamenti fisici ai file corrispondenti della directory /etc/ del server.
*1*
Nella directory var/ bisognerebbe eliminare tutto quello che non serve, lasciando comunque, almeno le directory vuote dove necessario. In particolare vanno eliminati tutti i file di lock, i file delle registrazioni, e tutti i file amministrativi dei programmi che non riguardano i client. Altri file vanno lasciati, ma per ognuno di questi occorre conoscerne il motivo. Per fare un esempio, il file var/lib/dosemu/hdimage serve per avviare DOSEMU, e potrebbe essere condiviso tranquillamente tra tutti i client.
Anche le directory riferite alle stampanti costituiscono un problema. Se la stampa è necessaria, è il caso di predisporre le directory e i file necessari per una stampante di rete, in modo da poter poi condividere tra tutti i client la stessa configurazione.
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.
È stato indicato che basta predisporre una directory radice per un client senza disco e poi le altre per gli altri client 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 client 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 client, 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 client, e che servirà per generare le altre.
La directory standard va preparata congiuntamente a quella del primo client utilizzato come prova del buon funzionamento della directory radice NFS. Quando si cambia qualcosa nella directory del client, 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/.
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 client senza disco.
Prima di farlo, si deve fare mente locale alla situazione che si ha di fronte: il kernel dei client provvede da solo a definire l'indirizzo dell'interfaccia di rete e a instradarsi verso il server; 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 client 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/.
Un'altra cosa a cui fare attenzione, sono i demoni avviati nei client. Bisogna ridurli al minimo indispensabile, anche in considerazione del fatto che è improbabile l'attivazione di servizi su dei client senza disco.
Il file etc/fstab utilizzato dai client 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 client, sarà il caso di predisporre i punti di innesto rispettivi. L'esempio seguente dovrebbe essere chiaro a sufficienza.
/dev/nfs / 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. |
Perché la gestione dei client senza disco possa funzionare, occorre evidentemente che il server 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) |
Per attivare un nuovo client basta riprodurre la directory radice NFS standard, creando solo collegamenti fisici, come nell'esempio seguente, in cui si suppone di aggiungere il client 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.
In questo capitolo è stato ignorato volutamente il problema della memoria virtuale. Per attivare la sua gestione, le macchine usate come client dovrebbero avere un disco fisso, e in tal senso dovrebbe essere modificata la procedura di inizializzazione del sistema.
Gero Kuhlmann, Mounting the root filesystem via NFS (nfsroot)
/usr/src/linux/Documentation/nfsroot.txt
Ken Yap, Diskless Linux Workstation
Roberto Salvi, AngoLinux, Realizzazione di un Laboratorio Diskless
---------------------------
Appunti Linux 1999.09.21 --- Copyright © 1997-1999 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.