[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico] [volume] [parte]
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.
Per poter condividere file attraverso NFS, sia come cliente che come servente, occorre includere il supporto al file system NFS nel kernel (sezione 49.2.20).
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:
|
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:
|
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. (1) 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 ... |
Il programma rpc.mountd è il demone che si occupa di gestire l'innesto 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 gli innesti 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.
Il programma 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 lucchetto 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 lucchetto 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 [nodo][(opzioni)]... |
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:
L'elenco seguente mostra alcuni esempi di record di questo file; tuttavia si osservi che non tutti i serventi NFS si comportano allo stesso modo, pertanto alcune direttive possono funzionare da una parte e altre da un'altra.
|
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:
#
exportfs -ra
[Invio]
Il programma exportfs può anche essere usato per esportare al volo una directory, senza modificare il file |
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:
|
È 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, conviene utilizzare le direttive seguenti nel file /etc/hosts.allow
:
|
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:
|
Naturalmente, per una sicurezza maggiore, può essere conveniente inserire soltanto la direttiva seguente nel file /etc/hosts.deny
:
|
Quando il servizio NFS è attivo, si può verificare il funzionamento e l'utilizzo di questo con il programma showmount:
showmount [opzioni] [nodo] |
Se non si indica un nodo, viene interrogato il servizio NFS presso l'elaboratore locale.
Tabella 203.11. Alcune opzioni. |
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ù.
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:
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 innestare 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.
nodo_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 (114.1.6).
|
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 innesta un file system di rete.
|
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
:
|
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.
Tavis Barr, Nicolai Langfeldt, Seth Vidal, NFS HOWTO
<http://www.linux.org/docs/ldp/howto/HOWTO-INDEX/howtos.html>
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 nfs_con_i_sistemi_gnu_linux.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico]