27.3. Network File System (NFS)
Indietro | Capitolo 27. Server di rete | Avanti

## 27.3. Network File System (NFS)

Riorganizzato e migliorato da Tom Rhodes.
Scritto da Bill Swingle.

Fra i molti differenti file system che FreeBSD supporta c'è il Network File System, conosciuto anche come NFS. NFS permette ad un sistema di condividere directory e file con altri sistemi in rete. Usando NFS, utenti e programmi possono accedere a file su sistemi remoti quasi come se fossero files locali.

Alcuni dei più notevoli benefici che NFS ci fornisce sono:

- Workstation locali usano meno spazio su disco perchè i dati usati in locale possono essere conservati su una singola macchina e restano accessibili agli altri sulla rete.

- Non c'è bisogno per gli utenti di avere home directory separate su ogni macchina in rete. Le home directory possono essere poste sul server NFS e rese disponibili attraverso la rete.

- Device di storage come floppy disk, drive CDROM, e drive Zip® possono essere usati da altre macchine sulla rete. Questo può ridurre il numero di device di storage rimuovibili sulla rete.

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

Demone | Descrizione
--- | ---
nfsd | Il demone NFS che serve richieste da client NFS.
mountd | Il demone di mount NFS che serve le richieste che nfsd(8) gli passa.
rpcbind | Questo demone permette ai client NFS di scoprire quali porte il server NFS sta usando.

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, «Configurazione Iniziale» 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

Grazie al contributo di Wylie Stilwell.
Riscritto da Chern Lee.

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

Esempio 27.2. Montare un export con amd

Puoi osservare i mount disponibili di un host remoto con il comando `showmount`. Ad esempio, per vedere i mounts di un host chiamato `foobar`, puoi usare:

`%` `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

Grazie al contributo di John Lind.

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.

Indietro | Risali | Avanti
27.2. Il «Super-Server» inetd | Partenza | 27.4. Network Information System (NIS/YP)

Questo, ed altri documenti, possono essere scaricati da ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Per domande su FreeBSD, leggi la documentazione prima di contattare <questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a <doc@FreeBSD.org>.