Fra i molti differenti file system che FreeBSD supporta c'è il Network File System, conosciuto anche come NFS. NFS permette ad un sistema di condividere directory e file con altri sistemi in rete. Usando NFS, utenti e programmi possono accedere a file su sistemi remoti quasi come se fossero files locali.
Alcuni dei più notevoli benefici che NFS ci fornisce sono:
Workstation locali usano meno spazio su disco perchè i dati usati in locale possono essere conservati su una singola macchina e restano accessibili agli altri sulla rete.
Non c'è bisogno per gli utenti di avere home directory separate su ogni macchina in rete. Le home directory possono essere poste sul server NFS e rese disponibili attraverso la rete.
Device di storage come floppy disk, drive CDROM, e drive Zip® possono essere usati da altre macchine sulla rete. Questo può ridurre il numero di device di storage rimuovibili sulla rete.
NFS consiste di almeno due parti: un server ed uno o più client. Il client accede da remoto ai dati conservati sulla macchina server. Affinchè questo funzioni, alcuni processi devono essere configurati e devono essere attivi.
Il server deve avere attivi i seguenti demoni:
Demone | Descrizione |
---|---|
nfsd | Il demone NFS che serve richieste da client NFS. |
mountd | Il demone di mount NFS che serve le richieste che nfsd(8) gli passa. |
rpcbind | Questo demone permette ai client NFS di scoprire quali porte il server NFS sta usando. |
Il client può anche eseguire un demone, noto come nfsiod. Il demone nfsiod serve le richieste dal server NFS. E' opzionale, aiuta a migliorare le prestazioni ma non è indispensabile per operazioni corrette. Consultare la pagina di manuale di nfsiod(8) per più informazioni.
La configurazione di NFS
è un processo relativamente semplice.
I processi che devono essere attivi
possono essere tutti avviati al boot della macchina
con poche modifiche al tuo file
/etc/rc.conf
.
Sul server NFS assicurati
che le seguenti opzioni sono configurati nel file
/etc/rc.conf
:
rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r"
mountd viene eseguito automaticamente in caso il server NFS sia abilitato.
Sul client, accertati che questa riga sia
attiva nel file
/etc/rc.conf
:
nfs_client_enable="YES"
Il file /etc/exports
specifica quali file system NFS
dovrebbe esportare (talora
chiamate anche «share»). Ogni linea di
/etc/exports
specifica un
file system che deve essere esportato e quali
macchine hanno accesso a quel file system.
Assieme alle macchine che hanno accesso a quel file system,
possono esserci specificate anche opzioni. Ci
sono molte opzioni di questo tipo che possono essere
usate in questo file ma solo poche saranno menzionate
qui. Puoi facilmente
scoprire le altre opzioni leggendo la pagina di manuale
di exports(5).
Queste sono alcune linee di esempio del file
/etc/exports
:
I seguenti esempi danno un'idea di
come esportare file system, anche se le
impostazioni possono essere diverse
a seconda del tuo ambiente e della tua
configurazione di rete.
Ad esempio, per esportare la directory
/cdrom
a tre macchine di esempio che hanno lo
stesso nome di dominio del server (da qui
la mancanza di nome dominio per ognuno)
o hanno delle linee nel vostro file
/etc/hosts
.
L'opzione -ro
rende il
file system esportato read-only. Con
questo flag, il sistema remoto non sarà in grado
di scrivere alcun cambiamento sul file system
esportato.
/cdrom -ro host1 host2 host3
La seguente linea esporta la directory
/home
a tre host
identificati da indirizzo IP. E' una
impostazione utile in caso tu abbia
una rete privata senza un DNS server
configurato. Opzionalmente il file
/etc/hosts
può essere configurato per hostname interni.
Per favore rileggi
hosts(5) per più informazioni. Il flag
-alldirs
permette alle sottodirectory
di fungere da mount point. In altre parole, non monterà
le sottodirectory ma permetterà ai client di montare
solo le directory che necessita o di cui ha bisogno.
/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4
La linea seguente esporta /a
cosicchè due client da diversi domini possono accedere
al file system. L'opzione -maproot=root
permette all'utente root
sul
sistema remoto di scrivere dati
sul file system esportato come utente root
.
Se il flag -maproot=root
non
è specificato, anche se l'utente ha accesso come
root
sul file system remoto,
non sarà in grado di modificare files sul file system
esportato.
/a -maproot=root host.example.com box.example.org
Affinchè un client abbia accesso ad
un file system, questo deve avere permessi adeguati.
Assicurati che il client sia elencato nel
file /etc/exports
.
In /etc/exports
, ogni
linea rappresenta le informazioni per un
file system esportato ad un host. Un
host remoto può essere specificato solo
una volta per file system, e può
avere solo una entry di default. Ad esempio,
supponi che /usr
sia
un singolo file system. Il seguente
/etc/exports
sarebbe
invalido:
# Invalid when /usr is one file system /usr/src client /usr/ports client
Un file system, /usr
,
ha due linee che specificano exports verso lo stesso
host, client
.
Il formato corretto per questa situazione è:
/usr/src /usr/ports client
Le proprietà di un file system esportato ad un dato host devono essere tutte su una riga. Linee senza un cliente specificato sono trattate come un singolo host. Questo limita il modo di esportare file system, ma per la maggior parte delle persone non è un problema.
Il seguente è un esempio di valida
lista di esportazione, dove
/usr
e /exports
/usr
and /exports
sono file system locali:
# Export src and ports to client01 and client02, but only # client01 has root privileges on it /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # The client machines have root and can mount anywhere # on /exports. Anyone in the world can mount /exports/obj read-only /exports -alldirs -maproot=root client01 client02 /exports/obj -ro
Il demone mountd deve
essere forzato a rileggere il file /etc/exports
ogni volta che lo modifichi,
cosicchè i cambiamenti abbiano effetto.
Questo può essere ottenuto inviando un segnale HUP
al processo mountd
:
#
kill -HUP `cat /var/run/mountd.pid`
o invocando lo script mountd
rc(8)
con i parametri appropriati:
#
/etc/rc.d/mountd onereload
Sei invitato a far riferimento a Sezione 11.2, «Configurazione Iniziale» per maggiori informazioni sugli script rc.
Alternativamente, un reboot farà sì
che FreeBSD imposti tutto
correttamente. Non è necessario tuttavia effettuare
un reboot. L'esecuzione del seguente comando da
utente root
dovrebbe avviare tutto.
Sul server NFS:
#
rpcbind
#
nfsd -u -t -n 4
#
mountd -r
Sul client NFS:
#
nfsiod -n 4
Ora dovrebbe essere tutto pronto per montare
un file system remoto.
In questi esempi il nome del server
sarà server
e quello del client
sarà client
. Se vuoi solo
temporaneamente montare un file system remoto o
anche testare la configurazione, basta che
esegui un comando come questo
come utente root
sul client:
#
mount server:/home /mnt
Questo monterà la directory
/home
del server
sopra /mnt
sul client. Se
tutto è impostato correttamente dovresti
essere in grado di entrare nella directory
/mnt
sul client e vedere
tutti i file che sono sul server.
Se vuoi montare automaticamente un
file system remoto ogni volta che il
computer fa boot, aggiungi il file system
al file /etc/fstab
.
Questo è un esempio:
server:/home /mnt nfs rw 0 0
La pagina di manuale di fstab(5) elenca tutte le possibili opzioni.
Alcune applicazioni (es. mutt)
richiedono il lock dei file per operare in modo corretto.
In caso di NFS, può essere utilizzato
rpc.lockd per il lock dei file.
Per abilitarlo, aggiungi la seguente riga al file
/etc/rc.conf
sia sul client che sul
server (assumendo che il client e server NFS
siano già configurati):
rpc_lockd_enable="YES" rpc_statd_enable="YES"
Avvia l'applicazione con:
#
/etc/rc.d/nfslocking start
Se non è richiesto un lock reale tra il server
e il client NFS, è possibile
dire al client NFS di fare un lock locale
passando l'opzione -L
a mount_nfs(8).
Ulteriori dettagli possono essere trovati nella pagina man di
mount_nfs(8).
NFS ha molti usi pratici. Alcuni dei più usati sono elencati di seguito:
Fa sì che alcune macchine condividano un CDROM o un altro media fra di loro. Questo è un metodo più economico e spesso più convieniente di installare software su molte macchine.
Su grandi reti, potrebbe essere più conveniente configurare un server NFS centrale in cui conservare tutte le home directory degi utenti. Queste home directory possono essere esportate sulla rete cosicchè gli utenti abbiano sempre la stessa directory, indipendentemente dalla workstation dalla quale effettuino il login.
Molte macchine potrebbero avere una
directory comune
/usr/ports/distfiles
.
In questo modo, quando hai bisogno di
installare un port su molte macchine,
puoi velocemente accedere al sorgente senza
scaricarlo su ogni macchina.
amd(8) (il demone di mount automatico)
monta automaticamente un file system remoto
ogni volta che un file o una directory in quel
file system viene acceduto. I file system che sono
inattivi per un certo periodo di tempo possono
anche essere smontati automaticamente da
amd. L'uso di
amd fornisce una semplice
alternativa a mount permanenti, dato che i mount
permanenti sono di solito
elencati in /etc/fstab
.
amd opera connettendosi
ad un server NFS sulle directory
/host
e
/net
. Quando si accede ad un file
all'interno di una di queste directory,
amd
fa una ricerca del mount remoto corrispondente e lo
monta automaticamente. /net
è usato per montare
un file system esportato da un indirizzo IP,
mentre /host
è usato per montare un export da un hostname remoto.
Un accesso ad un file in
/host/foobar/usr
dovrebbe
comunicare a amd di
cercare di montare
l'export /usr
sull'host
foobar
.
Puoi osservare i mount disponibili di un
host remoto con il comando
showmount
. Ad esempio, per
vedere i mounts di un host chiamato
foobar
, puoi usare:
%
showmount -e foobar
Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0%
cd /host/foobar/usr
Come si vede nell'esempio,
il comando showmount
mostra
/usr
come un export.
Quando si cambia directory in
/host/foobar/usr
,
amd
cerca di risolvere foobar
e
automaticamente monta l'export desiderato.
amd può essere
avviato dagli scripts di startup inserendo le
seguenti linee in
/etc/rc.conf
:
amd_enable="YES"
Inoltre, altri flags personalizzati possono essere
ad amd con le opzioni
amd_flags
. Di default,
amd_flags
è impostato a:
amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"
Il file /etc/amd.map
definisce le opzioni di default con le quali
gli export sono montati. Il file
/etc/amd.conf
definisce
alcune delle più avanzate caratteristiche di
amd.
Consulta le pagine di manuale di amd(8) e amd.conf(5) per maggiori informazioni.
Alcuni adapter Ethernet per sistemi PC hanno limitazioni che possono portare a seri problemi seri di rete, in particolare con NFS. Questa difficoltà non è specifica a FreeBSD, ma i sistemi FreeBSD ne sono affetti.
I problemi avvengono quasi sempre quando sistemi PC (FreeBSD) sono connessi in rete con workstation ad alta performance, tipo quelli di Silicon Graphics, Inc., e Sun Microsystems, Inc. Il mount NFS funziona, ed alcune operazioni possono avere successo, ma d'improvviso sembra che il server non dia più risposte al client, anche se le richieste da e verso altri sistemi continuano ad essere processate. Questo avviene sul sistema client, sia che il client sia il sistema FreeBSD sia che sia la workstation. Su molti sistemi, non c'è modo di effettuare lo shutdown del client in modo pulito una volta che questo problema si sia manifestato. L'unica soluzione è spesso quella di resettare il client, poichè la situazione NFS non può essere risolta.
Anche se la soluzione «corretta»
è usare un adapter Ethernet dalle migliori
prestazioni e capacità , c'è un semplice
workaround che permetterà operazioni soddisfacenti.
Se il sistem FreeBSD è il server,
includi le opzioni -w=1024
al
mount dal client. Se il sistema FreeBSD
è il client, allora monta
il file system NFS con l'opzione -r=1024
.
Queste opzioni possono essere specificate usando
il quarto campo della linea di
fstab
sul client per
mount automatici, o usa il parametro -o
del comando mount(8) per mount manuali.
Bisognerebbe notare che c'è un problema diverso, a volte confuso con questo, quando il server NFS ed il client sono su reti diverse. Se è questo il caso, accertatevi che i vostri router indirizzino correttamente l'informazione necessaria su UDP, o non andrai da nessuna parte, indipendentemente da cosa tu stia cercando di fare.
Nei seguenti esempi, fastws
è
il nome host (interfaccia) di una workstation
ad alte prestazioni, e freebox
è il nome host (interfaccia) di un sistema FreeBSD con
un adapter Ethernet a basse prestazioni. Inoltre,
/sharedfs
sarà il file system esportato
(vedi exports(5)), e /project
sarà il mount point sul client per il file system
montato. In tutti i casi, nota che le opzioni
hard
o soft
e
bg
possono essere utili
nella tua applicazione.
Esempi dal sistema FreeBSD (freebox
)
come client da /etc/fstab
su
freebox
:
fastws:/sharedfs /project nfs rw,-r=1024 0 0
Come comando manuale di mount da
freebox
:
#
mount -t nfs -o -r=1024 fastws:/sharedfs /project
Esempi dal sistema FreeBSD come server in
/etc/fstab
su
fastws
:
freebox:/sharedfs /project nfs rw,-w=1024 0 0
Come comando di mount manuale su
fastws
:
#
mount -t nfs -o -w=1024 freebox:/sharedfs /project
Praticamente ogni Ethernet adapter a 16-bit permetterà operazioni senza le succitate restrizioni sulla dimensione di lettura e scrittura.
Per chiunque è interessato, ecco cosa succede quando occorre il problema, il che spiega anche perchè sia non riparabile. NFS tipicamente lavora con una dimensione di «block» di 8 K (anche se può creare frammenti di dimensione minore). Dal momento che la massima dimensione dei pacchetti Ethernet è attorno a 1500 bytes, il «block» NFS sarà diviso in molti pacchetti Ethernet anche se è pur sempre una singola unità per il codice di più alto livello e deve essere ricevuto, assemblato e riconosciuto come una unità . La workstation ad alta performance può inviare pacchetti che comprendono le unità NFS una dietro l'altra, l'una vicino all'altra come permette lo standard.i Sulla scheda a minore capacità , gli ultimi pacchetti sovrascrivono i precedenti pacchetti della stessa unità prima che possano essere trasferiti all'host e l'unità nella sua interezza non può essere ricostruita o riconosciuta. Come risultato, la workstation andrà in timeout e cercherà ancora di ripetere l'operazione, ma cercherà con la stessa unità da 8 K, ed il processo sarà ripetuto ancora, all'infinito.
Mantenendo la dimensione dell'unità al di sotto della limitazione dei pacchetti Ethernet, ci assicuriamo che ogni completo pacchetto Ethernet ricevuto possa essere ricono sciuto individualmente, evitando così la situazione deadlock.
Sovrascritture possono anche capitare quando una workstation ad alte prestazioni riversi dati verso un sistema PC, ma con la scheda di rete migliore, sovrascritture di questo tipo non sono garantite su «unità » NFS. Quando una sovrascrittura avviene, le unità affette saranno ritrasmesse, e c'è una buona probabilità che saranno ricevute, assemblate, e riconosciute.
Questo, ed altri documenti, possono essere scaricati da ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Per domande su FreeBSD, leggi la
documentazione prima di contattare
<questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a
<doc@FreeBSD.org>.