Nfs-kernel-server: configurazione lato server
NFS |
Sommario |
|
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 contenti 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 contente la variabile NEED_SVCGSSD=
appaia così:
NEED_SVCGSSD=no
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 = /var/lib/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 permessi ACL dei file, ma non i permessi unix che vengono gestiti tramite gli UID (citazione). Premesso che per la maggiorparte 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 fittizio della lan, per esempio small.lan
(assolutamente arbitrario):
[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
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
. 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.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.
Per rendere operative le modifiche ai file di configurazione eseguire:
# /etc/init.d/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.