Provided by: manpages-it_0.3.4-5_all bug

NOME

       exports - file system NFS che sono esportati

SINTASSI

       /etc/exports

DESCRIZIONE

       Il  file  /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, mountd(8) che dal demone di file server NFS
       nfsd(8).

       Il formato del file è simile a quello del file 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.

   Formato dei nomi delle macchine
       I clienti NFS possono essere specificati in più modi:

       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.

       gruppi di reti
              I gruppi NIS possono essere dati come @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.

       metacaratteri
              I  nomi  delle macchine possono conteneri i metacaratteri * e ?:
              ciò può essere usare per rendere più compatto il  file  exports;
              per esempio, *.cs.foo.edu corrisponde a tutti i nodi nel dominio
              cs.foo.edu. Questi metacaratteri,  però,  non  corrispondono  ai
              punti  del  nome  del  dominio,  per cui il modello di prima non
              corrisponderebbe a a.b.cs.foo.edu.

       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 indirizzo/netmask.

       =public
              Questo è un nome speciale che indica la directory data  come  la
              directory  radice publica (vedi la sezione WebNFS di nfsd(8) per
              una discussione su WebNFS e la gestione della radice  pubblica).
              Usando  questa  convenzione, =public deve essere l’unica opzione
              della riga e  nessuna  opzione  d’esportazione  gli  può  essere
              associata. Si noti che in realtà questo non esporta la directory
              citata: bisogna ancora dare le  opzioni  d’esportazione  in  una
              voce separata.

       Il   percorso  della  radice  pubblica  può  essere  specificato  anche
       invocando nfsd con l’opzione --public-root.  Specifiche ripetute  della
       radice pubblica vengono ignorate.

   Opzioni Generali
       mountd e nfsd comprendono le seguenti opzioni d’esportazione:

       secure 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 insecure.

       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 rw.

       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.

       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.

       link_absolute
              Lascia   stare  tutti  i  collegamenti.  Questa  è  l’operazione
              predefinita.

   Correlazione degli identificativi utente
       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.

       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  nobody  (nessuno).
       Questo  è il modo di operare (detto «root squashing»=«schiacciamento di
       root») predefinito, e può essere disabilitato con no_root_squash.

       Di default, nfsd prova a ottenere l’uid e  il  gid  anonimi  ricercando
       all’avvio  l’utente  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 anonuid e anongid.

       Oltre  a  questo, 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 all_squash.

       A beneficio  delle  installazioni  in  cui  gli  uid  differiscono  tra
       macchine  diverse, 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 ugidd.

       La correlazione basata su ugidd è avviata dall’opzione  map_daemon,  ed
       usa  il  protocollo  RPC  UGID.  Perché  funzioni,  si deve avviare nel
       cliente il demone di correlazione ugidd(8).  Questo è  il  meno  sicuro
       dei  tre metodi, poiché grazie a ugidd ognuno può richiedere al cliente
       un elenco dei nomi utente  validi.  Ci  si  può  proteggere  da  questo
       rischio  restringendo  l’accesso  a  ugidd  ai  soli nodi validi: basta
       inserire l’elenco dei nodi validi in hosts.allow o (quelli invalidi) in
       hosts.deny; il nome del servizio è ugidd.  Si veda hosts_access (5) per
       una descrizione della sintassi dei questi file.

       La correlazione statica si attiva con l’opzione 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.

       Ecco qui una lista completa delle opzioni di correlazione:

       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 bin.

       no_root_squash
              Disabilita  il  root   squashing.   Questa   opzione   è   utile
              principalmente per clienti senza disco (diskless).

       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:

              squash_uids=0-15,20,25-50

              Solitamente  la propria lista di squash sarà molto più semplice.

       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  è  no_all_squash,  che  è
              l’impostazione predefinita.

       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  rpc.ugidd(8)  giri  nel
              cliente.  L’impostazione  predefinita è map_identity, che lascia
              invariati tutti  gli  uid.  Le  normali  opzioni  di  squash  si
              applicano  indipendentemente dall’attivazione della correlazione
              dinamica.

       map_static
              Questa opzione abilita la  correlazione  statica:  specifica  un
              file che descrive le trasformazioni di uid e gid. Ad esempio,

              map_static=/etc/nfs/foobar.map

              Il formato del file ha questo aspetto:

              # 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

       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.

              Per fare ciò, il server NFS deve conoscere il  dominio  NIS  del
              cliente:  lo  si  specifichi come argomento all’opzione map_nis;
              per esempio,

              map_nis=pippo.com

              Si noti che indicare qui il dominio NIS  potrebbe  non  bastare:
              ulteriori  azioni  potrebbero  essere  necessarie prima che 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
              /etc/yp.conf.   Se  è  in  uso  un’altra  libreria NIS, potrebbe
              essere necessario  ottenere  un  demone  ypbind(8)  speciale  da
              configurare tramite yp.conf.

       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 /home/vasco nella sottostante sezione ESEMPIO, che
              trasforma tutte le richieste all’uid 150 (che si suppone  essere
              quello dell’utente vasco).

ESEMPIO

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

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

AVVERTENZE

       Diversamente da altre  implementazioni  del  server  NFS,  questo  nfsd
       permette  di  esportare  verso  lo stesso nodo una directory ed una sua
       sottodirectory, per esempio /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  /usr/X11R6,  sono
       applicate  le  opzioni  di mount date nella voce relativa a /usr/X11R6.
       Questo vale anche quando quest’ultima è data da un metacarattere  o  un
       gruppo di rete.

FILE

       /etc/exports

DIAGNOSTICA

       Ogni  errore  nell’analisi  del  file,  riscontrato  durante l’avvio di
       nfsd(8) oppure mountd(8), viene segnalato tramite 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.

VEDERE ANCHE

       mountd(8), nfsd(8)