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

Capitolo 217.   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.

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

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

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.

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

217.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 49.2.14), 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 (49.2.20).

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.

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

217.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 217.3 mostra questa situazione.

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/

217.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]

217.2.5   Avvio del kernel dal dischetto

L'avvio del kernel da un dischetto è un problema semplice da risolvere, descritto eventualmente nel capitolo 34. 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 file system, 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[Invio]

  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:"

• Si può fare la stessa cosa con GRUB; segue un esempio della porzione più importante del file /boot/grub/menu.lst da inserire nel dischetto stesso:

  title diskless kernel (fd0)/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:"

  Si osservi il fatto che qui non viene utilizzato il dispositivo /dev/boot255.

• SYSLINUX si configura in modo simile a LILO e a GRUB, 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:"

• 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:

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

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

217.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'.

• Nella directory lib/ si potrebbero eliminare i moduli, se si è deciso che i kernel dei clienti non ne devono fare uso.

• Nella directory etc/ si potrebbero eliminare tutti i file e le sottodirectory riferite a programmi, inclusi i demoni, che non si intende utilizzare.

• Nella directory etc/, i file passwd e group potrebbero essere dei collegamenti fisici ai file corrispondenti della directory /etc/ del servente.

  Si osservi che 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.

• 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 lucchetto, i file delle registrazioni e tutti i file amministrativi dei programmi che non riguardano i clienti. Altri file vanno lasciati, ma per ognuno di questi occorre conoscerne il motivo.

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

217.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/.

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

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

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

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

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

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

217.4   Riferimenti

• Gero Kuhlmann, Mounting the root filesystem via NFS

  sorgenti_linux/Documentation/nfsroot.txt

• Stefano Salvi, AngoLinux, Realizzazione di un Laboratorio Diskless

  <http://www.itis.mn.it/linux/>

• EtherBoot

  <http://www.etherboot.org/>

• Charles M. Coldwell, Diskless Linux

  <http://frank.harvard.edu/~coldwell/diskless>

• Linux terminal server project

  <http://www.ltsp.org>

Appunti di informatica libera 2006.07.01 --- Copyright © 2000-2006 Daniele Giacomini -- <daniele (ad) swlibero·org>

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] [translators] [docinfo] [indice analitico]