Nfs-kernel-server: configurazione lato server: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
mNessun oggetto della modifica
 
(15 versioni intermedie di 2 utenti non mostrate)
Riga 1: Riga 1:
{{NFS}}
{{NFS}}
= Installazione =
= Installazione =


Installare i pacchetti necessari:
Installare i pacchetti necessari:


== nfsV2 e nfsV3 ==
<pre># apt-get install nfs-kernel-server portmap</pre>
== nfsV4 ==
<pre># apt-get install nfs-kernel-server</pre>
<pre># apt-get install nfs-kernel-server</pre>


= Configurazione =
= Configurazione =


== nfsV2 e nfsV3 ==
=== nfs-common ===
 
Editare il file <code>/etc/default/nfs-common</code> ed assicurarsi che le righe contenenti le variabili  <code>NEED_IDMAPD=</code> e <code>NEED_GSSD=</code> appaiano così:
 
<pre>
NEED_IDMAPD=yes
NEED_GSSD=no
</pre>
 
=== nfs-kernel-server ===


{{Box|Convenzione|IP della macchina server: <code>192.168.1.10</code>; directory da condividere: <code>/media/storage</code>}}
Editare il file <code>/etc/default/nfs-kernel-server</code> ed assicurarsi che la riga contenente la variabile <code>NEED_SVCGSSD=</code> appaia così:


Ora  editare col vostro editor preferito (gedit, kate, vim, ...) il file  <code>/etc/exports</code> ed aggiungere la seguente riga:
<pre>NEED_SVCGSSD="no"</pre>
<pre>/media/storage      192.168.1.0/24(rw,sync,no_subtree_check)</pre>
Questa è comunque l'opzione di default se non viene specificato nulla.


Nota:
Da notare che attraverso questo file di configurazione è possibile definire tutte le opzioni di <code>rpc.mountd</code> attraverso il parametro <code>RPCMOUNTDOPTS</code>, come ad esempio restringere il numero delle versioni di protocollo utilizzabili.
*'''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:
=== idmapd.conf ===
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.
Editare il file <code>/etc/idmapd.conf</code>, che di default dovrebbe apparire così:
<pre>
[General]


Ora lanciamo il demone e rendiamo disponibile la directory condivisa:
Verbosity = 0
<pre># /etc/init.d/nfs-kernel-server start
Pipefs-Directory = /run/nfs/rpc_pipefs
# exportfs -a</pre>
# set your own domain here, if id differs from FQDN minus hostname
#Domain = localdomain


== nfsV4 ==
[Mapping]


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ì:
Nobody-User = nobody
Nobody-Group = nogroup
</pre>


Il parametro da controllare è ''Domain'', che in maniera automatica debian si ricava come FQDN meno nome host. Se quindi non avete configurato un dominio di rete è assai probabile che ''rpc.idmapd'' sbagli ad associare proprietà e regole ACL dei file, ma non i permessi unix che vengono gestiti tramite gli [[UID]] ([http://blather.michaelwlucas.com/archives/796 citazione]). Per la maggior parte degli utenti ''home'' e ''soho'' questo non sarà un grosso problema, visto che l'unico effetto visibile sarà un'errata visualizzazione dei proprietari dei file lato client (tutti associati a ''nobody:nogroup'').<br/>
Premesso questo è necessario valutare come avviene la risoluzione dei nomi all'interno della propria LAN. Se non si è configurato ne un servizio DNS per la propria LAN ne si sono editati i file <code>/etc/hosts</code> dei vari PC specificando un dominio fittizio, allora è possibile che valga la pena di lasciare semplicemente commentato il parametro <code>Domain</code>; in caso contrario vale assolutamente la pena di indicare correttamente il dominio (anche solo fittizio) della LAN, per esempio <code>small.lan</code> (evidentemente fittizio):
<pre>
<pre>
NEED_IDMAPD=yes
[General]
NEED_GSSD=no
 
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
Domain = small.lan
 
[Mapping]
 
Nobody-User = nobody
Nobody-Group = nogroup
</pre>
</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ì:
Una volta salvate le modifiche riavviare <code>nfs-common</code>:
<pre># service nfs-common restart</pre>
{{Box|Nota|In generale ricordare che nel caso del server è necessario riavviare anche ''nfs-kernel-server'' dopo aver riavviato ''nfs-common''}}


<pre>NEED_SVCGSSD=no</pre>
=== exports ===


A questo punto è possibile definire le condivisioni editando il file <code>/etc/exports</code>, ogni riga del quale descrive una directory. Ad esempio inserendo le seguenti righe:
A questo punto è possibile definire le condivisioni editando il file <code>/etc/exports</code>, ogni riga del quale descrive una directory. Ad esempio inserendo le seguenti righe:
Riga 57: Riga 72:
</pre>
</pre>


Si condivide la cartella <code>/home</code> e la sua  sottocartella <code>/home</code>. 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:
Si condivide la cartella <code>/home</code> e la sua  sottocartella <code>/home/altro</code>. 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>rw</code>:  abilita 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>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>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.
* <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.
* <code>crossmnt</code>: questa opzione serve in teoria solo se si sono rimontate delle directory (si veda la successiva sottosezione dedicata al rimontaggio delle cartelle), tuttavia è possibile che omettendola si noti un crollo della velocità  di trasferimento (per esempio fino a 150-200 kB/s) nel trasferire grossi file da un client al server.
* <code>crossmnt</code>: questa opzione serve in teoria solo se si sono rimontate delle directory (si veda la successiva sottosezione dedicata al rimontaggio delle cartelle), tuttavia è possibile che omettendola si noti un crollo della velocità  di trasferimento (per esempio fino a 150-200 kB/s) nel trasferire grossi file da un client al server.
 


{{ Warningbox | Dalla versione 4 di NFS tutte le risorse da esportare devono essere contenute dentro una medesima directory cui dovrà essere attribuito fsid&#61;0, in caso contrario è necessario rimontarle tutte prima in un'altra cartella e poi esportare questa, si veda più avanti. }}
{{ Warningbox | Se si usa la versione 4 di NFS (quella di default) tutte le risorse da esportare devono essere contenute dentro una medesima directory cui dovrà essere attribuito fsid&#61;0, in caso contrario è necessario rimontarle tutte prima in un'altra cartella e poi esportare questa, si veda più avanti. }}


Per rendere operative le modifiche al file <code>/etc/exports</code> eseguire:
Per rendere operative le modifiche ai file di configurazione eseguire:


<pre># /etc/init.d/nfs-kernel-server restart</pre>
<pre># service nfs-kernel-server restart</pre>


In caso di ulteriori problemi a visualizzare il contenuto delle cartelle provare a riavviare server e client.
In caso di ulteriori problemi a visualizzare il contenuto delle cartelle provare a riavviare server e client.


=== RIMONTARE LE DIRECTORY ===
== 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:
È 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:
Riga 83: Riga 97:
</pre>
</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>:
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>
<pre>
Riga 90: Riga 104:
</pre>
</pre>


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


<pre>
<pre>
Riga 105: Riga 119:
</pre>
</pre>


Da notare l'aggiunta dell'opzione <code>crossmnt</code>, che non deve essere omessa pena l'impossibilità di vedere il contenuto delle  sottocartelle di ''export'' sulle macchine client. Quest'opzione DEVE ESSERE assegnata solo alla cartella cui viene attribuito  fsid=0.<BR>
Da notare l'aggiunta dell'opzione <code>crossmnt</code>, che non deve essere omessa pena l'impossibilità di vedere il contenuto delle  sottocartelle di ''export'' sulle macchine client. Quest'opzione DEVE ESSERE assegnata solo alla cartella cui viene attribuito  fsid=0.<BR>
Stando al manuale l'opzione  <code>nohide</code> ha un effetto molto simile a quello di <code>crossmnt</code>, con la differenza che quest'opzione  NON DEVE ESSERE assegnata alla cartella cui viene attribuito fsid=0, ma solo alle sotto directory (in caso contrario l'export delle risorse fallisce), ovvero restando al soprastante esempio:
Stando al manuale l'opzione  <code>nohide</code> ha un effetto molto simile a quello di <code>crossmnt</code>, con la differenza che quest'opzione  NON DEVE ESSERE assegnata alla cartella cui viene attribuito fsid=0, ma solo alle sotto directory (in caso contrario l'export delle risorse fallisce), ovvero restando al soprastante esempio:


<pre>
<pre>
Riga 114: Riga 128:
</pre>
</pre>


'''Sottolineo'''  che per quanto riguarda la mia personale esperienza questo secondo metodo è risultato inadeguato, poiché nel caso di trasferimento di grossi file (>1GB) da client a server ho notato un sistematico crollo della velocità di trasferimento (170 kB/s circa, tipicamente dopo aver superato la soglia di 1,1-2,5 GB trasferiti). Nel trasferimento da server a client le due soluzioni mi risultano invece equivalenti.
'''Sottolineo'''  che per quanto riguarda la mia personale esperienza questo secondo metodo è risultato inadeguato, poiché nel caso di trasferimento di grossi file (>1GB) da client a server ho notato un sistematico crollo della velocità di trasferimento (170 kB/s circa, tipicamente dopo aver superato la soglia di 1,1-2,5 GB trasferiti). Nel trasferimento da server a client le due soluzioni mi risultano invece equivalenti.
 
[[Categoria:Condivisione_risorse]]
[[Categoria:NFS]]

Versione attuale delle 17:12, 3 mag 2015

NFS

Sommario

Spazio Kernel
  1. Lato server
  2. Lato client

Installazione

Installare i pacchetti necessari: 

# apt-get install nfs-kernel-server

Configurazione

nfs-common

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

NEED_IDMAPD=yes
NEED_GSSD=no

nfs-kernel-server

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

NEED_SVCGSSD="no"

Questa è comunque l'opzione di default se non viene specificato nulla.

Da notare che attraverso questo file di configurazione è possibile definire tutte le opzioni di rpc.mountd attraverso il parametro RPCMOUNTDOPTS, come ad esempio restringere il numero delle versioni di protocollo utilizzabili.

idmapd.conf

Editare il file /etc/idmapd.conf, che di default dovrebbe apparire così: 

[General]

Verbosity = 0
Pipefs-Directory = /run/nfs/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
#Domain = localdomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

Il parametro da controllare è Domain, che in maniera automatica debian si ricava come FQDN meno nome host. Se quindi non avete configurato un dominio di rete è assai probabile che rpc.idmapd sbagli ad associare proprietà e regole ACL dei file, ma non i permessi unix che vengono gestiti tramite gli UID (citazione). Per la maggior parte degli utenti home e soho questo non sarà un grosso problema, visto che l'unico effetto visibile sarà un'errata visualizzazione dei proprietari dei file lato client (tutti associati a nobody:nogroup).
Premesso questo è necessario valutare come avviene la risoluzione dei nomi all'interno della propria LAN. Se non si è configurato ne un servizio DNS per la propria LAN ne si sono editati i file /etc/hosts dei vari PC specificando un dominio fittizio, allora è possibile che valga la pena di lasciare semplicemente commentato il parametro Domain; in caso contrario vale assolutamente la pena di indicare correttamente il dominio (anche solo fittizio) della LAN, per esempio small.lan (evidentemente fittizio): 

[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
Domain = small.lan

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

Una volta salvate le modifiche riavviare nfs-common: 

# service nfs-common restart
Info.png Nota
In generale ricordare che nel caso del server è necessario riavviare anche nfs-kernel-server dopo aver riavviato nfs-common


exports

A questo punto è possibile definire le condivisioni editando il file /etc/exports, ogni riga del quale descrive una directory. Ad esempio inserendo le seguenti righe: 

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

Si condivide la cartella /home e la sua sottocartella /home/altro. 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: abilita 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.
  • crossmnt: questa opzione serve in teoria solo se si sono rimontate delle directory (si veda la successiva sottosezione dedicata al rimontaggio delle cartelle), tuttavia è possibile che omettendola si noti un crollo della velocità di trasferimento (per esempio fino a 150-200 kB/s) nel trasferire grossi file da un client al server.
Warning.png ATTENZIONE
Se si usa la versione 4 di NFS (quella di default) tutte le risorse da esportare devono essere contenute dentro una medesima directory cui dovrà essere attribuito fsid=0, in caso contrario è necessario rimontarle tutte prima in un'altra cartella e poi esportare questa, si veda più avanti.


Per rendere operative le modifiche ai file di configurazione eseguire: 

# service nfs-kernel-server restart

In caso di ulteriori problemi a visualizzare il contenuto delle cartelle provare a riavviare server e client.

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,crossmnt)
/export/utente 192.168.1.0/24(rw,no_subtree_check,sync)
/export/altro  192.168.1.0/24(rw,no_subtree_check,sync)

Da notare l'aggiunta dell'opzione crossmnt, che non deve essere omessa pena l'impossibilità di vedere il contenuto delle sottocartelle di export sulle macchine client. Quest'opzione DEVE ESSERE assegnata solo alla cartella cui viene attribuito fsid=0.
Stando al manuale l'opzione nohide ha un effetto molto simile a quello di crossmnt, con la differenza che quest'opzione NON DEVE ESSERE assegnata alla cartella cui viene attribuito fsid=0, ma solo alle sotto directory (in caso contrario l'export delle risorse fallisce), ovvero restando al soprastante esempio: 

/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)

Sottolineo che per quanto riguarda la mia personale esperienza questo secondo metodo è risultato inadeguato, poiché nel caso di trasferimento di grossi file (>1GB) da client a server ho notato un sistematico crollo della velocità di trasferimento (170 kB/s circa, tipicamente dopo aver superato la soglia di 1,1-2,5 GB trasferiti). Nel trasferimento da server a client le due soluzioni mi risultano invece equivalenti.

Estratto da "https://guide.debianizzati.org/index.php?title=Nfs-kernel-server:_configurazione_lato_server&oldid=38209"