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

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
(verificata)
 
(144 versioni intermedie di 6 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili|Squeeze|Sid}}
{{File_System
|precedente=RAID:_Redundant_Array_of_Indipendent_Disks
|successivo=Samba:_guida_estesa
}}{{Versioni compatibili|Lenny|Squeeze|Wheezy|Jessie}}{{Template:NFS}}
= Introduzione =


=Creare directory da condivedere in una rete GNU/Linux, in modo semplice.=
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.


Uno dei modi più semplici per condividere risorse tra macchine GNU/Linux è l'uso di Network File System. Il funzionamento è semplice, una macchina, '''server''', mette a disposizione la risorsa (ovvero una directory del propio file system), altre macchine, '''client''', vi accedono come fosse una directory del proprio file system. Ora si vedranno entrambe le impostazioni, lato '''server''' e lato '''client'''.
{{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 filesystem offre.<br/>
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.


==Impostazione lato Server==
= Versioni =


{{Box | Convenzione | IP della macchina server 192.168.1.10, direcotory da condividere /media/storage}}
Da [http://it.wikipedia.org/wiki/Network_File_System Wikipedia]:<br /><br />


Installare i pacchetti necessari:
''Network File System (NFS) è un protocollo sviluppato inizialmente da Sun Microsystems nel 1984 e definito dagli RFC 1094, 1813, (3010) e 3530.''<br /><br />
<pre># apt-get install nfs-kernel-server portmap</pre>
Ora editare col vostro editor (gedit, kate, vim.......) preferito il file '''/etc/exports''' ed aggiungere la seguente:
<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'''


Completare dando ai vari client i permessi per l'accesso alla macchina '''server'''
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 />
editare '''/etc/hosts.allow''' ed inserie
Per completezza si segnala che da qualche anno è in sviluppo la versione 4.1 del protocollo.
<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>


==Impostazione lato Client==
=== Importante ===


Installare i pacchetti necessari
* 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.
<pre># apt-get install nfs-common portmap</pre>
* 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.
creare la dirctory dove si vuol montare la directory condivisa, esempio: ''/media/condivisa''
* È 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.
<pre># mkdir /media/condivisa</pre>
 
editare il file '''/etc/fstab''' ed inserire
= Sicurezza =
<pre>192.168.1.10:/media/storage /media/condivisa nfs rw,auto,hard  0  0</pre>
 
'''nota'''
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à.
*'''192.168.1.10:/media/storage''' sono l'indirizzo e la directory del '''server'''
 
**aggiungere tante entry quante sono le directory condivise
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/>
*'''/media/condivisa''' è la directory dove sarà montata la risorsa
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/>
*'''nfs''' è il tipo di file system
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/>
*'''rw''' sono i permessi di lettura e scrittura
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'.
**modificare in '''ro''' se si desideramo solo permessi di lettura
 
*'''auto''' la risorsa viene montata automaticamente
''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/>
**modificare in '''noauto''' se si vuole montare la partizione manualmente
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.
Editareil file '''/etc/hosts.allow''' ed aggiungere
 
<pre>portmap: 192.168.1.10</pre>
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.
Ora avviare il demone e montare la partizione
 
<pre># /etc/init.d/nfs-common start
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.
# mount -a</pre>
 
= 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 />
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.
 
{{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
}}


=Conclusioni=
Come ho scritto all'inizio questo è il modo più semplice per condividere risorse tra macchine Gnu/Linux, queste impostazioni sono adatte ad una rete privata, dove non ci sono problemi di sicurezza, visto che ho lasciato abilitato la condivisione a tutta la LAN. Se si vuole fare una condivisione più mirata o selettiva
<pre> man nfs, man portmap</pre>
::::::::::::::::::::::::::::::::::::::::::::::
[[Utente:xtow|xtow]]


[[Categoria:Condivisione_risorse]]
[[Categoria:Condivisione_risorse]]
[[Categoria:NFS]]

Versione attuale delle 17:11, 3 mag 2015

File System e dispositivi fisici
Arrow left.png

Generalità

Locali

Remoti

Strumenti

Arrow right.png


Edit-clear-history.png 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.


Debian-swirl.png Versioni Compatibili

Debian 5 "lenny"
Debian 6 "squeeze"
Debian 7 "wheezy"
Debian 8 "jessie"
NFS

Sommario

Spazio Kernel
  1. Lato server
  2. Lato client

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.

Info.png 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.




Guida scritta da: xtow Swirl-auth80.png Debianized 80%
Estesa da:
Wtf 17:13, 5 giu 2011 (CEST)
S3v (Esempi)
Verificata da:
Wtf, eccetto V2-V3
Mirko.pagliai 19:31, 19 mar 2012 (CET), eccetto "metodo dinamico"
S3v 19:11, 3 mag 2015 (CEST) (eccetto "metodo statico")

Verificare ed estendere la guida | Cos'è una guida Debianized