27.3 Network File System (NFS)

27.3.1 Come Funziona NFS

NFS consiste di almeno due parti: un server ed uno o più client. Il client accede da remoto ai dati conservati sulla macchina server. Affinchè questo funzioni, alcuni processi devono essere configurati e devono essere attivi.

Il server deve avere attivi i seguenti demoni:

Il client può anche eseguire un demone, noto come nfsiod. Il demone nfsiod serve le richieste dal server NFS. E' opzionale, aiuta a migliorare le prestazioni ma non è indispensabile per operazioni corrette. Consultare la pagina di manuale di nfsiod(8) per più informazioni.

27.3.2 Configurare NFS

La configurazione di NFS è un processo relativamente semplice. I processi che devono essere attivi possono essere tutti avviati al boot della macchina con poche modifiche al tuo file /etc/rc.conf.

Sul server NFS assicurati che le seguenti opzioni sono configurati nel file /etc/rc.conf:

rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"

mountd viene eseguito automaticamente in caso il server NFS sia abilitato.

Sul client, accertati che questa riga sia attiva nel file /etc/rc.conf:

nfs_client_enable="YES"

Il file /etc/exports specifica quali file system NFS dovrebbe esportare (talora chiamate anche “share”). Ogni linea di /etc/exports specifica un file system che deve essere esportato e quali macchine hanno accesso a quel file system. Assieme alle macchine che hanno accesso a quel file system, possono esserci specificate anche opzioni. Ci sono molte opzioni di questo tipo che possono essere usate in questo file ma solo poche saranno menzionate qui. Puoi facilmente scoprire le altre opzioni leggendo la pagina di manuale di exports(5).

Queste sono alcune linee di esempio del file /etc/exports:

I seguenti esempi danno un'idea di come esportare file system, anche se le impostazioni possono essere diverse a seconda del tuo ambiente e della tua configurazione di rete. Ad esempio, per esportare la directory /cdrom a tre macchine di esempio che hanno lo stesso nome di dominio del server (da qui la mancanza di nome dominio per ognuno) o hanno delle linee nel vostro file /etc/hosts. L'opzione -ro rende il file system esportato read-only. Con questo flag, il sistema remoto non sarà in grado di scrivere alcun cambiamento sul file system esportato.

/cdrom -ro host1 host2 host3

La seguente linea esporta la directory /home a tre host identificati da indirizzo IP. E' una impostazione utile in caso tu abbia una rete privata senza un DNS server configurato. Opzionalmente il file /etc/hosts può essere configurato per hostname interni. Per favore rileggi hosts(5) per più informazioni. Il flag -alldirs permette alle sottodirectory di fungere da mount point. In altre parole, non monterà le sottodirectory ma permetterà  ai client di montare solo le directory che necessita o di cui ha bisogno.

/home  -alldirs  10.0.0.2 10.0.0.3 10.0.0.4

La linea seguente esporta /a cosicchè due client da diversi domini possono accedere al file system. L'opzione -maproot=root permette all'utente root sul sistema remoto di scrivere dati sul file system esportato come utente root. Se il flag -maproot=root non è specificato, anche se l'utente ha accesso come root sul file system remoto, non sarà  in grado di modificare files sul file system esportato.

/a  -maproot=root  host.example.com box.example.org

Affinchè un client abbia accesso ad un file system, questo deve avere permessi adeguati. Assicurati che il client sia elencato nel file /etc/exports.

In /etc/exports, ogni linea rappresenta le informazioni per un file system esportato ad un host. Un host remoto può essere specificato solo una volta per file system, e può avere solo una entry di default. Ad esempio, supponi che /usr sia un singolo file system. Il seguente /etc/exports sarebbe invalido:

# Invalid when /usr is one file system
/usr/src   client
/usr/ports client

Un file system, /usr, ha due linee che specificano exports verso lo stesso host, client. Il formato corretto per questa situazione è:

/usr/src /usr/ports  client

Le proprietà di un file system esportato ad un dato host devono essere tutte su una riga. Linee senza un cliente specificato sono trattate come un singolo host. Questo limita il modo di esportare file system, ma per la maggior parte delle persone non è un problema.

Il seguente è un esempio di valida lista di esportazione, dove /usr e /exports /usr and /exports sono file system locali:

# Export src and ports to client01 and client02, but
only
# client01 has root privileges on it
/usr/src /usr/ports -maproot=root    client01
/usr/src /usr/ports               client02
# The client machines have root and can mount anywhere
# on /exports. Anyone in the world can mount /exports/obj read-only
/exports -alldirs -maproot=root      client01 client02
/exports/obj -ro

Il demone mountd deve essere forzato a rileggere il file /etc/exports ogni volta che lo modifichi, cosicchè i cambiamenti abbiano effetto. Questo può essere ottenuto inviando un segnale HUP al processo mountd:

# kill -HUP `cat /var/run/mountd.pid`

o invocando lo script mountd rc(8) con i parametri appropriati:

# /etc/rc.d/mountd onereload

Sei invitato a far riferimento a Sezione 11.2 per maggiori informazioni sugli script rc.

Alternativamente, un reboot farà  sì che FreeBSD imposti tutto correttamente. Non è necessario tuttavia effettuare un reboot. L'esecuzione del seguente comando da utente root dovrebbe avviare tutto.

Sul server NFS:

# rpcbind
# nfsd -u -t -n 4
# mountd -r

Sul client NFS:

# nfsiod -n 4

Ora dovrebbe essere tutto pronto per montare un file system remoto. In questi esempi il nome del server sarà  server e quello del client sarà  client. Se vuoi solo temporaneamente montare un file system remoto o anche testare la configurazione, basta che esegui un comando come questo come utente root sul client:

# mount server:/home
/mnt

Questo monterà  la directory /home del server sopra /mnt sul client. Se tutto è impostato correttamente dovresti essere in grado di entrare nella directory /mnt sul client e vedere tutti i file che sono sul server.

Se vuoi montare automaticamente un file system remoto ogni volta che il computer fa boot, aggiungi il file system al file /etc/fstab. Questo è un esempio:

server:/home /mnt nfs rw 0 0

La pagina di manuale di fstab(5) elenca tutte le possibili opzioni.

27.3.3 Locking

Alcune applicazioni (es. mutt) richiedono il lock dei file per operare in modo corretto. In caso di NFS, può essere utilizzato rpc.lockd per il lock dei file. Per abilitarlo, aggiungi la seguente riga al file /etc/rc.conf sia sul client che sul server (assumendo che il client e server NFS siano già configurati):

rpc_lockd_enable="YES"
rpc_statd_enable="YES"

Avvia l'applicazione con:

# /etc/rc.d/nfslocking start

Se non è richiesto un lock reale tra il server e il client NFS, è possibile dire al client NFS di fare un lock locale passando l'opzione -L a mount_nfs(8). Ulteriori dettagli possono essere trovati nella pagina man di mount_nfs(8).

27.3.4 Usi Pratici

NFS ha molti usi pratici. Alcuni dei più usati sono elencati di seguito:

• Fa sì che alcune macchine condividano un CDROM o un altro media fra di loro. Questo è un metodo più economico e spesso più convieniente di installare software su molte macchine.

• Su grandi reti, potrebbe essere più conveniente configurare un server NFS centrale in cui conservare tutte le home directory degi utenti. Queste home directory possono essere esportate sulla rete cosicchè gli utenti abbiano sempre la stessa directory, indipendentemente dalla workstation dalla quale effettuino il login.

• Molte macchine potrebbero avere una directory comune /usr/ports/distfiles. In questo modo, quando hai bisogno di installare un port su molte macchine, puoi velocemente accedere al sorgente senza scaricarlo su ogni macchina.

27.3.5 Mount automatici con amd

amd(8) (il demone di mount automatico) monta automaticamente un file system remoto ogni volta che un file o una directory in quel file system viene acceduto. I file system che sono inattivi per un certo periodo di tempo possono anche essere smontati automaticamente da amd. L'uso di amd fornisce una semplice alternativa a mount permanenti, dato che i mount permanenti sono di solito elencati in /etc/fstab.

amd opera connettendosi ad un server NFS sulle directory /host e /net. Quando si accede ad un file all'interno di una di queste directory, amd fa una ricerca del mount remoto corrispondente e lo monta automaticamente. /net è usato per montare un file system esportato da un indirizzo IP, mentre /host è usato per montare un export da un hostname remoto.

Un accesso ad un file in /host/foobar/usr dovrebbe comunicare a amd di cercare di montare l'export /usr sull'host foobar.

% showmount -e foobar
Exports list on foobar:
/usr                               10.10.10.0
/a                                 10.10.10.0
% cd /host/foobar/usr

Come si vede nell'esempio, il comando showmount mostra /usr come un export. Quando si cambia directory in /host/foobar/usr, amd cerca di risolvere foobar e automaticamente monta l'export desiderato.

amd può essere avviato dagli scripts di startup inserendo le seguenti linee in /etc/rc.conf:

amd_enable="YES"

Inoltre, altri flags personalizzati possono essere ad amd con le opzioni amd_flags. Di default, amd_flags è impostato a:

amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map
/net /etc/amd.map"

Il file /etc/amd.map definisce le opzioni di default con le quali gli export sono montati. Il file /etc/amd.conf definisce alcune delle più avanzate caratteristiche di amd.

Consulta le pagine di manuale di amd(8) e amd.conf(5) per maggiori informazioni.

27.3.6 Problemi nell'integrazione con altri sistemi

Alcuni adapter Ethernet per sistemi PC hanno limitazioni che possono portare a seri problemi seri di rete, in particolare con NFS. Questa difficoltà  non è specifica a FreeBSD, ma i sistemi FreeBSD ne sono affetti.

I problemi avvengono quasi sempre quando sistemi PC (FreeBSD) sono connessi in rete con workstation ad alta performance, tipo quelli di Silicon Graphics, Inc., e Sun Microsystems, Inc. Il mount NFS funziona, ed alcune operazioni possono avere successo, ma d'improvviso sembra che il server non dia più risposte al client, anche se le richieste da e verso altri sistemi continuano ad essere processate. Questo avviene sul sistema client, sia che il client sia il sistema FreeBSD sia che sia la workstation. Su molti sistemi, non c'è modo di effettuare lo shutdown del client in modo pulito una volta che questo problema si sia manifestato. L'unica soluzione è spesso quella di resettare il client, poichè la situazione NFS non può essere risolta.

Anche se la soluzione “corretta” è usare un adapter Ethernet dalle migliori prestazioni e capacità , c'è un semplice workaround che permetterà  operazioni soddisfacenti. Se il sistem FreeBSD è il server, includi le opzioni -w=1024 al mount dal client. Se il sistema FreeBSD è il client, allora monta il file system NFS con l'opzione -r=1024. Queste opzioni possono essere specificate usando il quarto campo della linea di fstab sul client per mount automatici, o usa il parametro -o del comando mount(8) per mount manuali.

Bisognerebbe notare che c'è un problema diverso, a volte confuso con questo, quando il server NFS ed il client sono su reti diverse. Se è questo il caso, accertatevi che i vostri router indirizzino correttamente l'informazione necessaria su UDP, o non andrai da nessuna parte, indipendentemente da cosa tu stia cercando di fare.

Nei seguenti esempi, fastws è il nome host (interfaccia) di una workstation ad alte prestazioni, e freebox è il nome host (interfaccia) di un sistema FreeBSD con un adapter Ethernet a basse prestazioni. Inoltre, /sharedfs sarà  il file system esportato (vedi exports(5)), e /project sarà  il mount point sul client per il file system montato. In tutti i casi, nota che le opzioni hard o soft e bg possono essere utili nella tua applicazione.

Esempi dal sistema FreeBSD (freebox) come client da /etc/fstab su freebox:

fastws:/sharedfs /project nfs rw,-r=1024 0 0

Come comando manuale di mount da freebox:

# mount -t nfs -o -r=1024 fastws:/sharedfs /project

Esempi dal sistema FreeBSD come server in /etc/fstab su fastws:

freebox:/sharedfs /project nfs rw,-w=1024 0 0

Come comando di mount manuale su fastws:

# mount -t nfs -o -w=1024 freebox:/sharedfs /project

Praticamente ogni Ethernet adapter a 16-bit permetterà  operazioni senza le succitate restrizioni sulla dimensione di lettura e scrittura.

Per chiunque è interessato, ecco cosa succede quando occorre il problema, il che spiega anche perchè sia non riparabile. NFS tipicamente lavora con una dimensione di “block” di 8 K (anche se può creare frammenti di dimensione minore). Dal momento che la massima dimensione dei pacchetti Ethernet è attorno a 1500 bytes, il “block” NFS sarà  diviso in molti pacchetti Ethernet anche se è pur sempre una singola unità  per il codice di più alto livello e deve essere ricevuto, assemblato e riconosciuto come una unità . La workstation ad alta performance può inviare pacchetti che comprendono le unità  NFS una dietro l'altra, l'una vicino all'altra come permette lo standard.i Sulla scheda a minore capacità , gli ultimi pacchetti sovrascrivono i precedenti pacchetti della stessa unità  prima che possano essere trasferiti all'host e l'unità  nella sua interezza non può essere ricostruita o riconosciuta. Come risultato, la workstation andrà  in timeout e cercherà  ancora di ripetere l'operazione, ma cercherà  con la stessa unità  da 8 K, ed il processo sarà  ripetuto ancora, all'infinito.

Mantenendo la dimensione dell'unità  al di sotto della limitazione dei pacchetti Ethernet, ci assicuriamo che ogni completo pacchetto Ethernet ricevuto possa essere ricono sciuto individualmente, evitando così la situazione deadlock.

Sovrascritture possono anche capitare quando una workstation ad alte prestazioni riversi dati verso un sistema PC, ma con la scheda di rete migliore, sovrascritture di questo tipo non sono garantite su “unità ” NFS. Quando una sovrascrittura avviene, le unità  affette saranno ritrasmesse, e c'è una buona probabilità  che saranno ricevute, assemblate, e riconosciute.