Nfs-kernel-server: condividere risorse tra macchine GNU/Linux

Versioni Compatibili Tutte le versioni supportate di Debian

Introduzione

NFS è l'acronimo di Network Filesystem, ovvero un filesystem utilizzato per montare cartelle remote sul proprio filesystem locale. L'utente in sintesi mette a disposizione una o più risorse (ovvero una directory del proprio file system) presenti su una delle sue macchine e le altre vi possono accedere come fosse una directory del proprio file system. In poche parole NFS permette di impostare un sistema di condivisioni simili a quello di Windows, o meglio, è Windows che ha "copiato" NFS per realizzare il suo sistema di condivisione.

Al di là di quest'aspetto 'estetico' il vantaggio principale consiste nel poter accedere alle risorse remote come se fossero risorse locali, cosa non possibile se si utilizzano protocolli come ftp/sftp o http (che sono alcuni dei protocolli sfruttati dalla funzione "Risorse --> Connetti al server" di GNOME). In sintesi è possibile manipolare file e directory sfruttando tutte le possibilità che un normale file system offre. A titolo d'esempio si cita la condivisione di calendari in Thunderbird; come noto è impossibile condvidere un calendario e/o una rubrica tramite protocollo sftp, mentre risulta possibile usando ftp/http anche se l'operazione risulta macchinosa ed in ogni caso le credenziali sono trasmesse in chiaro. Usando NFS invece l'operazione non presenta differenze rispetto al caso in cui il calendario fosse stato salvato in una posizione realmente presente sul disco rigido della propria macchina.

Sia chiaro che ogni macchina può simultaneamente condividere alcune risorse che accedere a quelle presenti su altre macchine.

Nel seguito si vedrà come configurare sia la macchina che condivide le risorse (server) sia quelle che dovranno accedervi (client), tuttavia risulta opportuno esporre prima alcune considerazioni sulla sicurezza.

Sicurezza

Nel caso di una piccola rete domestica/aziendale il discorso sicurezza lascia il tempo che trova, dato che di norma in questi casi hanno accesso alle macchine solo persone fidate. Se però così non fosse è bene essere consapevoli che la condivisione NFS non abbinata ad un sistema di autenticazione centralizzato, come kerberos o ldap, è causa di gravi vulnerabilità.

Con i vari protocolli di rete come ftp, sftp, ecc. è infatti necessario effettuare un'autenticazione presso il server ospitante le risorse (che poi queste credenziali siano trasmesse in chiaro o cifrate è un altro paio di maniche), mentre con NFS non viene fatta alcuna autenticazione "diretta". Una volta definite le risorse da esportare l'accesso a queste è regolato in base all'UID dell'utente; poiché gli UID degli utenti di base sono assegnati in modo crescente a partire da uno stesso numero (cioè 1000, almeno per debian e derivati), a meno che un utente non decida di cambiarli sua sponte, è evidente come l'accesso alle stesse sia tutt'altro che sicuro. In realtà è possibile restringere l'accesso alle stesse in base all'indirizzo IP (man portmap), tuttavia questo accorgimento potrebbe non essere adeguato e/o sufficiente. Poiché su ogni macchina almeno un utente deve esistere, è chiaro per quanto detto che tutte le macchine hanno almeno un utente con lo stesso UID (a meno di modifiche fatte appositamente), cioè quello creato in fase d'installazione. Il risultato è che i vari utenti della rete potrebbero avere accesso a risorse cui non dovrebbero o che comunque non gli interessano, oppure non avere accesso alle risorse che gli servono, ecc. Basta infatti che l'UID dell'utente con cui ci si è autenticati sul computer 'A' coincida con uno di quelli associati ai nomi_utente del PC 'B'.

Esempio: due utenti possiedono entrambi due computer con sistema linux e decidono di mettere in rete le rispettive macchine per condividere alcune cartelle. L'utente 'A', che possiede il computer 'A', durante l'installazione di linux ha scelto come nome_utente 'tizio', mentre l'utente B proprietario del computer 'B' ha scelto come nome utente 'caio'. Di norma perché l'utente 'A' possa accedere alle risorse su 'B' è necessario che l'utente 'B' crei un utenza apposita sul PC 'B' e che poi comunichi nome utente e password all'utente 'A'. Col filesystem NFS il controllo dell'accesso alle varie risorse non viene fatto su una coppia di credenziali "nome_utente+password", ma solo sugli UID degli utenti; poiché sia 'tizio' che 'caio' sono stati i primi utenti creati rispettivamente sui PC 'A' e 'B' è evidente che dovranno avere anche lo stesso UID, avendo già detto che linux associa di base UID=1000 al primo utente creato. Il risultato finale nella migliore delle ipotesi è che l'utente 'A' acceda alle sole risorse scelte da 'B' con i privilegi di 'B' invece che di 'A' (cioè quelli attribuiti da 'B' ad 'A') e viceversa. Nel peggiore dei casi, poiché quando si condivide una cartella vengono automaticamente condivise tutte le sotto cartelle, l'utente 'A' avrà accesso con i privilegi di 'B' (e viceversa) a cartelle cui normalmente non avrebbe dovuto avere accesso, il che può essere più o meno grave a seconda della sensibilità dei dati in esse contenute.

Come già detto inizialmente questo problema è normalmente puramente teorico, poiché nella maggior parte delle piccole LAN private l'accesso alla rete ed ai PC che la compongono è possibile solo a persone di fiducia e/o in ogni caso le risorse condivise non contegono dati particolarmente sensibili. Se però così non fosse, l'utente sarebbe costretto ad implementare o un sistema di autenticazione come kerberos/ldap oppure a RINUNCIARE all'uso di NFS.

Impostazioni lato server

Installazione

Installare i pacchetti necessari:

# apt-get install nfs-kernel-server portmap

Configurazione

Esempio 1

Convenzione IP della macchina server: 192.168.1.10; directory da condividere: /media/storage

Ora editare col vostro editor preferito (gedit, kate, vim, ...) il file /etc/exports ed aggiungere la seguente riga:

/media/storage      192.168.1.0/24(rw,sync,no_subtree_check)

Nota:

• 192.168.1.0/24 indica l'abilitazione a tutte le macchine della rete 192.168.1
  • se si vuole abilitare una o determinate macchine basta specificarne l'IP
• rw indica che tutti hanno i permessi di lettura e scrittura
  • se si vogliono dare solo i permessi di lettura, sostituire rw con ro
• /media/storage è la directory del nostro filesystem che vogliamo condividere

Completare dando ai vari client i permessi per l'accesso alla macchina server: editare il file /etc/hosts.allow ed inserire

portmap: 192.168.1

Come si capisce, in questo modo si da il permesso di accedere a tutta la LAN; se si vogliono delle restrizioni agire di conseguenza inserendo l'indirizzo specifico del/i client.

Ora lanciamo il demone e rendiamo disponibile la directory condivisa:

# /etc/init.d/nfs-kernel-server start 
# exportfs -a

Esempio 2

Editare il file /etc/default/nfs-common ed assicurarsi che le righe contenti le variabili NEED_IDMAPD= e NEED_GSSD= appaiano così:

NEED_IDMAPD=yes
NEED_GSSD=no

Editare il file /etc/default/nfs-kernel-server ed assicurarsi che la riga contente la variabile NEED_SVCGSSD= appaia così:

NEED_SVCGSSD=no

A questo punto è possibile definire le condivisioni editando il file /etc/exports. Leggendo il manuale si trova consigliato di definire sempre la cartella che fungerà da radice per tutte le altre, cioè quella che contiene tutte le altre che si desidera impostare. In pratica ogni riga del file /etc/exports descrive una cartella. Ad esempio inserendo le seguenti righe:

/home       192.168.1.0/24(rw,fsid=0,no_subtree_check,sync)
/home/altro 192.168.1.0/24(rw,no_subtree_check,sync)

Si condivide la cartella /home e tutte le sue sottocartelle. Specificare la sottocartella /home/altro è inutile a meno che questa non risieda fisicamente su un disco fisso diverso da /home. Si noti che se le risorse da esportare non sono tutte contenute dentro una medesima directory potrebbe essere conveniente rimontarle prima in un'altra cartella e poi esportare questa (si veda più avanti). La dicitura 192.168.1.0/24 serve a restringere l'accesso alla risorsa /home alle sole richieste provenienti dagli indirizzi IP che vanno da 192.168.1.1 a 192.168.1.254. Una richiesta che per esempio dovesse provenire da 192.168.2.15 sarebbe rifiutata. Tra ( ) si indicano le opzioni:

• rw: abilità la cartella in lettura e scrittura, ammesso comunque che l'utente abbia il permesso di scrivere su quella cartella; indicando ro si limita la possibilità di scrivere anche per quegli utenti che se non accedessero da remoto avrebbero di norma il permesso di scrivere.
• fsid=0: identifica la cartella come radice per il filesystem da esportare. Una sola cartella può avere valore di fsid pari a 0.
• no_subtree_check: velocizza l'accesso alle risorse a scapito di un minimo aumento del rischio sicurezza.
• sync: impone sincronia tra client e server. L'alternativa è async, ma è meglio evitarla poiché in caso di crash o eventi imprevisti aumenta la probabilità di causare danni al filesystem.

Per rendere operative le modifiche al file /etc/exports eseguire:

# /etc/init.d/nfs-kernel-server restart

RIMONTARE LE DIRECTORY

È possibile rimontare una o più cartelle in una seconda posizione col risultato che il contenuto delle cartelle risulta accessibile da due differenti posizioni (quella originale e quella dove si rimonta). Per far ciò è prima necessario creare il punto di mount, per esempio:

# mkdir -p /export/utente
# mkdir -p /export/altro

Supponendo di voler rimontare le cartelle /home/utente e /altro rispettivamente in /export/utente e /export/altro:

# mount --bind /home/utente /export/utente
# mount --bind /altro       /export/altro

Per evitare di dover ridigitare ad ogni riavvio i precedenti comandi basta aggiungere le seguenti due righe al file /etc/fstab:

/home/utente /export/utente none bind 0 0
/altro       /export/altro none bind 0 0

A questo punto per esportare la cartella /export non rimane che editare il file etc/exports

/export        192.168.1.0/24(rw,fsid=0,no_subtree_check,sync)
/export/utente 192.168.1.0/24(rw,no_subtree_check,sync,nohide)
/export/altro  192.168.1.0/24(rw,no_subtree_check,sync,nohide)

Da notare l'aggiunta dell'opzione nohide, che non deve essere omessa pena l'impossibilità di vedere il contenuto delle sottocartelle di export sulle macchine client. Quest'opzione risulta utile proprio in questo tipo di situazione specifica, ovvero dove alcune cartelle vengono "rimontate" in una seconda posizione (l'opzione crossmnt ha un effetto molto simile a nohide). In caso di problemi a visualizzare il contenuto delle cartelle provare a riavviare server e client.

Impostazioni lato client

Installazione

Installare i pacchetti necessari

# apt-get install nfs-common portmap

Configurazione

Una volta definite le risorse da condividere è possibile caricarle su un altro PC in modo permanente (statico) o su richiesta (dinamico). Il primo approccio è caratterizzato da un consumo di banda prolungato nel tempo, in quanto client e server devono costantemente scambiare informazioni (anche se non si utilizzano direttamente le risorse condivise), nel secondo invece il consumo di banda avviene solo quando si ha un effettivo accesso alle risorse. Nel caso di una LAN è ragionevole supporre che la banda non sia un problema, ma nel caso di condivisioni attraverso internet il discorso potrebbe cambiare. In generale se l'accesso alle risorse remote non è frequente è più logico utilizzare l'approccio dinamico.

Esempio 1

Creare la dirctory dove si vuol montare la directory condivisa, esempio: /media/condivisa

# mkdir /media/condivisa

editare il file /etc/fstab ed inserire

192.168.1.10:/media/storage /media/condivisa nfs user,rw,auto,hard  0   0

Nota:

• 192.168.1.10:/media/storage sono l'indirizzo e la directory del server
  • aggiungere tante entry quante sono le directory condivise
• /media/xxx directory raccomandata per montare le risorse
• /media/condivisa è la directory dove sarà montata la risorsa
• nfs è il tipo di file system
• user permette a qualsiasi utente di montare,anche manualmente,la risorsa
• rw sono i permessi di lettura e scrittura
  • modificare in ro se si desideramo solo permessi di lettura
• auto la risorsa viene montata automaticamente
  • modificare in noauto se si vuole montare la partizione manualmente

Editare il file /etc/hosts.allow ed aggiungere

portmap: 192.168.1.10

Ora avviare il demone e montare la partizione:

# /etc/init.d/nfs-common start
# mount -a

Esempio 2

Sia che si voglia caricare le risorse remote in modo statico che dinamico, La prima cosa da fare è assicurarsi che sul PC client sia installato il pacchetto nfs-common, in caso contrario installarlo. Editare il file /etc/default/nfs-common ed assicurarsi che la riga contente la variabile NEED_IDMAPD= appaia così:

NEED_IDMAPD=yes

Fatto ciò l'utente deve decidere se montare le risorse in modo statico o dinamico, NON È POSSIBILE adottare entrambe le soluzioni contemporaneamente.

IMPORTANTE: si noti che sul PC cliente se si decide di montare le risorse remote sotto la cartella /home/nome_utente allora tutte le cartelle compariranno anche sul desktop, proprio come se fosse stato collegato un disco esterno o una chiavetta USB. È possibile aggirare il problema creando la cartella in un'altra posizione e poi creando un collegamento simbolico alla stessa nella cartella utente.

METODO STATICO

Per montare staticamente una risorsa il comando da usare è il solito mount, infatti questo comando supporta una valanga di protocolli e filesystem, tra cui appunto NFS. Prima di montare le risorse remote è necessario creare il punto di mount locale, si supponga per esempio di voler montare le suddette risorse in /home/nfs (si sconsiglia di montare le risorse direttamente in cartelle già esistenti che contengono già altri file/cartelle, come /home o peggio /), ergo restando all'esempio:

# mkdir /home/nfs

Fatto ciò è possibile montare le risorse remote digitando da terminale:

# mount -t nfs4 indirizzo_server:/ /home/nfs

Dove con indirizzo_server si identifica il server con le risorse condivise; può essere nella forma di un IP (es.: 192.168.5.92) oppure di un alias (es.: mioserver, in tal caso come sempre si presuppone che il computer client sia in grado di risolvere correttamente l'alias). Si noti che si è scritto indirizzo_server:/ e non indirizzo_server:/home poiché nel file /etc/exports del server la cartella /home è stata definita come radice (si ricorda che saranno esportate automaticamente anche tutte le sotto cartelle della cartella indicata col comando mount). A questo punto sarà sufficiente esplorare la cartella /home/nfs per vedere le risorse esportate. Per smontare le risorse remote è sufficiente digitare:

# umount /home/nfs

Se si desidera caricare automaticamente le risorse remote all'avvio del PC, evitando così di dover ridigitare ogni volta il precedente comando, è sufficiente editare il file /etc/fstab aggiungendo in coda la seguente riga:

indirizzo_server:/ /home/nfs nfs4 _netdev,auto 0 0

Dove _netdev e auto sono due opzioni che impongono rispettivamente di aspettare che i dispositivi di rete siano stati caricati e di caricare automanticamente le risorse remote presenti su indirizzo_server.

NOTA BENE: qualora si decida di abbandonare il metodo statico per quello dinamico è evidente che prima cosa è necessario smontare tutte le risorse montate staticamente che si intende gestire dinamicamente, e poi eliminare (o commentare) la riga eventualmente aggiunta al file /etc/fstab.

METODO DINAMICO

Per usare questo metodo è necessario il pacchetto autofs, pertanto se non installato procedere alla sua installazione:

apt-get install autofs5

A questo punto è necessario modificare il file /etc/auto.master aggiungendo una riga del tipo /home/nfs /etc/auto.nfs. Questa riga dice che le risorse remote specificate nel file /etc/auto.nfs (naturalmente l'utente è liberissimo di scegliere un altro nome al posto di auto.nfs, basta essere coerenti nel seguito) andranno montante all'interno della cartella /home/nfs (che deve esistere! Autofs non crea il punto di mount). Come già scritto nel caso statico si sconsiglia di montare le risorse direttamente in cartelle già esistenti che contengono già altri file/cartelle, come /home o peggio /. È possibile definire più tipi di risorse remote inserendo più righe, il punto è che per ognuna è necessario indicare il punto di mount e il file contenente le relative istruzioni. A questo punto per quanto detto l'utente deve creare il suo file auto.nfs (o come è stato chiamato) usando il suo editor di testo preferito, ad esempio:

# gedit /etc/auto.nfs

che ovviamente apparirà vuoto essendo appena stato creato dall'utente. Inserire la seguente riga:

nome_arbitrario -fstype=nfs4,hard,intr indirizzo_server:/

Quanto appena scritto viene definito in gergo indirect map. Osservando la riga si nota subito essere composta da tre parti:

1. Key: in questo esempio è nome_arbitrario, a sottolineare che trattasi di una parola qualsiasi a scelta dell'utente. È il nome della sottocartella di /home/nfs/ in cui compariranno le risorse remote. Si badi bene che diversamente da quanto fatto in precedenza, la suddetta cartella viene creata al momento da autofs, quindi l'utente NON deve creare tale sottocartella in anticipo.
2. Options: banalmente la sezione delle opzioni, in questo caso sono tre cioè -fstype=nfs4, hard e intr. È naturalmente possibile specificare ulteriori opzioni (si veda il manuale di mount), basta separarle con una virgola.
3. Location: definisce il percorso per caricare le risorse remote. In quest'esempio è indirizzo_server:/ (si ricordi che / non indica la radice del filesystem del server, ma la cartella definita come radice in /etc/exports sul server, cioè /home restando all'esempio), che come già ripetuto può essere sia un IP che un alias.

Prima di rendere operativo automount assicurarsi di aver smontato eventuali risorse statiche relative al server per cui abbiamo configurato auto.nfs. Fatto ciò digitare:

# /etc/init.d/autofs reload

Un modo per testare se le risorse remote vengono montate correttamente è digitare da terminale:

$ ls /home/nfs/nome_arbitrario

Se il comando restituisce l'elenco di file e cartelle contenute nella cartella /home del server significa che l'operazione di automount è andata a buon fine. Le risorse remote rimangono montate di base fino a 10 minuti dall'ultimo accesso alle stesse. Nota Bene: digitare ls /home/nfs/ non mostra nulla poiché il comando non è sufficiente ad innescare l'automount delle risorse remote, quindi viene mostrato il contenuto della sola cartella nfs che è vuota per costruzione (o meglio dovrebbe essere tale, visto che come già detto è sconsigliato montare risorse in una cartella contenente file e sotto cartelle). Per innescare l'automount serve proprio la parola chiave (la key) indicata nel file /etc/auto.nfs, cioè nome_arbitrario. Per lo stesso motivo in nautilus facendo click sulla cartella /home/nfs non apparirà nulla, bisogna invece cliccare su "vai --> posizione" e digitare /home/nfs/nome_arbitrario seguito da invio; in realtà anche questo non è detto che funzioni, in tal caso è d'obbligo l'uso del terminale digitando per esempio:

$ cd /home/nfs/nome_arbitrario

Fatto ciò le risorse risulteranno visibile anche in nautilus.

Possibili Problemi

Tra i problemi tipici c'è quello di non riuscire a montare le risorse remote. Una prima verifica banale è quella di assicurarsi che la cartella dove devono essere montate le risorse remote sia indicata correttamente (per esempio /home/nfs è DIVERSO da /home/NFS). Una seconda causa potrebbe essere dovuta al numero della porta che NFS sceglie casualmente, infatti se il numero della porta è maggiore di 1024 scatta un errore di sicurezza; in tal caso è sufficiente aggiungere alle opzioni indicate nel file /etc/exports anche insecure, ad esempio:

/home       192.168.1.0/24(rw,fsid=0,no_subtree_check,sync,insecure)
/home/altro 192.168.1.0/24(rw,no_subtree_check,sync,insecure)

Un altro motivo potrebbe essere costituito dal set di permessi delle cartelle esportate; provare ad impostare temporaneamente i loro permessi su 777. Se il problema è risolto provare a reimpostare i permessi sul vecchio schema e vedere se l'errore si ripropone. Potrebbe capitare che trasferendo grossi file il server si congeli obbligando ad un riavvio forzato, in tal caso potrebbe essere utile specificare sulla macchina client le opzioni rsize e wsize indicando valori non troppo grandi, per esempio:

• Caso statico: mount -t nfs4 -o rsize=8192,wsize=8192 indirizzo_server:/ /home/NFS

• Caso statico, file /etc/fstab aggiungere (o modificare quella già esistente): indirizzo_server:/ /home/NFS nfs4 _netdev,auto,rsize=8192,wsize=8192 0 0

• Caso dinamico, file /etc/auto.nfs aggiungere (o modificare quella già esistente) nome_arbitrario -fstype=nfs4,rsize=8192,wsize=8192 indirizzo_server:/

A tal proposito potrebbe essere utile leggere questo. Nel caso di autofs se il server è spento e sulla macchina client è presente un collegamento simbolico alle risorse esterne, creato per esempio con un comando del tipo:

# ln -s /home/nfs/nome_arbitrario /home/nome_utente/nome_arbitrario

è probabile che si noti un ritardo di circa 3 minuti all'avvio di gnome ed ogni volta che si lancia nautilus per visualizzare una qualche cartella. La semplice presenza del collegamento simbolico è infatti sufficiente ad innescare una richiesta di caricamento per le risorse remote, con la conseguenza che essendo il server spento queste falliscano inevitabilmente. Di base autofs è impostato per ripetere la richiesta di caricamento risorse dopo 60s per un massimo di 3 volte, ecco dunque da dove nascerebbero i 3 minuti di ritardo sistematico. In tal caso la soluzione più semplice è rinunciare ai collegamenti simbolici verso le risorse remote caricate tramite nfs, altrimenti è possibile ridurre i valori delle variabili timeo e retrans specificandoli nel file /etc/auto.nfs (o come è stato chiamato):

nome_arbitrario -fstype=nfs4,timeo=150,retrans=2 indirizzo_server:/

In questo esempio il tempo di timeout viene ridotto a 150 decimi di secondo (15s) ed il numero di tentativi ridotto a 2, così che ogni volta il ritardo sia di "soli" 15x2=30s. Altre problematiche sono descritte al punto 7 di questa pagina.

Riferimenti esterni

Manuali: man nfs e man portmap

Pagine web:

• Sourceforge, pagina ufficiale.
• linux-nfs.
• linux-tutorial.

xtow

--Wtf 17:13, 5 giu 2011 (CEST)