Capitolo 137. NFS con i sistemi GNU/Linux

NFS è un servizio di rete che, avvalendosi delle RPC, permette la condivisione di porzioni di file system da e verso altri elaboratori connessi.

Nell'ambito del modello ISO-OSI, il protocollo NFS si colloca al livello cinque (sessione). A seconda della versione del protocollo NFS, questo può avvalersi, al livello sottostante (trasporto), del protocollo UDP o del protocollo TCP.

Il kernel Linux può incorporare, sia le funzionalità necessarie ad accedere a un file system NFS remoto, sia le funzionalità di servente NFS, che comunque devono essere gestite attraverso programmi di contorno.

137.1 Supporto nel kernel

Per poter condividere file attraverso NFS, sia come cliente che come servente, occorre includere il supporto al file system NFS nel kernel (sezione 29.2.14).

Si può controllare la possibilità di accedere a un file system NFS leggendo il contenuto del file /proc/filesystems. L'esempio seguente rappresenta una situazione in cui ciò è possibile, per la presenza della riga nodev nfs:

        ext3
        ext2
        minix
        umsdos
        msdos
        vfat
nodev   proc
nodev   nfs
nodev   smbfs
        iso9660

Per scoprire se il kernel consente di gestire la funzionalità di servente NFS, si può cercare il file /proc/net/rpc/nfsd, che potrebbe contenere qualcosa simile all'esempio seguente:

rc 0 63064 138528
fh 0 194531 0 0 0
io 61203811 330360802
th 8 350 47.860 3.570 1.470 0.000 0.880 0.730 0.250 0.290 0.000 1.760
ra 16 7654 169 54 60 23 53 24 14 20 21 2115
net 201592 201592 0 0
rpc 201592 0 0 0 0
proc2 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
proc3 22 2 771 4595 101428 13065 19 10207 51228 3301 16 34 0 3310  (segue)
  15 520 45 2130 0 45 45 0 10816

137.2 Dal lato del servente

Dalla parte dell'elaboratore servente è necessario che oltre al Portmapper siano in funzione alcuni demoni, avviati secondo l'ordine seguente: rpc.mountd, rpc.nfsd, rpc.statd, rpc.lockd ed eventualmente rpc.rquotad. ⁽¹⁾ Quindi, è necessario che il file di configurazione /etc/exports sia stato configurato correttamente. Si può controllare la presenza del servizio attraverso l'interrogazione delle RPC:

$ rpcinfo -p[Invio]

   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  54407  status
    100024    1   tcp  38826  status
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100021    1   udp  54411  nlockmgr
    100021    3   udp  54411  nlockmgr
    100021    4   udp  54411  nlockmgr
    100005    1   udp  54412  mountd
    100005    1   tcp  38827  mountd
    100005    2   udp  54412  mountd
    100005    2   tcp  38827  mountd
    100005    3   udp  54412  mountd
    100005    3   tcp  38827  mountd

Nello stesso modo, si può analizzare l'albero dei processi:

$ pstree[Invio]

init-+-...
    ...
     |-lockd---rpciod
    ...
     |-8*[nfsd]
    ...
     |-portmap---portmap
    ...
     |-rpc.mountd
     |-rpc.statd
    ...

rpc.mountd è il demone che si occupa di gestire il montaggio del file system di rete dal lato del servente:

rpc.mountd [opzioni]

Generalmente, viene avviato dalla procedura di inizializzazione del sistema, in modo autonomo, cioè indipendente dal supervisore dei servizi di rete. Mantiene aggiornato il file /var/lib/nfs/rmtab che elenca i montaggi in essere. Tuttavia, non è garantito che il contenuto di questo file sia esatto, per cui non lo si può utilizzare per determinare con certezza quali siano le connessioni in corso.

rpc.nfsd è il demone che si occupa di gestire le richieste, da parte dei clienti, per i servizi NFS, avvalendosi in pratica delle funzionalità del kernel Linux.

rpc.nfsd [opzioni]

Deve essere in funzione nel servente. Viene avviato generalmente dalla procedura di inizializzazione del sistema, subito dopo rpc.mountd. Anche rpc.nfsd funziona in modo autonomo rispetto al supervisore dei servizi di rete.

Il demone rpc.lockd si occupa di avviare la gestione del sistema di file di lock NFS, noto come NLM, ovvero NFS lock manager:

rpc.lockd

In generale, con i kernel Linux recenti non dovrebbe essere necessaria la presenza di questo programma; tuttavia, anche se così fosse, il suo avvio non provoca inconvenienti.

Il demone rpc.statd serve al sistema di file di lock NFS per aggiornare la situazione quando un elaboratore cliente viene riavviato o comunque si blocca:

rpc.statd [opzioni]

La configurazione del servizio avviene principalmente attraverso il file /etc/exports, il quale contiene l'indicazione delle porzioni di file system locale da concedere in condivisione. Se il file manca o è vuoto, non viene concesso l'utilizzo di alcuna parte del file system locale all'esterno.

Si tratta di un file di testo normale, in cui vengono ignorate le righe vuote, quelle bianche e quelle che iniziano con il simbolo #; per il resto, le righe sono intese come dei record, ognuno dei quali è composto da:

l'indicazione di una directory a partire dalla quale si concede la condivisione;
una serie di nodi o reti cui viene concesso l'utilizzo di questa directory con l'eventuale specificazione di opzioni di accesso.

In pratica si utilizza la sintassi seguente:

directory_di_partenza [host][(opzioni)]...

La configurazione di questo file potrebbe non dare sempre gli effetti previsti, a causa di difetti che possono essere presenti nei demoni che si occupano della gestione del servizio. In generale, si è cercato sempre di garantire la sicurezza, a discapito della funzionalità. Se una configurazione di /etc/exports sembra non funzionare senza un motivo apparente, è bene provarne altre, limitando l'uso di opzioni particolari, o cercando di identificare meglio gli elaboratori a cui si concede l'accesso. Eventualmente, si veda anche la pagina di manuale exports(5).

Gli elaboratori a cui si concede l'accesso alla directory condivisa possono essere specificati in vari modi, alcuni dei quali sono elencati di seguito:

indicazione di un nodo singolo

quando si utilizza un nome o un indirizzo IP che fa riferimento da un elaboratore specifico;
uso di caratteri jolly

possono essere utilizzati i caratteri jolly * e ? per indicare un gruppo di nomi di elaboratore con una sola notazione, tenendo presente che questi simboli non possono sostituirsi ai punti di un nome di dominio;
rete IP

attraverso la notazione indirizzo_ip/maschera_di_rete è possibile indicare simultaneamente tutti gli elaboratori collocati all'interno della rete o della sottorete a cui si fa riferimento.

Le opzioni tra parentesi tonde sono parole chiave particolari. Segue la descrizione di alcune di queste:

ro

Consente l'accesso in sola lettura. Questa è la modalità di funzionamento predefinita.
rw

Consente l'accesso in lettura e scrittura.
insecure_lock | no_auth_nlm

Questa opzione consente di usare un sistema di file di lock meno rigido, quando alcuni elaboratori clienti mostrano difficoltà in questo senso.
root_squash

Si tratta di un'opzione di sicurezza, di solito predefinita, attraverso la quale si impedisce l'accesso come utente root. In pratica, quando un utente root presso un elaboratore cliente utilizza il file system condiviso, viene trattato come utente nobody.⁽²⁾
all_squash

La presenza di questa opzione fa sì che tutti gli accessi al file system condiviso, avvengano con i privilegi dell'utente nobody.

no_root_squash

Non effettua la trasformazione dell'UID root e ciò è necessario quando si utilizzano clienti NFS senza disco fisso.

L'elenco seguente mostra alcuni esempi di record di questo file.

/usr *.brot.dg(ro)	Concede ai nodi del dominio `brot.dg` l'accesso in lettura alla directory `/usr/` e seguenti.
/ roggen.brot.dg(ro,root_squash)	Concede a `roggen.brot.dg` di accedere in sola lettura a partire dalla directory radice, escludendo i privilegi dell'utente `root`.
/home roggen.brot.dg(rw) weizen.mehl.dg(rw)	Concede a `roggen.brot.dg` e a `weizen.mehl.dg` di accedere in lettura e scrittura alla directory `/home/`.
/ *(rw,no_root_squash)	Questa definizione non dovrebbe funzionare più. Sembrerebbe voler concedere a tutta la rete di accedere in lettura e scrittura a partire dalla directory radice, permettendo ai vari utenti `root` di mantenere i loro privilegi. Tuttavia l'asterisco non dovrebbe riuscire a rimpiazzare i punti che compongono i nomi di dominio, risolvendosi così in una directory che in pratica non viene condivisa.

Quando si modifica il file /etc/exports, per garantire che queste siano prese in considerazione dal sistema di condivisione del file system, è necessario utilizzare il programma exportfs nel modo seguente:

# exports -ra

Il programma exportfs può anche essere usato per esportare al volo una directory, senza modificare il file /etc/exports. In generale, si tratta di una pratica non consigliabile, ma della quale bisogna tenere conto. Eventualmente si può consultare la pagina di manuale exportfs(8).

Infine, bisogna considerare che alcuni dei demoni che abilitano il servizio NFS potrebbero essere stati compilati in modo da utilizzare i file /etc/hosts.allow e /etc/hosts.deny per controllare l'accesso. L'elenco seguente mostra in che modo abilitare o disabilitare l'accesso in modo selettivo per ogni demone coinvolto, tenendo conto che anche il Portmapper potrebbe dipendere da questi file:

Demone	`/etc/hosts.allow`	`/etc/hosts.deny`
Portmapper	`portmap: specifica_dei_nodi`	`portmap: specifica_dei_nodi`
`rpc.mountd`	`mountd: specifica_dei_nodi`	`mountd: specifica_dei_nodi`
`rpc.nfsd`	`nfsd: specifica_dei_nodi`	`nfsd: specifica_dei_nodi`
`rpc.lockd`	`lockd: specifica_dei_nodi`	`lockd: specifica_dei_nodi`
`rpc.statd`	`statd: specifica_dei_nodi`	`statd: specifica_dei_nodi`
`rpc.rquotad`	`rquotad: specifica_dei_nodi`	`rquotad: specifica_dei_nodi`

È molto probabile che molti di questi demoni siano insensibili al contenuto dei file /etc/hosts.allow e /etc/hosts.deny; tuttavia, se nel proprio sistema si utilizzano questi file, è meglio scrivere una riga di più in questi file, anche se inutile, piuttosto che dimenticarsene e avere problemi in seguito. Pertanto, per abilitare l'accesso a tutti questi demoni, converrà utilizzare le direttive seguenti nel file /etc/hosts.allow:

portmap: specifica_dei_nodi
mountd: specifica_dei_nodi
nfsd: specifica_dei_nodi
lockd: specifica_dei_nodi
statd: specifica_dei_nodi
rquotad: specifica_dei_nodi

Per converso, può essere conveniente inserire le righe seguenti nel file /etc/hosts.deny, allo scopo di escludere gli accessi che non provengano dai nodi autorizzati espressamente:

portmap: ALL
mountd: ALL
nfsd: ALL
lockd: ALL
statd: ALL
rquotad: ALL

Naturalmente, per una sicurezza maggiore, può essere conveniente inserire soltanto la direttiva seguente nel file /etc/hosts.deny:

ALL: ALL

137.3 Verifica del servizio

Quando il servizio NFS è attivo, si può verificare il funzionamento e l'utilizzo di questo con il programma showmount:

showmount [opzioni] [host]

Se non si indica un nodo, viene interrogato il servizio NFS presso l'elaboratore locale.

Segue la descrizione di alcune opzioni:

`-a \| --all`	elenca i clienti che utilizzano il proprio servizio e anche le directory che questi hanno montato;
`-e \| --exports`	elenca le directory esportate dal servente locale o dal servente remoto (se indicato come ultimo argomento del comando).

Quando si interroga la situazione dell'utilizzo in corso, le informazioni vengono tratte dal file /var/lib/xtab, che però potrebbe mostrare l'utilizzo attuale di directory che in realtà non lo sono più.

137.4 Porte coinvolte

Il servizio NFS si avvale per il suo funzionamento del Portmapper e di altri demoni specifici. In alcuni casi, questi demoni comunicano utilizzando porte TCP o UDP definite in modo dinamico, pubblicizzate poi dal Portmapper stesso. I punti di riferimento costanti sono solo quelli seguenti:

Porta TCP o UDP	Demone
111	Portmapper
2 049	`rpc.nfsd`

137.5 Dal lato del cliente

Con i sistemi GNU/Linux, l'utilizzo di un file system di rete richiede solo che il kernel sia stato predisposto per questo. Non occorrono programmi demone, basta il normalissimo mount.

Per montare un file system di rete si interviene in modo analogo a quello di una unità di memorizzazione locale, con la differenza fondamentale del modo di esprimere il dispositivo virtuale corrispondente al file system remoto da connettere.

host_remoto:directory_remota

La notazione sopra riportata rappresenta la porzione di file system remoto cui si vuole accedere, attraverso l'indicazione simultanea dell'elaboratore e della directory di partenza.

Supponendo che l'elaboratore dinkel.brot.dg conceda l'utilizzo della directory /usr/ e successive, l'elaboratore roggen.brot.dg potrebbe sfruttarne l'occasione attraverso il programma mount nel modo seguente:

mount -t nfs dinkel.brot.dg:/usr /usr

Inoltre, nell'elaboratore roggen.brot.dg si potrebbe aggiungere una riga nel file /etc/fstab in modo da automatizzarne la connessione (68.3.6).

dinkel.brot.dg:/usr  /usr         nfs      defaults     0  0

Sia attraverso il programma mount (preceduti dall'opzione -o), che nel file /etc/fstab (nel campo delle opzioni) possono essere specificate delle opzioni particolari riferite a questo tipo di file system. L'elenco seguente mostra solo alcune di queste opzioni, che possono avere rilevanza quando si monta un file system di rete.

`rsize=n`	Permette di specificare la dimensione dei pacchetti utilizzati in lettura da parte del cliente NFS. Il valore predefinito è di 1 024 byte.
`wsize=n`	Permette di specificare la dimensione dei pacchetti utilizzati in scrittura da parte del cliente NFS. Il valore predefinito è di 1 024 byte.
`timeo=n`	Permette di definire il valore del timeout, espresso in decimi di secondo, per il completamento delle richieste. In pratica, se entro quel tempo non si ottiene una conferma, si verifica un minor timeout e l'operazione viene ritentata con una durata di timeout doppia. Quando si raggiunge un timeout massimo di 60 secondi si verifica un major timeout. Il valore predefinito è sette, corrispondente a 0,7 secondi.
`hard`	Stabilisce che la connessione deve essere ritentata all'infinito, anche dopo un major timeout. È la modalità di funzionamento predefinita.
`soft`	Stabilisce che venga generato un errore di I/O non appena si verifica un major timeout. Questa modalità si contrappone a quella `hard`.
`intr`	Permette l'interruzione di una chiamata NFS attraverso l'uso di segnali. Può essere utile per interrompere una connessione quando il servente non risponde.
`nosuid`	Evita di prendere in considerazione i permessi di tipo SUID e SGID dei file eseguibili.

In condizioni normali, conviene usare solo le opzioni rw, hard e intr, come nell'esempio seguente che rappresenta sempre una direttiva del file /etc/fstab:

dinkel.brot.dg:/home  /home         nfs      rw,hard,intr       0  0

Per motivi di sicurezza, può essere utile anche l'opzione nosuid, se si teme che un programma compromesso, presente nel file system remoto, possa acquisire privilegi particolare e intaccare l'elaboratore locale dal quale lo si avvia.

137.6 Riferimenti

Tavis Barr, Nicolai Langfeldt, Seth Vidal, NFS HOWTO

<http://www.linux.org/docs/ldp/howto/HOWTO-INDEX/howtos.html>

1) Linux NFS GNU GPL

2) L'utente nobody corrisponde spesso al numero UID 65 534 o -2. Tuttavia, questo utente non ha un numero UID standard, tanto che in alcuni sistemi si preferisce utilizzare un numero più basso di quelli assegnati agli utenti comuni.