Un Network File System (NFS) consente di montare delle partizioni su un sistema remoto e utilizzarle come se fossero filesystem locali. Ci� permette l'amministratore del sistema di immagazzinare le risorse in una posizione centrale sulla rete, garantendo agli utenti autorizzati la possibilit� di accedervi costantemente.
In questo capitolo, vengono presentati solo i concetti fondamentali relativi a NFS, con l'aggiunta di qualche informazione supplementare; pertanto, se desiderate delle istruzioni specifiche circa la configurazione e il funzionamento di NFS su macchine client o server, dovrete consultare il capitolo Network File System (NFS) nella Red Hat Enterprise Linux System Administration Guide.
9.1. Come funziona
Al momento sono disponibili tre versioni di NFS. La versione 2 (NFSv2), che esiste gi� da alcuni anni, � ampiamente supportata. La versione 3 (NFSv3) offre alcune opzioni aggiuntive, come un file handling di lunghezza variabile e rapporti di errore pi� completi, ma non � completamente compatibile con i client di NFSv2. La versione 4 (NFSv4) include il Kerberos security, opera attraverso dei firewall e su Internet, non necessita pi� di portmapper, supporta le ACL, e utilizza delle operazioni di tipo stateful. Red Hat Enterprise Linux supporta le versioni dei client NFSv2, NFSv3 e client NFSv4, e durante l'esecuzione di un mounting tramite NFS, Red Hat Enterprise Linux utilizza NSFv4 per default in caso di connessione con un server che supporta tale versione.
Tutte le versioni di NFS possono usare Transmission Control Protocol (TCP) in esecuzione attraverso una rete IP, richiesto anche da NFSv4. NFSv2 e NFSv3 possono utilizzare User Datagram Protocol (UDP) in esecuzione attraverso una rete IP, in modo da fornire un collegamento di rete di tipo stateless tra il client ed il server.
Quando si utilizza con UDP NFSv2 o NFSv3, il collegamento UDP di tipo stateless in condizioni normali minimizza il traffico di rete, in quanto il server NFS invia un cookie al client dopo che lo stesso client viene autorizzato ad accedere al volume condiviso. Questo cookie � un valore casuale memorizzato dalla parte del server, viene trasmesso con le richieste RPC inviate dal client. Il server NFS pu� essere riavviato senza influenzare i client lasciando intatti il cookie. Tuttavia UDP � di tipo stateless, se il server si arresta inaspettatamente, i client UDP continuano a saturare la rete con delle richieste per il server. Per questa ragione, TCP � il protocollo preferito quando ci si collega ad un server NFS.
Quando si utilizza NFSv4, si viene a creare un collegamento di tipo stateless, e l'autenticazione dell'utente e del gruppo di Kerberos, insieme ad alcuni livelli di sicurezza, vengono resi disponibili in modo facoltativo. NFSv4 non presenta alcuna interazione con portmapper, rpc.mountd, rpc.lockd, e rpc.statd, poich� essi sono stati trasferiti all'interno del kernel. NFSv4 � in ascolto sulla porta TCP 2049.
Nota Bene
Con Red Hat Enterprise Linux, per default, UDP � il protocollo di trasporto per NFS. Consultate il capitolo intitolato Network File System (NFS) nella Red Hat Enterprise Linux System Administration Guide per maggiori informazioni sul collegamento ai server NFS usando TCP. UDP pu� essere usato a scopo di compatibilit� se necessario, ma un suo uso esteso � deprecato.
NFS effettua l'autenticazione solo quando un sistema client cerca di eseguire un montaggio della risorsa NFS condivisa. Per limitare l'accesso al servizio NFS, vengono usati i wrappers TCP, i quali leggono i file /etc/hosts.allow e /etc/hosts.deny per stabilire se concedere o negare a un determinato client l'accesso al server NFS. Per maggiori informazioni su come configurare i controlli di accesso con wrapper TCP, consultate il Capitolo 17.
Una volta passati i wrapper TCP da parte del client, il server NFS fa riferimento al suo file di configurazione, /etc/exports, per determinare se il client possiede i privilegi minimi necessari per montare i filesystem esportati. Dopo aver autorizzato l'accesso, tutte le operazioni di file e directory sono disponibili per l'utente.
Avvertenza
Se si utilizza NFSv2 oppure NFSv3, i quali non supportano l'autenticazione di Kerberos, i privilegi di montaggio NFS vengono garantiti al client host e non all'utente. Quindi, i filesystem esportati sono accessibili da un utente su di un client host con permessi di accesso. Quando si configurano le condivisioni NFS, fate molta attenzione su quale host ottenere i permessi di lettura/scrittura (rw).
Importante
Per far funzionare correttamente NFS con una installazione di default di Red Hat Enterprise Linux, con firewall abilitati, � necessario configurare IPTables insieme con la porta 2049 TCP di default.
Lo script di inizializzazione di NFS ed il processo rpc.nfsd, abilitano ora il processo di binding a qualsiasi porta specificata durante l'avvio del sistema. Tuttavia tale processo potrebbe essere propenso ad errori, se tale porta risulta non disponibile, oppure se si verifica un conflitto con un altro demone.
9.1.1. Servizi richiesti
Per permettere la condivisione dei file NFS, Red Hat Enterprise Linux utilizza un supporto a livello kernel combinato con una serie di processi del demone. NFSv2 e NFSv3 si affidano al Remote Procedure Calls (RPC), per codificare e decodificare le richieste tra i client ed i server. I servizi RPC con Linux sono controllati dal servizio portmap. Per condividere o montare i filesystem NFS, i seguenti servizi funzionano insieme, a seconda di quale versione di NFS � stata implementata:
nfs — Inizia i processi RPC appropriati per le richieste del servizio per i filesystem NFS condivisi.
nfslock — Un servizio facoltativo che inizia i processi RPC appropriati, per abilitare i client NFS ad eseguire un bloccaggio dei file sul server.
portmap — Il servizio RPC, per Linux, risponde alle richieste per i servizi RPC e imposta i collegamenti per il servizio RPC richiesto. Con NFSv4 tale procedura non viene utilizzata.
I seguenti processi RPC lavorano insieme per facilitare i servizi NFS:
rpc.mountd — Questo processo riceve la richiesta di montaggio da un client NFS e verifica se il filesystem richiesto � stato esportato. Viene iniziato automaticamente dal servizio nfs e non richiede una configurazione da parte dell'utente. Tale procedura non viene utilizzata con NFSv4.
rpc.nfsd — Questo processo implementa il server NFS. Funziona con il kernel di Linux per soddisfare le richieste dinamiche dei client NFS, come per esempio l'aggiunta di thread del server ogni qualvolta che si collega un client NFS. Questo processo corrisponde al servizio nfs.
rpc.lockd — Un processo facoltativo che permette ai client NFS di bloccare i file presenti sul server. Questo processo corrisponde al servizio nfslock. Tale procedura non viene utilizzata con NFSv4.
rpc.statd — Questo processo implementa il protocollo RPC Network Status Monitor (NSM), il quale notifica ai client NFS quando un server NFS viene riavviato in seguito ad uno spegnimento non corretto. Questo processo viene avviato automaticamente dal servizio nfslock e non richiede una configurazione da parte dell'utente. Tale procedura non viene utilizzata con NFSv4.
rpc.rquotad — Questo processo fornisce le informazioni sulla user quota per gli utenti remoti. Viene iniziato automaticamente dal servizio nfs e non necessita della configurazione da parte dell'utente.
rpc.idmapd — Questo processo fornisce il client NFSv4 e le chiamate server, le quali eseguono la mappatura tra i nomi NFSv4 di tipo on-the-wire (i quali rappresentano delle stringhe sotto forma di user@domain), e gli UID e GID locali. Per un funzionamento corretto di idmapd con NFSv4, � necessario configurare /etc/idmapd.conf. Questo servizio � necessario con NFSv4.
rpc.svcgssd — Questo processo fornisce il meccanismo di trasporto del server per il processo di autenticazione (Versione 5 di Kerberos) con NFSv4. Questo servizio � necessario con NFSv4.
rpc.gssd — Questo processo fornisce il meccanismo di trasporto del client per il processo di autenticazione (Versione 5 di Kerberos) con NFSv4. Questo servizio � necessario con NFSv4.
9.1.2. NFS e portmap
Nota Bene
La seguente sezione viene applicata solo alle implementazioni NFSv2 o NFSv3, che necessitano del servizio portmap per una backward compatibility.
Il servizio portmap � necessario per mappare le richieste RPC ai servizi corretti. I processi RPC notificano al portmap il proprio avvio, rivelando il numero della porta che stanno monitorando e quali numeri di programmi RPC sono pronti a servire. Il sistema client poi contatta portmap sul server con un particolare numero di programma RPC. A questo punto, il servizio portmap reindirizza il client al numero di porta corretto perch� possa comunicare con il servizio desiderato.
Dal momento che i servizi basati su RPC si affidano al portmap per effettuare tutte le connessioni con le richieste in ingresso dei client, � chiaro che portmap deve essere disponibile prima che i servizi di cui sopra siano avviati.
Il servizio portmap utilizza i wrappers TCP per il controllo dell'accesso, e le regole del controllo all'accesso per portmap influenzano tutti i servizi basati su RPC. Alternativamente, potete specificare a quale demone RPC di NFS applicare una determinata regola. Le pagine man relative a rpc.mountd e rpc.statd contengono informazioni sulla sintassi precisa di queste regole.
9.1.2.1. Troubleshooting NFS e portmap
Poich� portmap serve a coordinare i servizi RPC con i numeri di porta utilizzati per comunicare tra loro, pu� essere utile visualizzare lo stato dei servizi RPC correnti, utilizzando portmap nelle operazioni di troubleshooting. Il comando rpcinfo mostra ogni singolo servizio RPC con accanto il suo numero di porta, il numero di programma RPC, la versione ed il tipo di protocollo IP (TCP o UDP).
Se volete accertarvi che i servizi RPC di NFS corretti siano abilitati per il portmap, emettere il seguente comando come root:
rpcinfo -p
Quanto segue � un esempio di output del seguente comando:
Osservando l'output di questo comando, si nota che i servizi NFS corretti sono in esecuzione. Se uno dei servizi NFS non si avvia in modo corretto, portmap non sar� in grado di mappare sulla porta corretta, le richieste RPC dei client relative a quel servizio. In molti casi, se NFS non � presente nell'output rpcinfo, il riavvio di NFS causa la corretta registrazione del servizio con portmap, con un consequente avvio delle sue funzioni. Per informazioni su come iniziare NFS, consultare la Sezione 9.2.
Altre utili opzioni sono disponibili per il comando rpcinfo. Consultate la pagina man per maggiori informazioni.
