.\"
.\" Traduzione in italiano di Giovanni Bortolozzo <borto@dei.unipd.it>
.\" Ottobre 1996
.\" Correzioni, Ottavio G. Rizzo, ottobre 1998
.\"
.\" Aggiornamento a 2.2beta37, Ottavio Rizzo, marzo 1999
.TH EXPORTS 5 "11 agosto 1997" "" "Linux System Administration"
.UC 5
.SH NOME
exports \- file system NFS che sono esportati
.SH SINTASSI
.B /etc/exports
.SH DESCRIZIONE
Il file
.I /etc/exports
fa da elenco per il controllo dell'accesso per file system che
possono essere esportati a clienti NFS.  usato sia dal demone per il
mount NFS,
.BR mountd (8)
che dal demone di file server NFS
.BR nfsd (8).
.PP
Il formato del file  simile a quello del file 
.I exports
di SunOS, tranne per il fatto che sono permesse diverse opzioni
addizionali. Ogni riga contiene un mount point e una lista di macchine
o gruppi di rete (netgroup) autorizzati a montare il
file system in quel posto. Ogni nome di macchina pu essere seguito da
una lista opzionale, tra parentesi, di parametri per mount. Le righe
vuote sono ignorate, e un # introduce un commento fino alla fine della
riga. Le voci possono essere continuate su pi righe usando un backslash.
.PP
.SS Formato dei nomi delle macchine
I clienti NFS possono essere specificati in pi modi:
.IP "single host"
Questo  il formato pi comune: un nodo pu essere indicato sia da un
nome abbreviato riconosciuto dal resolver, da un nome di dominio
completamente qualificato (fqdn) oppure da un indirizzo IP.
.IP "gruppi di reti"
I gruppi NIS possono essere dati come
.IR @group :
Solo la parte di nodo di ogni mebro del gruppo viene estratta ed
aggiunta alla lista d'acceso. Parti di nodo vuote o contenenti solo un
trattino - sono ignorate.
.IP "metacaratteri"
I nomi delle macchine possono conteneri i metacaratteri \fI*\fR e
\fI?\fR: ci pu essere usare per rendere pi compatto il file
\fIexports\fR; per esempio, \fI*.cs.foo.edu\fR corrisponde a tutti i
nodi nel dominio \fIcs.foo.edu\fR. Questi metacaratteri, per, non
corrispondono ai punti del nome del dominio, per cui il modello di
prima non corrisponderebbe a \fIa.b.cs.foo.edu\fR.
.IP "reti IP"
 anche possibile esportare directory contemporaneamente verso tutti i
nodi di una (sotto-)rete IP: lo si fa specificando una coppia
indirizzo IP e netmask come
.IR indirizzo/netmask .
.TP
.B =public
Questo  un nome speciale che indica la directory data come la
directory radice publica (vedi la sezione WebNFS di
.BR nfsd (8)
per una discussione su WebNFS e la gestione della radice
pubblica). Usando questa convenzione,
.B =public
deve essere l'unica opzione della riga e nessuna opzione
d'esportazione gli pu essere associata. Si noti che in realt questo
.I non
esporta la directory citata: bisogna ancora dare le opzioni
d'esportazione in una voce separata.
.PP
Il percorso della radice pubblica pu essere specificato anche
invocando
.I nfsd
con l'opzione
.BR \-\-public\-root .
Specifiche ripetute della radice pubblica vengono ignorate.
.PP
.SS Opzioni Generali
.IR mountd " e " nfsd
comprendono le seguenti opzioni d'esportazione:
.TP
.IR secure "\*d"
Questa opzione richiede che la richiesta sia originata da una porta
internet con numero minore di IPPORT_RESERVED (1024). Questa opzione
 abilitata di natura. Per disabilitarla, specificare
.IR insecure .
.TP
.IR ro
Permette solo richieste di sola lettura su questo volume NFS. Il
comportamento predefinito  di permettere anche richieste di
scrittura, cosa che pu 
essere anche specificata esplicitamente usando l'opzione
.IR rw .
.TP
.I noaccess
Rende tutto ci che sta sotto alla directory inacessibile al cliente
in questione: molto utile quando si vuole esportare una gerarchia di
directory verso un cliente, ma escludendo certe sottodirectory. Il
cliente ha una visione molto ristretta di una directory marcata con
noaccess: pu leggerne gli attributi e vedere . e ..; queste sono
anche le uniche voce riportate da una readdir.
.TP
.IR link_relative
Converte collegamenti simbolici assoluti (quelli in cui il contenuto
del collegamento 
inizia con uno slash /) in collegamenti relativi precedendoli con il
numero di ../ necessario per portarli dalla directory che contiene il
link alla radice del server. Ci ha una sottile, forse
discutibile, semantica quando la gerarchia dei file non  montata
nella propria radice. 
.TP
.IR link_absolute
Lascia stare tutti i collegamenti. Questa  l'operazione predefinita.
.SS Correlazione degli identificativi utente
.PP
.I nfsd
basa il suo controllo d'accesso ai file del server sull'uid
e il gid forniti in ognuna delle richieste RPC di NFS. Il comportamento
normale che un utente si aspetterebbe  di poter accedere a sui file
nel server proprio come farebbe in un normale file system. Ci
richiede che siano usati gli stessi uid e i gid sul cliente e sul
server. Ci non sempre  vero, per quanto sia sempre preferibile.
.PP
Molto spesso, non  desiderabile che l'utente root del
cliente sia trattato come root anche quando accede ai file nel server
NFS. A questo scopo, l'uid 0  normalmente trasformato in un
identificativo differente: il cosiddetto uid anonimo (anonymous) o
.IR nobody " (nessuno)."
Questo  il modo di operare (detto root squashing=schiacciamento di
root) predefinito, e pu essere disabilitato con 
.IR no_root_squash .
.PP
Di default,
.I nfsd
prova a ottenere l'uid e il gid anonimi ricercando all'avvio l'utente   
.I nobody
nel file delle password. Se non lo trova, sono allora usati un uid e
un gid pari a -2 (cio 65534). Questi valori possono essere ridefiniti
dalle opzioni 
.IR anonuid " e " anongid .
.PP
Oltre a questo,
.I nfsd
permette comunque di specificare gli uid e i gid ai quali dovrebbe
corrispondere l'utente nobody. Inoltre si possono mappare tutte le
richieste degli utenti all'uid anonimo specificando l'opzione 
.IR all_squash .
.PP 
A beneficio delle installazioni in cui gli uid differiscono tra
macchine diverse, 
.I nfsd
fornisce pi metodi per correlare dinamicamente gli uid del server
con gli uid del cliente e viceversa: file di correlazione statica,
correlazione basata su NIS e correlazione basata su
.IR ugidd .
.PP
La correlazione basata su
.I ugidd
 avviata dall'opzione
.IR map_daemon ,
ed usa il protocollo RPC UGID. Perch funzioni, si deve avviare nel
cliente il demone di correlazione
.BR ugidd (8).
Questo  il meno sicuro dei tre metodi, poich grazie a
.I ugidd
ognuno pu richiedere al cliente un elenco dei nomi utente validi. Ci
si pu proteggere da questo rischio restringendo l'accesso a
.I ugidd
ai soli nodi validi: basta inserire l'elenco dei nodi validi in
.I hosts.allow
o (quelli invalidi) in
.IR hosts.deny ;
il nome del servizio 
.IR ugidd .
Si veda
.I hosts_access (5)
per una descrizione della sintassi dei questi file.
.PP
La correlazione statica si attiva con l'opzione
.IR map_static ,
che prende come argomento il nome di un file che descrive la
correlazione. La correlazione basata su NIS richiede al server NIS del
cliente di mettere in relazione i nomi utente e gruppo sul server con
quelli sul cliente.
.PP
Ecco qui una lista completa delle opzioni di correlazione:
.TP
.IR root_squash
Trasforma le richieste dell'uid/gid 0 nel'uid/gid anonimo. Si noti che ci
non  applicato a ogni altro uid che potrebbe essere ugualmente
sensibile, come l'utente 
.IR bin .
.TP
.IR no_root_squash
Disabilita il root squashing. Questa opzione  utile principalmente
per clienti senza disco (diskless).
.TP
.IR squash_uids " e " squash_gids
Questa opzione specifica un elenco di uid e gid che dovrebbero essere
trasformati in anonimo. Un'elenco valido di uid  come
questo: 
.IP
squash_uids=0-15,20,25-50
.IP
Solitamente la propria lista di squash sar molto pi semplice.
.TP
.IR all_squash
Trasforma tutti gli uid e i gid nell'utente anonimo. Utile per directory
FTP pubbliche esportate in NFS, directory di spool delle news,
ecc. L'opzione opposta 
.IR no_all_squash ,
che  l'impostazione predefinita.
.TP
.IR map_daemon
Questa opzione abilita la correlazione dinamica di uid/gid. Ogni uid in
una richiesta NFS sar tradotto nell'equivalente uid nel server, e
ogni uid in una risposta NFS sar trasformato nel modo opposto. Questa
opzione richiede che
.BR rpc.ugidd (8)
giri nel cliente. L'impostazione predefinita 
.IR map_identity ,
che lascia invariati tutti gli uid. Le normali opzioni di squash si
applicano indipendentemente dall'attivazione della correlazione dinamica.
.TP
.IR map_static
Questa opzione abilita la correlazione statica: specifica un file che
descrive le trasformazioni di uid e gid. Ad esempio,
.IP
.IR map_static=/etc/nfs/foobar.map
.IP
Il formato del file ha questo aspetto:
.IP
.nf
.ta +3i
# Correlazioni per il cliente pippo:
#    remoto     locale
uid  0-99       -       # schiscia questi
uid  100-500    1000    # trasforma 100-500 in 1000-1500
gid  0-49       -       # schiscia questi
gid  50-100     700     # trasforma 50-100 in 700-750
.fi
.TP
.IR map_nis
Questa opzione abilita la correlazione basata su NIS. Per esempio, se
il server s'imbatte nello uid 123, considera il nome utente associato
e contatta il server NIS del cliente NFS per ottenere lo uid associato
a quel nome sul cliente.
.IP
Per fare ci, il server NFS deve conoscere il dominio NIS del
cliente: lo si specifichi come argomento all'opzione
.IR map_nis ;
per esempio,
.IP
.I map_nis=pippo.com
.IP
Si noti che indicare qui il dominio NIS potrebbe non bastare:
ulteriori azioni potrebbero essere necessarie prima che
.I nfsd
possa entrare in contatto col server. Se la propria distribuzione
utilizza la libreria NYS, uno o pi server NIS per il dominio del
cliente possono essere specificati in
.IR /etc/yp.conf .
Se  in uso un'altra libreria NIS, potrebbe essere necessario ottenere
un demone
.IR ypbind (8)
speciale da configurare tramite
.IR yp.conf .
.TP
.IR anonuid " e " anongid
Queste opzioni impostano esplicitamente l'uid e il gid dell'account
anonimo. Sono utili principalmente per clienti PC/NFS, dove si potrebbe
volere che tutte le richieste appaiano provenire da un unico
utente. Per esempio, si consideri la voce per esportare
.B /home/vasco
nella sottostante sezione ESEMPIO, che trasforma tutte le richieste
all'uid 150 (che si suppone essere quello dell'utente vasco).
.IP
.SH ESEMPIO
.PP
.nf
.ta +3i
# campione di /etc/exports
/               capo(rw) fiducioso(rw,no_root_squash)
/progetti       prog*.dominio.locale(rw)
/usr            *.dominio.locale(ro) @fiducioso(rw)
/home/vasco     pc001(rw,all_squash,anonuid=150,anongid=100)
/pub            (ro,insecure,all_squash)
/pub/privato    (noaccess)
.fi
.PP
La prima riga esporta l'intero filesystem alle macchine capo e
fiducioso. In aggiunta all'accesso in scrittura,  disabilitato l'uid
squashing per fiducioso. La seconda e terza voce mostrano esempi
di metacaratteri per nomi di nodi e gruppi (la voce `@fiducioso). La
quarta riga mostra la voce per un cliente PC/NFS di cui si  parlato prima.
La quinta riga esporta la directory FTP pubblica ad ogni nodo
sul pianeta, eseguendo tutte le richieste sotto l'account
nobody. L'opzione 
.I insecure 
in questa voce permette anche clienti il cui NFS
non usi la porta riservata per NFS. L'ultima riga nega l'accesso alla
directory privata a tutti i clienti NFS.
.SH AVVERTENZE
Diversamente da altre implementazioni del server NFS, questo
.B nfsd
permette di esportare verso lo stesso nodo una directory ed una sua
sottodirectory, per esempio
.IR /usr " e " /usr/X11R6 .
In questo caso, sono applicate le opzioni di mount della voce pi
specifica. Per esempio, quando un utente accede nel cliente ad un file
in 
.IR /usr/X11R6 ,
sono applicate le opzioni di mount date nella voce relativa a
.IR /usr/X11R6 .
Questo vale anche quando quest'ultima  data da un metacarattere o un
gruppo di rete.
.SH FILE
/etc/exports
.SH DIAGNOSTICA
Ogni errore nell'analisi del file, riscontrato durante l'avvio di
.BR nfsd (8)
oppure
.BR mountd (8),
viene segnalato tramite
.BR syslogd (8)
al livello NOTICE in provenienza da un DEMONE. Qualsiasi nodo
sconosciuto  segnalato in questo momento, ma spesso non tutti i
nodi sono gi noti a named(8) al momento dell'avvio, quindi vengono
segnalati, con gli stessi parametri di syslogd(8), non appena trovati.
.SH VEDERE ANCHE
mountd(8), nfsd(8)