|
|
| (117 versioni intermedie di 3 utenti non mostrate) |
| Riga 1: |
Riga 1: |
| {{Versioni compatibili}} | | {{File_System |
| | |precedente=RAID:_Redundant_Array_of_Indipendent_Disks |
| | |successivo=Samba:_guida_estesa |
| | }}{{Versioni compatibili|Lenny|Squeeze|Wheezy|Jessie}}{{Template:NFS}} |
| | = Introduzione = |
|
| |
|
| == Introduzione ==
| | NFS è l'acronimo di Network Filesystem, ovvero un filesystem utilizzato per montare cartelle remote sul proprio filesystem locale (o meglio per condividere in una LAN filesystem presenti su un server). L'utente in sintesi mette a disposizione una o più risorse (ovvero una directory del proprio filesystem) presenti su una delle sue macchine e le altre vi possono accedere come fosse una directory del proprio filesystem. 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. |
|
| |
|
| 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. | | {{Box|NOTE| |
| | * L'utilizzo di NFS è consigliato solo all'interno di una LAN, in caso contrario è preferibile ricorrere ad altre soluzioni come [[SSHFS: montare una risorsa remota sfruttando FUSE ed SSH | SSHFS]]. |
| | * Sebbene NFS sia privilegiato in ambienti UNIX puri è comunque possibile sfruttarlo anche in ambienti misti con client Windows. |
| | }} |
|
| |
|
| 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. | | 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 filesystem offre.<br/> |
| 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, menter 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. | | A titolo d'esempio si cita la condivisione di calendari in Thunderbird; come noto è impossibile condividere 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.
| | = Versioni = |
|
| |
|
| 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.
| | Da [http://it.wikipedia.org/wiki/Network_File_System Wikipedia]:<br /><br /> |
|
| |
|
| == Sicurezza ==
| | ''Network File System (NFS) è un protocollo sviluppato inizialmente da Sun Microsystems nel 1984 e definito dagli RFC 1094, 1813, (3010) e 3530.''<br /><br /> |
|
| |
|
| 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à.
| | In questi trent'anni il protocollo NFS è stato migliorato più volte attraverso la definizione di nuovi versioni, pertanto trascurando quelle più vecchie ormai completamente obsolete, ci si limiterà alla versione 3 (1995) e alla versione 4 (2000).<br /> |
| | Per completezza si segnala che da qualche anno è in sviluppo la versione 4.1 del protocollo. |
|
| |
|
| 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.
| | === Importante === |
| In realtà è possibile restringere l'accesso alle stesse in base all'indirizzo IP (<code>man portmap</code>), 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'.
| | * Dal punto di vista della configurazione non esistono differenze tra le versioni 2 e 3, mentre la versione 4 introduce alcune piccole differenze di sintassi. |
| 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.
| | * La scelta del protocollo da utilizzare avviene lato client e non lato server, ovvero attraverso ''mount'' e quindi tutti gli strumenti che da esso dipendono (<code>/etc/fstab</code>, <code>autofs</code>, ecc.). A meno che l'utente non specifichi esplicitamente il protocollo da usare tramite l'opzione ''nfsvers'' (o l'equivalente ''vers'') avverrà una negoziazione per tentativi tra client e server partendo dalla versione 4; in caso di fallimento verrà provata la versione 3, dopo di che, se anche questa fallisce, procede automaticamente con un ultimo tentativo usando la versione 2 del protocollo. |
| | * È possibile restringere lato server le versioni utilizzabili del protocollo editando opportunamente il parametro <code>RPCMOUNTDOPTS</code> del file <code>/etc/default/nfs-kernel-server</code>. Richieste di utilizzo di versioni bloccate del protocollo da parte dei client vengono negate. |
|
| |
|
| 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.
| | = Sicurezza = |
|
| |
|
| == Impostazioni lato server ==
| | 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à. |
|
| |
|
| === Installazione ===
| | 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 solo in base all'[[UID]] dell'utente (V3 e precedenti), oppure in base all'UID per quanto riguarda i permessi tipo unix e in base al nome utente per quanto riguarda regole ACL e determinazione del proprietario (da V4, [http://blather.michaelwlucas.com/archives/796 citazione]); 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.<br/> |
| | | In realtà è possibile restringere l'accesso alle stesse in base all'indirizzo IP (in Lenny <code>man portmap</code>, <code>man exports</code> per tutti), tuttavia questo accorgimento potrebbe non essere adeguato e/o sufficiente.<br/> |
| Installare i pacchetti necessari:
| | 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.<br/> |
| | | 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'. |
| <pre># apt-get install nfs-kernel-server portmap</pre>
| |
| | |
| === Configurazione ===
| |
| | |
| ==== Esempio 1 ====
| |
| | |
| {{Box|Convenzione|IP della macchina server: <code>192.168.1.10</code>; directory da condividere: <code>/media/storage</code>}}
| |
| | |
| Ora editare col vostro editor preferito (gedit, kate, vim, ...) il file <code>/etc/exports</code> ed aggiungere la seguente riga:
| |
| <pre>/media/storage 192.168.1.0/24(rw,sync,no_subtree_check)</pre>
| |
| | |
| 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 <code>/etc/hosts.allow</code> ed inserire
| |
| <pre>portmap: 192.168.1</pre>
| |
| | |
| 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:
| |
| <pre># /etc/init.d/nfs-kernel-server start
| |
| # exportfs -a</pre>
| |
| | |
| ==== Esempio 2 ====
| |
| | |
| Editare il file <code>/etc/default/nfs-common</code> ed assicurarsi che le righe contenti le variabili <code>NEED_IDMAPD=</code> e <code>NEED_GSSD=</code> appaiano così:
| |
| | |
| <pre>
| |
| NEED_IDMAPD=yes
| |
| NEED_GSSD=no
| |
| </pre>
| |
| | |
| Editare il file <code>/etc/default/nfs-kernel-server</code> ed assicurarsi che la riga contente la variabile <code>NEED_SVCGSSD=</code> appaia così:
| |
| | |
| <pre>NEED_SVCGSSD=no</pre>
| |
| | |
| A questo punto è possibile definire le condivisioni editando il file <code>/etc/exports</code>. 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 <code>/etc/exports</code> descrive una cartella. Ad esempio inserendo le seguenti righe:
| |
| | |
| <pre>
| |
| /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)
| |
| </pre>
| |
| | |
| Si condivide la cartella <code>/home</code> e tutte le sue sottocartelle. Specificare la sottocartella <code>/home/altro</code> è inutile a meno che questa non risieda fisicamente su un disco fisso diverso da <code>/home</code>. 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 <code>/home</code> 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:
| |
| | |
| * <code>rw</code>: 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.
| |
| * <code>fsid=0</code>: identifica la cartella come radice per il filesystem da esportare. Una sola cartella può avere valore di fsid pari a 0.
| |
| * <code>no_subtree_check</code>: velocizza l'accesso alle risorse a scapito di un minimo aumento del rischio sicurezza.
| |
| * <code>sync</code>: 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 <code>/etc/exports</code> eseguire:
| |
| | |
| <pre># /etc/init.d/nfs-kernel-server restart</pre>
| |
| | |
| ===== 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:
| |
| | |
| <pre>
| |
| # mkdir -p /export/utente
| |
| # mkdir -p /export/altro
| |
| </pre>
| |
| | |
| Supponendo di voler rimontare le cartelle <code>/home/utente</code> e <code>/altro</code> rispettivamente in <code>/export/utente</code> e <code>/export/altro</code>:
| |
| | |
| <pre>
| |
| # mount --bind /home/utente /export/utente
| |
| # mount --bind /altro /export/altro
| |
| </pre>
| |
| | |
| Per evitare di dover ridigitare ad ogni riavvio i precedenti comandi basta aggiungere le seguenti due righe al file <code>/etc/fstab</code>:
| |
| | |
| <pre>
| |
| /home/utente /export/utente none bind 0 0
| |
| /altro /export/altro none bind 0 0
| |
| </pre>
| |
| | |
| A questo punto per esportare la cartella <code>/export</code> non rimane che editare il file <code>etc/exports</code>
| |
| | |
| <pre>
| |
| /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/www 192.168.1.0/24(rw,no_subtree_check,sync,nohide) | |
| </pre>
| |
| | |
| Da notare l'aggiunta dell'opzione <code>nohide</code>, 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
| |
| <pre># apt-get install nfs-common portmap</pre>
| |
| | |
| === 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: <code>/media/condivisa</code>
| |
| <pre># mkdir /media/condivisa</pre>
| |
| editare il file <code>/etc/fstab</code> ed inserire
| |
| <pre>192.168.1.10:/media/storage /media/condivisa nfs user,rw,auto,hard 0 0</pre>
| |
| | |
| 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
| |
| <pre>portmap: 192.168.1.10</pre>
| |
| | |
| Ora avviare il demone e montare la partizione:
| |
| <pre># /etc/init.d/nfs-common start
| |
| # mount -a</pre>
| |
| | |
| ==== 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 <code>NEED_IDMAPD=</code> appaia così:
| |
| | |
| <pre>NEED_IDMAPD=yes</pre>
| |
| | |
| 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 <code>/home/nome_utente</code> 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 <code>mount</code>, 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 <code>/home/nfs</code> (si sconsiglia di montare le risorse direttamente in cartelle già esistenti che contengono già altri file/cartelle, come <code>/home</code> o peggio <code>/</code>), ergo restando all'esempio:
| |
| | |
| <pre># mkdir /home/nfs</pre>
| |
| | |
| Fatto ciò è possibile montare le risorse remote digitando da terminale:
| |
| | |
| <pre># mount -t nfs4 indirizzo_server:/ /home/nfs</pre>
| |
| | |
| Dove con <code>indirizzo_server</code> 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.: <code>mioserver</code>, in tal caso come sempre si presuppone che il computer client sia in grado di risolvere correttamente l'alias). Si noti che si è scritto <code>indirizzo_server:/</code> e non <code>indirizzo_server:/home</code> poiché nel file <code>/etc/exports</code> del server la cartella <code>/home</code> è stata definita come radice (si ricorda che saranno esportate automaticamente anche tutte le sotto cartelle della cartella indicata col comando <code>mount</code>). A questo punto sarà sufficiente esplorare la cartella <code>/home/nfs</code> per vedere le risorse esportate.
| |
| Per smontare le risorse remote è sufficiente digitare:
| |
| | |
| <pre># umount /home/nfs</pre>
| |
| | |
| 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 <code>/etc/fstab</code> aggiungendo in coda la seguente riga:
| |
| | |
| <pre>indirizzo_server:/ /home/nfs nfs4 _netdev,auto 0 0</pre>
| |
| | |
| Dove <code>_netdev</code> e <code>auto</code> 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 <code>/etc/fstab</code>.
| |
| | |
| ===== METODO DINAMICO =====
| |
| | |
| Per usare questo metodo è necessario il pacchetto autofs, pertanto se non installato procedere alla sua installazione:
| |
| | |
| <pre>apt-get install autofs5</pre>
| |
| | |
| A questo punto è necessario modificare il file <code>/etc/auto.master</code> aggiungendo una riga del tipo <code>/home/nfs /etc/auto.nfs</code>.
| |
| Questa riga dice che le risorse remote specificate nel file <code>/etc/auto.nfs<code> (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 <code>/home/nfs</code> (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 <code>/home</code> o peggio <code>/</code>. È 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 <code>auto.nfs</code> (o come è stato chiamato) usando il suo editor di testo preferito, ad esempio:
| |
| | |
| <pre># gedit /etc/auto.nfs</pre>
| |
| | |
| che ovviamente apparirà vuoto essendo appena stato creato dall'utente. Inserire la seguente riga:
| |
| | |
| <pre>nome_arbitrario -fstype=nfs4 indirizzo_server:/</pre>
| |
| | |
| Quanto appena scritto viene definito in gergo ''indirect map''. Osservando la riga si nota subito essere composta da tre parti:
| |
| | |
| # ''Key'': in questo esempio è <code>nome_arbitrario</code>, a sottolineare che trattasi di una parola qualsiasi a scelta dell'utente. È il nome della sottocartella di <code>/home/nfs/</code> 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.
| |
| # ''Options'': banalmente la sezione delle opzioni, in questo caso una sola cioè <code>-fstype=nfs4</code>. È naturalmente possibile specificare più opzioni, basta separarle con una virgola.
| |
| # ''Location'': definisce il percorso per caricare le risorse remote. In quest'esempio è <code>indirizzo_server:/</code> (si ricordi che <code>/</code> non indica la radice del filesystem del server, ma la cartella definita come radice in <code>/etc/exports</code> sul server, cioè <code>/home</code> 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:
| |
| | |
| <pre># /etc/init.d/autofs reload</pre>
| |
| | |
| Un modo per testare se le risorse remote vengono montate correttamente è digitare da terminale:
| |
| | |
| <pre>$ ls /home/nfs/nome_arbitrario</pre>
| |
| | |
| Se il comando restituisce l'elenco di file e cartelle contenute nella cartella <code>/home</code> 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 <code>ls /home/nfs/</code> non mostra nulla poiché il comando non è sufficiente ad innescare l'automount delle risorse remote, quindi viene mostrato il contenuto della sola cartella <code>nfs</code> 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 <code>/etc/auto.nfs</code>, cioè <code>nome_arbitrario</code>.
| |
| Per lo stesso motivo in nautilus facendo click sulla cartella <code>/home/nfs</code> non apparirà nulla, bisogna invece cliccare su "vai --> posizione" e digitare <code>/home/nfs/nome_arbitrario</code> seguito da invio; in realtà anche questo non è detto che funzioni, in tal caso è d'obbligo l'uso del terminale digitando per esempio:
| |
| | |
| <pre>$ cd /home/nfs/nome_arbitrario</pre>
| |
| | |
| 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 <code>/home/nfs</code> è DIVERSO da <code>/home/NFS</code>). 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 <code>/etc/exports</code> anche insecure, ad esempio:
| |
| | |
| <pre>
| |
| /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)
| |
| </pre>
| |
| | |
| 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 le opzioni rsize e wsize indicando valori non troppo grandi, per esempio:
| |
| | |
| * Caso statico: <code>mount -t nfs4 -o rsize=8192,wsize=8192 indirizzo_server:/ /home/nfs</code>
| |
| | |
| * Caso statico, file <code>/etc/fstab</code> aggiungere (o modificare quella già esistente): <code>indirizzo_server:/ /home/NFS nfs4 _netdev,auto,rsize=8192,wsize=8192 0 0</code>
| |
| | |
| * Caso dinamico, file <code>/etc/auto.nfs</code> aggiungere (o modificare quella già esistente) <code>nome_arbitrario -fstype=nfs4,rsize=8192,wsize=8192 indirizzo_server:/</code>
| |
| | |
| A tal proposito potrebbe essere utile leggere [http://nfs.sourceforge.net/nfs-howto/ar01s07.html#cpu_cycles_nfs 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:
| |
| | |
| <pre># ln -s /home/nfs/nome_arbitrario /home/nome_utente/nome_arbitrario</pre>
| |
| | |
| è 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 <code>timeo</code> e <code>retrans</code> specificandoli nel file <code>/etc/auto.nfs</code> (o come è stato chiamato):
| |
| | |
| <pre>nome_arbitrario -fstype=nfs4,timeo=150,retrans=2 indirizzo_server:/</pre>
| |
| | |
| 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 [http://nfs.sourceforge.net/nfs-howto/ questa pagina].
| |
| | |
| == Riferimenti esterni ==
| |
|
| |
|
| Manuali:
| | ''Esempio'': due utenti possiedono entrambi due computer con sistema GNU/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'.<br/> |
| <code>man nfs</code>
| | 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. |
| e | |
| <code>man portmap</code>
| |
|
| |
|
| Pagine web:
| | 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 contengono 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. |
|
| |
|
| * [http://nfs.sourceforge.net/ Sourceforge], pagina ufficiale.
| | Si noti che se su un computer non sono presenti un'utenza ed un gruppo aventi il medesimo nome di quelli presenti sulla macchina che esporta le risorse, allora visualizzando le proprietà di file e cartelle attraverso Nautilus sulla macchina client verranno indicati come proprietario e gruppo ''nouser'' e ''nogroup''. Accedendo invece dal server alle medesime risorse i nomi di proprietario e gruppo risulteranno corretti anche per file e cartelle creati dall'utente remoto. |
| * [https://wiki.linux-nfs.org/wiki/index.php/Main_Page linux-nfs].
| |
| * [http://www.linux-tutorial.info/modules.php?name=MContent&pageid=150 linux-tutorial].
| |
|
| |
|
| | = Ultime note = |
|
| |
|
| ::::::::::::::::::::::::::::::::::::::::::::::
| | Per navigare attraverso le pagine della guida usare il menù laterale. Si tenga presente che non è necessario leggersi tutte le pagine, in particolare la guida per lo "Spazio User" è ormai obsoleta in quanto facente riferimento ad un pacchetto non più disponibile da Squeeze; anche qualora l'utente usasse ancora Lenny è invitato ad usare l'applicativo che lavora a livello di kernel ("Spazio Kernel").<br /> |
| [[Utente:xtow|xtow]]
| | Similmente se si decidesse di usare la versione 3 del protocollo non sarebbe strettamente necessario leggersi le pagine relative alla 4, tuttavia si tenga presente che la sezione relativa al troubleshooting di quest'ultima è probabilmente valida in molti punti anche per la versione 3. |
|
| |
|
| --[[Utente:Wtf|Wtf]] 17:13, 5 giu 2011 (CEST)
| | {{Autori |
| | |Autore = [[Utente:xtow|xtow]] |
| | |Estesa_da = |
| | : [[Utente:Wtf|Wtf]] 17:13, 5 giu 2011 (CEST) |
| | : [[Utente:S3v|S3v]] (Esempi) |
| | |Verificata_da = |
| | : [[Utente:Wtf|Wtf]], eccetto V2-V3 |
| | : [[Utente:Mirko.pagliai|Mirko.pagliai]] 19:31, 19 mar 2012 (CET), eccetto "metodo dinamico" |
| | : [[Utente:S3v|S3v]] 19:11, 3 mag 2015 (CEST) (eccetto "metodo statico") |
| | | Numero_revisori = 3 |
| | }} |
|
| |
|
|
| |
|
| [[Categoria:Condivisione_risorse]] | | [[Categoria:Condivisione_risorse]] |
| [[Categoria:NFS]] | | [[Categoria:NFS]] |
|
Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.
Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione.
|
 Versioni Compatibili
Debian 5 "lenny"
Debian 6 "squeeze"
Debian 7 "wheezy"
Debian 8 "jessie"
|
Introduzione
NFS è l'acronimo di Network Filesystem, ovvero un filesystem utilizzato per montare cartelle remote sul proprio filesystem locale (o meglio per condividere in una LAN filesystem presenti su un server). L'utente in sintesi mette a disposizione una o più risorse (ovvero una directory del proprio filesystem) presenti su una delle sue macchine e le altre vi possono accedere come fosse una directory del proprio filesystem. 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.
|
NOTE
- L'utilizzo di NFS è consigliato solo all'interno di una LAN, in caso contrario è preferibile ricorrere ad altre soluzioni come SSHFS.
- Sebbene NFS sia privilegiato in ambienti UNIX puri è comunque possibile sfruttarlo anche in ambienti misti con client Windows.
|
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 filesystem offre.
A titolo d'esempio si cita la condivisione di calendari in Thunderbird; come noto è impossibile condividere 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.
Versioni
Da Wikipedia:
Network File System (NFS) è un protocollo sviluppato inizialmente da Sun Microsystems nel 1984 e definito dagli RFC 1094, 1813, (3010) e 3530.
In questi trent'anni il protocollo NFS è stato migliorato più volte attraverso la definizione di nuovi versioni, pertanto trascurando quelle più vecchie ormai completamente obsolete, ci si limiterà alla versione 3 (1995) e alla versione 4 (2000).
Per completezza si segnala che da qualche anno è in sviluppo la versione 4.1 del protocollo.
Importante
- Dal punto di vista della configurazione non esistono differenze tra le versioni 2 e 3, mentre la versione 4 introduce alcune piccole differenze di sintassi.
- La scelta del protocollo da utilizzare avviene lato client e non lato server, ovvero attraverso mount e quindi tutti gli strumenti che da esso dipendono (
/etc/fstab, autofs, ecc.). A meno che l'utente non specifichi esplicitamente il protocollo da usare tramite l'opzione nfsvers (o l'equivalente vers) avverrà una negoziazione per tentativi tra client e server partendo dalla versione 4; in caso di fallimento verrà provata la versione 3, dopo di che, se anche questa fallisce, procede automaticamente con un ultimo tentativo usando la versione 2 del protocollo.
- È possibile restringere lato server le versioni utilizzabili del protocollo editando opportunamente il parametro
RPCMOUNTDOPTS del file /etc/default/nfs-kernel-server. Richieste di utilizzo di versioni bloccate del protocollo da parte dei client vengono negate.
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 solo in base all'UID dell'utente (V3 e precedenti), oppure in base all'UID per quanto riguarda i permessi tipo unix e in base al nome utente per quanto riguarda regole ACL e determinazione del proprietario (da V4, citazione); 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 (in Lenny man portmap, man exports per tutti), 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 GNU/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 contengono 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.
Si noti che se su un computer non sono presenti un'utenza ed un gruppo aventi il medesimo nome di quelli presenti sulla macchina che esporta le risorse, allora visualizzando le proprietà di file e cartelle attraverso Nautilus sulla macchina client verranno indicati come proprietario e gruppo nouser e nogroup. Accedendo invece dal server alle medesime risorse i nomi di proprietario e gruppo risulteranno corretti anche per file e cartelle creati dall'utente remoto.
Ultime note
Per navigare attraverso le pagine della guida usare il menù laterale. Si tenga presente che non è necessario leggersi tutte le pagine, in particolare la guida per lo "Spazio User" è ormai obsoleta in quanto facente riferimento ad un pacchetto non più disponibile da Squeeze; anche qualora l'utente usasse ancora Lenny è invitato ad usare l'applicativo che lavora a livello di kernel ("Spazio Kernel").
Similmente se si decidesse di usare la versione 3 del protocollo non sarebbe strettamente necessario leggersi le pagine relative alla 4, tuttavia si tenga presente che la sezione relativa al troubleshooting di quest'ultima è probabilmente valida in molti punti anche per la versione 3.
Debianized 80%