Provided by:
manpages-fr-extra_20111118_all 
NOM
nfs - Format de fstab et options pour les systemes de fichiers nfs
SYNOPSIS
/etc/fstab
DESCRIPTION
NFS est un protocole standard de l'Internet cree par Sun Microsystem en
1984. NFS a ete developpe pour permettre le partage de fichiers entre
des systemes connectes a un reseau local. Le client NFS de Linux gere
trois versions du protocole : NFS version 2 [RFC1094], NFS version 3
[RFC1813], et NFS version 4 [RFC3530].
La commande mount(8) lie un systeme de fichiers au point de montage
donne dans l'espace de noms hierarchise du systeme. Le fichier
/etc/fstab decrit la facon dont mount(8) doit recreer la hierarchie de
l'espace de noms du systeme de fichiers a partir de systemes de
fichiers independants (dont ceux partages par des serveurs NFS).
Chacune des lignes du fichier /etc/fstab decrit un unique systeme de
fichiers, son point de montage, et un ensemble d'options par defaut
pour ce point de montage.
Dans le cas des montages de systemes de fichiers NFS, une ligne dans le
fichier /etc/fstab indique le nom du serveur, le chemin du repertoire
partage a monter, le repertoire local qui sera le point de montage, le
type de systeme de fichiers a monter et la liste des options de montage
qui indique la facon dont le systeme de fichiers sera monte et quel
sera le comportement du client NFS lorsqu'il accedera aux fichiers du
point de montage. Le cinquieme et le sixieme champs de chaque ligne ne
sont pas utilises par NFS, et par consequent contiennent par convention
la valeur zero. Par exemple :
serv:chemin /pt_montage type_fs option,option,... 0 0
Le nom du serveur et le chemin de partage sont separes par un deux
points, tandis que les options de montage sont separees par des
virgules. Les champs restants sont separes par des espaces ou des
tabulations.
Le nom du serveur peut etre un nom d'hote non qualifie, un nom de
domaine pleinement qualifie (<< fully qualified domain name >>), une
adresse IPv4, ou une adresse IPv6 entouree par des crochets. Les
adresses IPv6 de liens locaux ou de sites locaux doivent etre
accompagnees d'un identifiant d'interface. Referez-vous a ipv6(7) pour
des details quant a l'ecriture des adresse IPv6 brutes.
Le champ fstype contient << nfs >>. La valeur << nfs4 >> est obsolete.
OPTIONS DE MONTAGE
Consultez mount(8) pour la description des options de montage
generiques disponibles pour tous les systemes de fichiers. Si vous
n'avez pas besoin d'indiquer d'options de montage particulieres,
utilisez l'option generique defaults dans /etc/fstab.
Options prises en charge par toutes les versions
Les options suivantes peuvent etre utilisees avec n'importe quelle
version de NFS.
soft / hard Definir le comportement de recuperation du client NFS
lorsqu'une requete NFS ne repond pas (<< time out >>).
Si aucune option n'est indiquee (ou si c'est l'option
hard qui a ete choisie), les requetes NFS sont retentees
indefiniment. Si par contre l'option soft a ete choisie,
le client NFS levera un echec apres l'envoi de retrans
retransmissions, entrainant alors le retour d'une erreur
a l'application appelante.
NB : Un delai expire << soft >> peut provoquer dans
certains cas des erreurs de donnees non signalees. C'est
pourquoi l'option soft doit etre utilisee uniquement si
la reactivite du client est plus importante que
l'integrite des donnees. L'utilisation de NFS avec TCP
ou l'augmentation de la valeur de l'option retrans peut
diminuer les risques lies a l'utilisation de l'option
soft.
timeo=n Le temps en dixiemes de seconde ou le client NFS attend
une reponse avant qu'il reessaie une requete NFS.
Pour NFS sur TCP, la valeur timeo est de 600 par defaut
(60 secondes). Le client NFS effectue une progression
lineaire : apres chaque retransmission la temporisation
est augmentee de timeo jusqu'au maximum de 600 secondes.
Cependant, dans le cas de NFS sur UDP, le client utilise
un algorithme evolutif pour estimer la valeur appropriee
de depassement de temps (<< timeout >>) pour les types
de requetes frequemment utilisees (les requetes READ et
WRITE par exemple), mais utilise le reglage timeo pour
les requetes moins courantes (comme FSINFO). Si l'option
timeo n'est pas definie, les types de requetes moins
courantes sont re-emises apres 1,1 secondes. Apres
chaque re-emission, le client NFS double la valeur de
depassement de temps pour cette requete, jusqu'a
atteindre un maximum de 60 secondes.
retrans=n Nombre de tentatives de re-emission de la requete avant
que le client NFS n'enclenche une action de
recuperation. Si l'option retrans n'est pas definie, le
client NFS essaye chaque requete trois fois.
Le client NFS genere un message << le serveur ne repond
pas >> apres retrans tentatives, puis enclenche la
recuperation (qui depend de l'activation de l'option
hard de mount).
rsize=n Nombre maximal d'octets pour chaque requete reseau en
LECTURE que peut recevoir le client NFS lorsqu'il lit
les donnees d'un fichier sur le serveur NFS. La taille
reelle de la charge utile de donnees pour chaque requete
NFS en LECTURE est plus petite ou egale au reglage
rsize. La plus grande charge utile geree par le client
NFS Linux est de 1 048 576 octets (un mega-octet).
La valeur de rsize est un entier positif multiple de
1024. Les valeurs de rsize inferieures a 1024 sont
remplacees par 4096, et celles superieures a 1 048 576
sont remplacees par 1 048 576. Si la valeur indiquee est
bien dans la plage geree, mais qu'elle n'est pas un
multiple de 1024, elle sera arrondie au multiple de 1024
inferieur le plus proche.
Si la valeur de rsize n'est pas definie, ou si la valeur
de rsize depasse le maximum qu'a la fois le client et le
serveur peuvent gerer, le client et le serveur negocient
la plus grande valeur de rsize qu'ils puissent gerer
ensemble.
L'option rsize de mount telle qu'elle a ete definie sur
la ligne de commande lors du mount(8) apparait dans le
fichier /etc/mtab. D'autre part, la valeur reelle de
rsize negociee entre le client et le serveur est
indiquee dans le fichier /proc/mounts.
wsize=n Nombre maximal d'octets par requete d'ECRITURE reseau
que le client NFS peut envoyer quand il ecrit des
donnees dans un fichier sur un serveur NFS. La taille
reelle de la charge utile de donnees pour chaque requete
NFS en ECRITURE est plus petite ou egale au reglage
wsize. La plus grande charge utile geree par le client
NFS Linux est de 1 048 576 octets (un mega-octet).
Comme pour rsize, la valeur de wsize est un entier
positif multiple de 1024. Les valeurs de wsize
inferieures a 1024 sont remplacees par 4096, et celles
superieures a 1 048 576 par 1 048 576. Si la valeur
definie est bien dans l'etendue valide mais qu'elle
n'est pas multiple de 1024, elle est arrondie au
multiple de 1024 inferieur le plus proche.
Si la valeur de wsize n'est pas definie, ou si la valeur
wsize indiquee est superieure au maximum que soit le
client soit le serveur peut gerer, le client et le
serveur negocient la plus grande valeur de wsize qu'ils
peuvent tous les deux gerer.
L'option wsize de mount telle qu'elle a ete indiquee sur
la ligne de commande du mount(8) apparait dans le
fichier /etc/mtab. D'autre part, la valeur reelle de
wsize negociee par le client et le serveur est indiquee
dans le fichier /proc/mounts.
ac / noac Definir si le client peut memoriser (cache) les
attributs des fichiers. Si aucune option n'est indiquee
(ou si c'est ac qui est choisi), le client memorise les
attributs des fichiers.
Afin d'ameliorer les performances, les clients NFS
memorisent (mettent en cache) les attributs des
fichiers. Toutes les quelques secondes, un client NFS
verifie les attributs de chaque fichier de la version du
serveur afin de se mettre a jour. Les modifications qui
interviennent pendant ces petits intervalles restent
inapercues tant que le client n'a pas relance sa
verification sur le serveur. L'option noac empeche la
memorisation des attributs de fichiers par le client, ce
qui permet aux applications de detecter plus rapidement
les modifications des fichiers sur le serveur.
En plus d'empecher le client de memoriser les attributs
des fichiers, l'option noac force l'ecriture
synchronisee pour les applications afin que les
modifications sur un fichier soient immediatement
visibles sur le serveur. De cette facon, les autres
clients peuvent rapidement detecter les nouvelles
ecritures lors de la verification des attributs du
fichier.
L'usage de l'option noac offre une plus grande coherence
du cache aux clients NFS qui accedent aux memes
fichiers, mais au prix d'une penalisation significative
des performances. C'est pour cette raison qu'une
utilisation judicieuse des verrouillages (<< locking >>)
de fichiers est preferable. La section COH'ERENCE DES
DONN'EES ET DES M'ETADONN'EES contient une presentation
detaillee de ces approches.
acregmin=n Duree minimale (en seconde) de memorisation (cache) des
attributs d'un fichier normal avant leur actualisation
depuis le serveur. La valeur par defaut est de
3 secondes, si cette option n'est pas definie.
acregmax=n Duree maximale (en seconde) de memorisation (cache) des
attributs d'un fichier normal avant leur actualisation
depuis le serveur. La valeur par defaut est de
60 secondes, si cette option n'est pas definie.
acdirmin=n Duree minimale (en seconde) de memorisation (cache) des
attributs d'un repertoire avant leur actualisation
depuis le serveur. La valeur par defaut est de
30 secondes, si cette option n'est pas definie.
acdirmax=n Duree maximale (en seconde) de memorisation (cache) des
attributs d'un repertoire avant leur actualisation
depuis le serveur. La valeur par defaut est de
60 secondes, si cette option n'est pas definie.
actimeo=n L'utilisation de actimeo configure toutes les durees
acregmin, acregmax, acdirmin et bacdirmax a la meme
valeur. Si cette option n'est pas definie, le client
utilisera les valeurs par defaut de chacune des options,
telles que decrites ci-dessus.
bg / fg Determiner le comportement de la commande mount(8) dans
le cas d'un echec d'une tentative de montage d'un
partage. L'option fg entraine l'arret de mount(8) avec
un statut d'erreur si la moindre partie de la requete de
montage depasse le temps alloue ou echoue d'une
quelconque autre maniere. C'est ce que l'on appelle le
montage en << premier plan (foreground) >>, et c'est le
comportement par defaut si ni fg ni bg n'est indique.
Si l'option bg est indiquee, un depassement du temps
alloue (timeout) ou un echec entrainera la creation d'un
fils (fork) qui continuera a essayer de monter le
partage. Le pere s'interrompt immediatement en renvoyant
un code de sortie a zero. C'est ce que l'on appelle le
montage en << arriere-plan (background) >>.
Si le repertoire servant de point de montage local
n'existe pas, la commande mount(8) se comporte comme si
la requete etait restee sans reponse (timeout). Cela
permet aux montages NFS imbriques definis dans
/etc/fstab de s'executer dans n'importe quel ordre lors
de l'initialisation du systeme, meme si certains
serveurs NFS ne sont pas encore disponibles. On peut
aussi gerer ces problemes grace a un auto-monteur
(consultez automount(8) pour plus de details).
retry=n Duree, en minute, pendant laquelle le montage NFS sera
tente par la commande mount(8), en arriere-plan ou au
premier plan, avant d'abandonner. Si l'option n'est pas
definie, la valeur par defaut pour le premier plan est
de 2 minutes, et celle pour l'arriere-plan est
10 000 minutes, soit environ une semaine, a 80 minutes
pres. La commande mount(8) s'arretera des le premier
echec si on lui passe la valeur 0.
sec=mode Le type de securite RPCGSS a utiliser pour acceder aux
fichiers de ce point de montage. Si l'option sec n'est
pas definie, ou si sec=sys est choisie, le client NFS
utilise le type de securite AUTH_SYS pour toute requete
NFS sur ce point de montage. Les types de securite geres
sont none, sys, krb5, krb5i, krb5p, lkey, lkeyi, lkeyp,
spkm, spkmi et spkmp. Consultez la section
CONSID'ERATIONS DE S'ECURIT'E.
sharecache / nosharecache
Determiner comment le client partage ses caches de
donnees et d'attributs de fichiers lorsqu'un meme
partage est monte plus d'une fois en meme temps.
L'utilisation d'un seul cache reduit les besoins en
memoire sur le client et presente aux applications un
contenu identique lorsque le meme fichier partage est
accede via differents points de montage.
Si aucune des options n'est indiquee, ou si l'option
sharecache est demandee, un seul cache est utilise pour
tous les points de montage qui accedent au meme partage.
Si l'option nosharecache est indiquee, ce point de
montage utilise son propre cache. Notez que lorsque les
caches des donnees et des attributs sont partages, les
options de montage du premier point de montage
s'appliquent pour les futurs montages de ce meme
partage, tant que celui-ci est monte.
En ce qui concerne le noyau 2.6.18, le comportement
defini par nosharecache est le comportement historique
normal. Ceci est considere comme dangereux pour les
donnees puisque de multiples copies memorisees du meme
fichier sur le meme client peuvent se desynchroniser
suite a une mise a jour locale d'une des copies.
resvport / noresvport
Indiquer si le client NFS doit utiliser un port source
privilegie quand il communique avec un serveur NFS pour
ce point de montage. Si cette option n'est pas precisee,
ou si l'option resvport est precisee, le client NFS
utilise un port source privilegie. Si l'option
noresvport est activee, le client NFS utilise un port
source non privilegie. Cette option est permise par les
noyaux 2.6.28 et suivants.
Utiliser un port source non privilegie permet
d'augmenter le nombre maximal de points de montages
permis par client, mais les serveurs NFS doivent etre
configures pour permettre la connexion de clients par
des ports source non privilegies.
Veuillez consulter la section CONSID'ERATIONS DE S'ECURIT'E
pour d'importantes precisions.
lookupcache=mode
Preciser comment le noyau s'occupe du cache des entrees
de repertoire pour un point de montage donne. mode peut
etre all, none, pos ou positive. Cette option est prise
en charge par les noyaux 2.6.28 et suivants.
Le client NFS Linux garde en cache tous les resultats
des requetes NFS LOOKUP. Si le repertoire indique existe
sur le serveur, le resultat renvoye est positif
(<< positive >>), sinon c'est n'egatif (<< negative >>).
Si cette option n'est pas precisee, ou si all est
precise, le client suppose que les deux types d'entrees
(positif ou n'egatif) du cache de repertoire sont
valables jusqu'a ce que le cache de leur repertoire
parent expire.
Si pos ou positive est precise, le client suppose que
les entrees positives sont valables jusqu'a ce que le
cache de leur repertoire parent expire, mais valide les
entrees negatives avant qu'une application les utilise.
Si none est precise, le client valide a nouveau les deux
types d'entrees de cache de repertoire avant qu'une
application puisse les utiliser. Cela permet une
detection rapide des fichiers qui ont ete crees ou
supprimes par d'autres clients, mais peut avoir des
repercussions sur ces applications et les performances
du serveur.
La partie COH'ERENCE DES DONN'EES ET DES M'ETADONN'EES
contient un propos detaille sur ces echanges.
Options pour les versions NFS 2 et 3 uniquement
Utilisez ces options ainsi que les options de la sous-section
precedente uniquement pour les systemes de fichiers de type NFS
version 2 et 3.
proto=idreseau Le nom et la famille du protocole de transport
qu'utilise le client NFS pour transmettre ses requetes
au serveur NFS pour ce point de montage. Si un serveur
NFS a en meme temps une adresse IPv4 et une IPv6,
l'utilisation d'un identifiant reseau idreseau
entrainera le choix d'IPv4 ou d'IPv6 pour communiquer
avec ce serveur.
Si la prise en charge de TI-RPC est compilee dans la
commande mount.nfs, netid doit etre un identifiant
reseau valable present dans le fichier /etc/netconfig.
On peut fournir une valeur a << rdma >>. Si la commande
mount.nfs ne gere pas TI-RPC, netid doit valoir
<< tcp >>, << udp >> ou << rdma >>, et on utilisera
alors uniquement une adresse IPv4.
Chaque protocole de transport utilise differents
reglages de retransmission et de timeo. Merci de vous
referer a la description de ces deux options de montage
En plus de controler la facon dont le client NFS
transmet les requetes au serveur, cette option de mount
gere aussi la facon dont la commande mount(8) communique
avec les services rpcbind et mountd du serveur. Indiquer
un id reseau qui utilise TCP entraine l'utilisation de
TCP par tout le trafic passant par la commande mount(8)
ou le client NFS. Reciproquement, indiquer UDP entraine
l'utilisation d'UDP par tout le trafic.
Si l'option proto de mount n'est pas definie, la
commande mount(8) decouvrira quels protocoles sont
acceptes par le serveur et choisira un transport
approprie pour chacun des services. Consultez la section
M'ETHODES DE TRANSPORT pour plus de details.
udp L'option udp est une variante pour proto=udp, compatible
avec d'autres systemes d'exploitation.
tcp L'option tcp est une variante pour proto=tcp, compatible
avec d'autres systemes d'exploitation.
rdma L'option rdma est une variante pour proto=rdma.
port=n Valeur numerique du port du service NFS sur le serveur.
Si le service NFS du serveur n'est pas accessible sur le
port indique, la requete de montage echoue.
Si cette option n'est pas definie, ou si le port indique
est 0, le client NFS utilise le numero du port du
service NFS publie par le service rpcbind du serveur. La
requete de montage echoue si le service rpcbind du
serveur n'est pas accessible, si le service NFS du
serveur n'est pas enregistre dans son service rpcbind,
ou si le service NFS du serveur n'est pas accessible sur
le port publie.
mountport=n Valeur numerique du port de mountd sur le serveur. Si le
service mountd du serveur n'est pas present sur le port
indique, la requete de montage echoue.
Si cette option n'est pas definie, ou si le port indique
est 0, la commande mount(8) utilise le numero du port du
service mountd publie par le service rpcbind du serveur.
La requete de montage echoue si le service rpcbind du
serveur n'est pas accessible, si le service mountd du
serveur n'est pas enregistre dans son service rpcbind,
ou si le service mountd du serveur n'est pas accessible
sur le port publie.
Cette option peut etre utilisee pour les montages sur un
serveur NFS a travers un pare-feu qui bloque le
protocole rpcbind.
mountproto=idreseau
Le nom et la famille du protocole de transport que le
client NFS utilise pour transmettre ses requetes au
service mountd d'un serveur NFS quand il lance cette
requete de montage, puis quand il demontera ensuite ce
montage.
Si la prise en charge pour TI-RPC est compilee dans la
commande mount.nfs, idreseau peut etre un identifiant
reseau valide parmi ceux listes dans /etc/netconfig.
Sinon, idreseau doit valoir << tcp >> ou << udp >>, et
IPv4 sera utilise.
Cette option peut etre utilisee pour monter un serveur
NFS a travers un pare-feu qui bloque des transferts
specifiques. Utilise avec l'option proto, differents
modes de transfert peuvent etre choisis pour les
requetes vers mountd et NFS. Si le serveur ne propose
pas de service pour le mode indique, la requete de
montage echoue.
Veuillez consulter la section M'ETHODES DE TRANSPORT pour
plus de renseignements sur la maniere dont l'option de
montage mountproto interagit avec l'option proto.
mounthost=nom Le nom d'hote de la machine qui execute le mountd. Si
cette option n'est pas definie, la commande mount(8)
considere que le service mountd est assure par la
machine qui offre le service NFS.
mountvers=n Numero de version des RPC utilise pour contacter le
mountd du serveur. Si cette option n'est pas definie, le
client utilise un numero de version approprie a la
version du NFS contacte. Cette option est utile quand de
nombreux services NFS sont offerts par un seul et meme
serveur.
namlen=n La taille maximale d'un composant du nom de chemin ce
montage. Si cette option n'est pas definie, la taille
maximale est negociee avec le serveur. Dans la plupart
des cas, cette taille maximale est 255 caracteres.
Des versions precedentes de NFS ne gerent pas cette
negociation. L'utilisation de cette option garantit que
pathconf(3) donnera bien la longueur maximale aux
applications pour ces versions.
nfsvers=n Le numero de version du protocole NFS utilise pour
contacter le service NFS du serveur. Si le serveur ne
gere pas la version demandee, la requete de montage
echoue. Si cette option n'est pas definie, le client
tente de trouver une version adaptee au serveur, en
tentant successivement les versions 4, 3 puis 2.
vers=n Cette option est une variante pour l'option nfsvers,
compatible avec d'autres systemes d'exploitation.
lock / nolock Indiquer s'il faut utiliser le protocole auxiliaire NLM
pour verrouiller les fichiers sur le serveur. Si aucune
option n'est indiquee (ou si c'est lock qui est choisi),
le verrouillage NLM est active pour ce point de montage.
Si on utilise l'option nolock, les applications peuvent
verrouiller les fichiers, mais ces verrous n'ont de
portee que pour les applications qui tournent sur ce
meme client. Les applications distantes ne sont pas
informees de ces verrous.
Le verrouillage NLM doit etre desactive lors de
l'utilisation de l'option nolock si /var est monte via
NFS, parce que /var contient des fichiers utilises par
l'implementation de NLM sous Linux. L'usage de nolock
est aussi requis lors des montages de partages de
serveurs NFS ne gerant pas le protocole NLM.
intr / nointr Indiquer si les signaux peuvent interrompre les
operations sur le fichier pour ce point de montage. Si
aucune option n'est indiquee (ou si nointr est choisi),
les signaux n'interrompent pas les operations NFS sur
les fichiers. Si intr est indique, les appels systemes
renvoient EINTR si une operation NFS en cours est
interrompue par un signal.
L'utilisation de l'option intr est preferable a celle de
l'option soft car le risque de corruption des donnees
est moins important.
Les options de montage intr/ nointr sont obsoletes pour
des noyaux ulterieurs au 2.6.25. Seul un signal de
terminaison SIGKILL peut interrompre une operation NFS
en cours sur ces noyaux, et, si precisee, cette option
est ignoree pour assurer une compatibilite ascendante
sur des anciens noyaux.
cto / nocto Indiquer s'il faut utiliser la semantique de coherence
de cache close-to-open. Si aucune option n'est indiquee
(ou si c'est cto qui est choisi), le client utilise la
semantique de coherence de cache close-to-open. Si c'est
l'option nocto qui est choisie, le client utilise une
heuristique non standard pour savoir quand les fichiers
ont change sur le serveur.
L'utilisation de l'option nocto peut ameliorer les
performances des montages en lecture seule, mais devrait
etre limitee au cas ou les donnees sur le serveur ne
changent qu'occasionnellement. La section COH'ERENCE DES
DONN'EES ET DES M'ETADONN'EES expose le comportement de
cette option en details.
acl / noacl Indiquer s'il faut utiliser le protocole auxiliaire
NFSACL sur ce point de montage. Le protocole auxiliaire
NFSACL est un protocole proprietaire mis en oeuvre dans
Solaris et qui gere les listes de controle d'acces (les
ACLs). NSFACL n'est jamais devenu un element standard de
la specification du protocole NFS.
Si ni acl ni noacl ne sont precisees, le client NFS
negocie avec le serveur afin de savoir si le protocole
NFSACL est actif, et l'utilise dans ce cas. La
desactivation du protocole auxiliaire NFSACL est parfois
rendue necessaire quand la negociation pose des
problemes sur le client ou sur le serveur. Consultez la
section CONSID'ERATIONS DE S'ECURIT'E pour plus de details.
rdirplus / nordirplus
Indiquer s'il faut utiliser les requetes READDIRPLUS de
NFS version 3. Si cette option n'est pas definie, le
client NFS utilisera les requetes READDIRPLUS sur les
montages en NFS version 3 pour la lecture des petits
repertoires. Certaines applications sont plus efficaces
si le client n'utilise que des requetes READDIR pour
tous les repertoires.
local_lock=m'ecanisme
Precise si le verrouillage local doit etre utilise pour
les mecanismes flock, POSIX, ou les deux. mechanism
peut etre all, flock, posix, or none. Cette option est
prise en charge par les noyaux 2.6.37 et suivants.
Le client Linux NFS fournit un moyen de poser des
verrous locaux. Les applications peuvent donc
verrouiller des fichiers, mais ces verrous n'ont de
portee que pour les applications qui tournent sur ce
meme client. Les applications distantes ne sont pas
informees de ces verrous.
Si cette option n'est pas precisee, ou si none est
precise, le client suppose que les verrous ne sont pas
locaux.
Si all est specifie, le client suppose que les deux
types de verrous flock et POSIX sont locaux.
Si flock est specifie, le client suppose que seuls les
verrous flock sont locaux, et utilise le protocole NLM
associe pour verrouiller les fichiers quand les verrous
POSIX sont utilises.
Si posix est specifie, le client suppose que les verrous
POSIX sont locaux, et utilise le protocole NLM associe
pour verrouiller les fichiers quand les verrous flock
sont utilises.
Pour supporter le comportement flock de facon semblable
a celui des clients NFS < 2.6.12, utiliser 'local_lock=
flock'. Cette option est requise lors de l'exportation
des montages NFS via Samba comme des cartes Windows
Samba partage en mode verrouille flock. Puisque les
clients NFS > 2.6.12 utilise flock en emulant les
verrous POSIX, il y aura un conflit de verrous.
NOTE : Quand elles sont utilisees ensemble, l'option de
montage 'local_lock' sera ecrasee par l'option de
montage 'nolock'/'lock'.
Options pour NFS version 4 uniquement
Utilisez ces options ainsi que les options de la premiere sous-section
ci-dessus pour les systemes de fichiers de type NFS version 4 et plus
recents.
proto=idreseau Le nom et la famille du protocole de transport
qu'utilise le client NFS pour transmettre ses requetes
au serveur NFS pour ce point de montage. Si un serveur
NFS a en meme temps une adresse IPv4 et une IPv6,
l'utilisation d'un identifiant reseau idreseau
entrainera le choix d'IPv4 ou d'IPv6 pour communiquer
avec ce serveur.
Si la prise en charge pour TI-RPC est compilee dans la
commande mount.nfs, idreseau peut etre un identifiant
reseau valide parmi ceux listes dans /etc/netconfig.
Sinon, idreseau doit valoir << tcp >> ou << udp >>, et
IPv4 sera utilise.
Les serveurs NFS version 4 doivent prendre en charge
TCP, donc si cette option n'est pas precisee, le client
NFS utilise le protocole TCP. Veuillez vous referer a la
section M'ETHODES DE TRANSPORT pour plus de details.
port=n Valeur numerique du port du service NFS sur le serveur.
Si le service NFS du serveur n'est pas accessible sur le
port indique, la requete de montage echoue.
Si cette option de montage n'est pas definie, le client
NFS utilisera le numero de port standard de NFS (2049)
sans verifier de prime abord le service rpcbind du
serveur. Cette option permet a un client NFS version 4
de contacter un serveur NFS version 4 a travers un
pare-feu qui bloquerait les requetes rpcbind.
Si la valeur du port indiquee est 0, le client NFS
utilisera le numero de port du service NFS publie par le
service rpcbind du serveur. La requete de montage
echouera si le service rpcbind du serveur n'est pas
disponible, si le service NFS du serveur n'est pas
enregistre dans son service rpcbind, ou si le service
NFS du serveur n'est pas accessible sur le port publie.
intr / nointr Indiquer si les signaux peuvent interrompre les
operations sur les fichiers pour ce point de montage. Si
aucune option n'est indiquee (ou si intr est choisi),
les appels systemes renvoient EINTR si une operation NFS
en cours est interrompue par un signal. Si nointr est
indique, les signaux n'interrompent pas les operations
NFS.
L'utilisation de l'option intr est preferable a celle de
l'option soft car le risque de corruption des donnees
est moins important.
Les options de montage intr/ nointr sont obsoletes pour
des noyaux ulterieurs au 2.6.25. Seul un signal de
terminaison SIGKILL peut interrompre une operation NFS
en cours sur ces noyaux, et, si precisee, cette option
est ignoree pour assurer une compatibilite ascendante
sur des anciens noyaux.
cto / nocto Indiquer s'il faut utiliser la semantique de coherence
du cache close-to-open pour les repertoires NFS de ce
point de montage. Si ni cto ni nocto ne sont indiquees,
la semantique de coherence du cache close-to-open sera
utilisee par defaut pour les repertoires.
La politique de mise en cache des donnees des fichiers
n'est pas concernee par cette option. La section
COH'ERENCE DES DONN'EES ET DES M'ETADONN'EES decrit le
comportement de cette option en details.
clientaddr=n.n.n.n
Indiquer une seule adresse IPv4 en quatre parties
separees par des points, ou une adresse IPv6 qui n'est
pas un lien local. Le client NFS signalera alors que les
serveurs peuvent envoyer des requetes NFSv4 de rappel
sur les fichiers de ce point de montage. Si le serveur
ne peut pas etablir de connexion de rappel
(<< callback >>) sur ces clients, les performances
peuvent etre degradees ou les acces a ces fichiers
temporairement suspendus.
Si cette option n'est pas indiquee, la commande mount(8)
essaie de decouvrir automatiquement une adresse de
rappel (<< callback >>) appropriee. La procedure de
decouverte automatique n'est cependant pas parfaite.
Dans le cas d'interfaces reseau multiples, de directives
de routages speciales ou de typologie reseau atypique,
l'adresse exacte a utiliser pour les rappels peut ne pas
etre triviale a determiner.
SYST`EME DE FICHIERS DE TYPE nfs4
Le type nfs4 de systeme de fichiers est une ancienne syntaxe precisant
l'utilisation de NFSv4. Il peut toujours etre utilise avec toutes les
options specifiques a NFSv4, a l'exception de l'option de montage
nfsvers
FICHIER DE CONFIGURATION DU MONTAGE
Si la commande de montage est configuree pour, toutes les options de
montage decrites dans la section precedente peuvent etre configurees
dans le fichier /etc/nfsmount.conf. Referez-vous a nfsmount.conf(5)
pour plus de details.
EXEMPLES
Pour realiser le montage d'un partage en NFS version 2, il faut
preciser que le type du systeme de fichiers est nfs et indiquer
l'option de montage nfsvers=2. Pour realiser un montage en NFS
version 3, il faut preciser que le type du systeme de fichiers est nfs
et indiquer l'option de montage nfsvers=3. Pour realiser un montage en
NFS version 4, il faut preciser que le type du systeme de fichiers est
nfs, avec l'option de montage nfsver=4, ou demander le systeme de
fichiers nfs4.
L'exemple de fichier /etc/fstab qui suit permet a la commande mount de
negocier des valeurs par defaut convenables pour le comportement NFS.
serveur:/export /mnt nfs defaults 0 0
Voici un exemple de ligne du fichier /etc/fstab concernant un montage
NFS version 2 en UDP.
serveur:/export /mnt nfs nfsvers=2,proto=udp 0 0
Essayez cet exemple afin de realiser un montage NFS version 4 en TCP,
utilisant l'authentification reciproque de Kerberos 5.
serveur:/export /mnt nfs4 sec=krb5 0 0
Cet exemple peut servir a realiser le montage de /usr grace a NFS.
serveur:/export /usr nfs ro,nolock,nocto,actimeo=3600 0 0
Cet exemple montre comment utiliser une adresse brute non locale IPv6.
[fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0
M'ETHODES DE TRANSPORT.
Les clients NFS envoient leurs requetes aux serveurs NFS grace aux
appels de procedures distantes (<< Remote Procedure Calls >>), les
RPCs. Le client RPC decouvre automatiquement les entrees du service
distant, gere l'authentification requete par requete, ajuste les
parametres des requetes afin de gerer l'ordre des octets sur le client
et le serveur (<< endianess >>), et se charge de la retransmission des
requetes qui pourraient s'etre perdues dans le reseau ou sur le
serveur. Les requetes et les reponses RPC circulent sur un protocole de
transport reseau.
Dans la plupart des cas, la commande mount(8), le client NFS et le
serveur NFS peuvent negocier automatiquement les valeurs adequates de
taille pour les transferts de donnees et de transport pour un point de
montage. Cependant, dans certains cas, il peut etre efficace d'indiquer
explicitement ces valeurs grace aux options de montage.
Anciennement, les clients NFS se servaient uniquement du transport UDP
pour transmettre des requetes aux serveurs. Bien que son implementation
soit simple, NFS sur UDP a de nombreuses limitations qui l'empechent
d'obtenir de bonnes performances et un fonctionnement fluide dans
certains environnements de deploiement courants. Un taux de paquets
perdus meme insignifiant entraine la perte de requetes NFS completes.
On regle alors generalement le delai de depassement (<< timeout >>) a
une valeur inferieure a la seconde afin que les clients puissent
recuperer rapidement en cas de requetes rejetees. Cela peut entrainer
une surcharge du trafic reseau et du serveur.
Cependant, UDP peut etre assez efficace grace a des reglages
specifiques lorsque le MTU du reseau depasse la taille de transfert de
donnees de NFS (par exemple dans les environnements reseau qui
utilisent les trames Ethernet Jumbo). Dans ces cas, il est judicieux
d'adapter les reglages rsize et wsize de facon a ce que chaque requete
de lecture ou d'ecriture NFS soit contenue dans quelques trames du
reseau (voire meme dans une seule trame). Cela reduit la probabilite
qu'une perte d'une simple trame reseau de la taille de la MTU entraine
la perte complete d'un grande requete en lecture ou ecriture.
TCP est le protocole de transport utilise par defaut dans toutes les
implementations modernes de NFS. Il est efficace dans pratiquement tous
les environnements reseau concevables et offre d'excellentes garanties
contre la corruption de donnees que pourrait entrainer un incident
reseau. TCP est souvent requis pour acceder a un serveur a travers un
pare-feu.
Dans des conditions normales, les reseaux rejettent des paquets bien
plus souvent que les serveurs NFS ne rejettent de requetes. C'est
pourquoi un reglage agressif de delai de depassement (<< time-out >>)
de retransmission pour NFS sur TCP est inutile. Les reglages habituels
de delai de depassement pour NFS sur TCP varient entre une et dix
minutes. Apres qu'un client a termine ses retransmissions (la valeur de
l'option retrans de mount), il considere que le reseau a subi une panne
et tente de se reconnecter au serveur grace a une nouvelle interface de
connexion (<< socket >>). Puisque TCP fiabilise le transport de donnees
sur le reseau, rsize et wsize peuvent en toute securite permettre par
defaut la plus grande valeur geree a la fois par le client et par le
serveur, independamment de la taille du MTU du reseau.
Utilisation de l'option de montage mountproto
Cette section s'applique uniquement aux versions 2 et 3 du protocole
mount car NFS 4 n'utilise pas un protocole de montage separe.
Le client Linux peut utiliser differents modes de transfert pour
contacter le service rpcbind d'un serveur, son service mountd, son
gestionnaire de verrou reseau (NLM) et son service NFS. Le mode de
transport utilise par le client NFS de Linux pour chaque point de
montage depend des options passees a mount, qui incluent proto,
mountproto udp et tcp.
Le client envoie des notifications au gestionnaire reseau de statut
(NSM : << network status manager >>) via UDP, quel que soit le mode de
transfert precise. Il ecoute cependant les notifications NSM du serveur
a la fois sur UDP et TCP. Le protocole gerant la liste de controle
d'acces a NFS (NFACL : << nfs access control list >>) utilise le meme
mode de transfert que le service NFS principal.
Si aucune option n'est precisee quant au mode de transfert, le client
NFS Linux utilise UDP pour contacter le service mountd du server, et
TCP pour contacter ses services NLM et NFS par defaut.
Si le serveur ne gere pas ces modes de transfert pour ces services, la
commande mount(8) essaye de trouver quel mode est pris en charge par le
serveur, et essaye une fois de se reconnecter avec ce mode. Si le
serveur ne propose aucun mode gere par le client ou est mal configure,
la requete de montage echoue. Si l'option bg a ete passee, la commande
mount passe en arriere-plan et continue d'essayer la requete de montage
demandee.
Quand l'une des options proto, udp ou tcp est passee mais que
mountproto ne l'est pas, le mode de transfert demande est utilise a la
fois pour contacter le service mountd du serveur et ses services NLM et
NFS.
Si l'option mountproto est passee mais que ni proto, ni udp et ni tcp
n'est passee alors le mode demande est utilise pour la requete mount
initiale, mais la commande mount essaye de decouvrir quel mode de
transfert est pris en charge pour le protocole NFS, et preferera TCP si
les deux modes sont implementes.
Si mountproto et proto (ou udp ou tcp) sont passes en meme temps, le
mode de transport indique a l'option mountproto est utilise pour la
requete initiale de mountd, et le mode indique a proto (ou udp ou tcp)
est utilise pour NFS, quel que soit l'ordre de ces options. Le
programme ne cherchera pas a trouver les services si ces options sont
donnees.
Si l'une des options proto, udp, tcp ou mountproto est passee plus
d'une fois dans une meme commande, alors la valeur retenue sera celle
la plus a droite.
COH'ERENCE DES DONN'EES ET DES M'ETADONN'EES
Certains systemes de fichiers en grappes (cluster) recents offrent une
coherence absolue du cache a leurs clients. La coherence parfaite de
cache aux clients NFS << disparates >> est difficile a obtenir, surtout
sur les reseaux de grandes tailles (WAN). Dans ce cas, NFS est regle
pour la plus faible coherence de cache qui satisfait les contraintes de
la plupart des types de partage de fichiers. Habituellement, le partage
de fichiers est totalement sequentiel : le premier client A ouvre un
fichier, ecrit quelque chose dedans, puis le ferme. Ensuite, un client
B ouvre ce meme fichier, puis lit les modifications.
Coh'erence de cache << close-to-open >>
Quand une application ouvre un fichier stocke sur un serveur NFS, le
client NFS verifie qu'il existe toujours sur le serveur et que
l'utilisateur qui ouvre ce fichier en a bien le droit, grace a des
requetes GETATTR ou ACCESS. Quand l'application ferme le fichier, le
client NFS ecrit toutes les modifications en attente afin que le
prochain a ouvrir ce fichier puisse en voir les changements. Cela donne
l'opportunite au client NFS de prevenir l'application de toute erreur
en ecriture sur le serveur, via le code de retour de close(2). Ce
systeme de verification a l'ouverture et de purge a la fermeture est
connu sous le nom de coherence de cache << close-to-open >>
(close-to-open cache consistency).
Faible coh'erence de cache
Il y a toujours des cas dans lesquels le cache de donnees du client
contient des donnees incoherentes. Dans la version 3 du protocole NFS
est apparue la << faible coherence de cache >> (appelee aussi WCC),
offrant une methode efficace de verification des attributs d'un fichier
avant et apres une requete unique. Cela permet a un client une
meilleure perception des modifications qui ont pu etre realisees par
les autres clients.
Quand un client genere beaucoup d'operations concomitantes qui
modifient le meme fichier au meme moment (par exemple grace a des
ecritures asynchrones en arriere-plan), il est difficile de savoir si
le fichier a ete modifie par ce client ou par un autre.
M'emorisation (cache) des attributs
L'utilisation de l'option noac de mount permet de realiser la coherence
de la memorisation (cache) des attributs pour de multiples clients.
Pratiquement toutes les operations de systeme de fichiers verifient les
informations d'attributs de fichiers. Le client garde cette information
en memoire (cache) pendant un certain temps afin de reduire la charge
du serveur et du reseau. Quand noac est activee, le cache des attributs
de fichier est desactive sur le client et chaque operation qui doit
verifier les attributs des fichiers doit imperativement s'adresser au
serveur. Ceci permet au client de voir rapidement les modifications sur
un fichier, en contrepartie d'une augmentation importante des
operations reseaux.
Soyez attentif a ne pas confondre l'option noac avec << pas de
memorisation de donnees (no data caching) >>. L'option noac de mount
empeche la mise en cache par le client des metadonnees du fichier, mais
il existe toujours des cas dans lesquels des incoherences de donnees
cachees peuvent survenir entre le client et le serveur.
Le protocole NFS n'a pas ete concu pour gerer la coherence absolue des
caches pour des grappes (clusters) de systemes de fichiers sans qu'il
soit necessaire d'utiliser des types particuliers de serialisation au
niveau applicatif. Si la coherence absolue du cache est necessaire aux
clients, les applications devront utiliser le verrouillage de fichiers
(<< file locking >>). D'autre part, les applications pourront aussi
utiliser le drapeau O_DIRECT lors de l'ouverture des fichiers afin de
desactiver totalement la mise en cache des donnees.
Mettre en cache les entr'ees r'epertoires
Le client NFS Linux garde en cache les resultats d'une requete NFS
LOOKUP. Si la requete pointe sur un repertoire existant sur le serveur,
le resultat sera note positif. Sinon, si le repertoire n'existe pas
(c'est-a-dire si le serveur retourne ENOENT), le resultat sera note
n'egatif.
Afin de detecter l'ajout ou la suppression de repertoires sur le
serveur, le client NFS Linux regarde la date de modification
(<< mtime >>) du repertoire. Si le client detecte un changement dans
cette date, le client supprime tous les resultats LOOKUP encore en
cache concernant ce repertoire. Comme la date de modification est un
attribut conserve en cache, il est possible qu'un peu de temps se passe
avant que le client remarque le changement. Referez-vous aux
descriptions des options de montage acdirmin, acdirmax et noac pour
plus d'information quant a la maniere dont le temps de modification est
mis en cache.
Mettre en cache les entrees des repertoires ameliore les performances
des applications qui ne partagent pas de fichiers avec des applications
sur un autre client. L'utilisation d'informations en cache sur des
repertoires, cependant, peut interferer avec des applications qui
tournent simultanement sur de nombreux clients et qui doivent detecter
rapidement la creation ou la suppression de fichiers. L'option de
montage lookupcache permet de personnaliser certains comportements de
mise en cache de repertoires.
Avant la version 2.6.28 du noyau, le client NFS Linux cherchait
uniquement les resultats de recherches positifs. Cela permettait aux
applications de detecter rapidement de nouvelles entrees de repertoires
creees par d'autres clients, tout en fournissant une partie des
benefices dus a la mise en cache. Si une application depend de cet
ancien comportement, vous pouvez utiliser l'option
lookupcache=positive.
Si le client ignore son cache et valide toutes les requetes de
recherche avec le serveur, il peut alors detecter immediatement toute
creation ou suppression de repertoire par un autre client. Vous pouvez
forcer ce comportement avec l'option lookupcache=none. L'absence de
mise en cache des repertoires entraine une augmentation du nombre de
requetes NFS, et donc une perte de performances. Empecher la recherche
sur le cache devrait permettre une moindre perte au niveau des
performances que d'utiliser noac, et n'a aucun effet sur la maniere
dont le client NFS met en cache les attributs d'un fichier.
L'option de montage sync
Le client NFS gere l'option de montage sync differemment que d'autres
systemes de fichiers (consultez mount(8) pour une description generique
des options de montage sync et async). Si ni sync ni async ne sont
indiquees (ou si l'option async est indiquee), le client NFS retarde
l'envoi au serveur des ordres d'ecriture des applications jusqu'a ce
que l'un de ces evenements survienne :
La saturation en memoire entraine une demande de ressources
memoire au systeme.
Une application met a jour (<< flush >>) les donnees d'un
fichier de maniere explicite avec sync(2), msync(2) ou fsync(3).
Une application ferme un fichier avec close(2).
Le fichier est verrouille/deverrouille grace a fcntl(2).
Autrement dit, dans les conditions normales d'utilisation, des donnees
ecrites par une application peuvent ne pas apparaitre instantanement
sur le serveur qui heberge le fichier.
Si l'option sync est precisee pour un point de montage, tout appel
systeme qui ecrit des donnees dans des fichiers de ce point de montage
entraine la purge des donnees sur le serveur avant de revenir en espace
utilisateur (<< user space >>). Cela offre une meilleure coherence du
cache des donnees, mais a un impact certain sur les performances.
Les applications peuvent utiliser le drapeau d'ouverture O_SYNC afin
que les ecritures d'un fichier precis soient immediatement prises en
compte par le serveur, et ce sans l'utilisation de l'option sync de
mount.
Utilisation des verrous de fichiers avec NFS
Le Gestionnaire de Verrous Reseaux (NLM, Network Lock Manager) est un
protocole auxiliaire separe servant a gerer les verrous sur les
fichiers dans les versions 2 et 3 de NFS. Pour gerer la recuperation
des verrous apres le redemarrage d'un client ou du serveur, un second
protocole (connu sous le nom de protocole Network Status Manager) est
necessaire. Dans la version 4 de NFS, le verrouillage des fichiers est
directement implante dans le protocole NFS, et les protocoles NLM et
NSM ne sont plus utilises.
Dans la plupart des cas, les services NLM et NSM sont demarres
automatiquement et aucune configuration additionnelle n'est requise. La
configuration en noms de domaine completement definis (FQDN) de tous
les clients NFS est necessaire pour permettre aux serveurs NFS de
retrouver leurs clients, afin de les prevenir en cas de redemarrage.
NLM ne gere que l'annonce de verrouillage de fichiers. Pour verrouiller
les fichiers NFS, il faut utiliser fcntl(2) avec les commandes F_GETL
et F_SETL. Le client NFS convertit les verrous de fichiers obtenus
grace a flock(2) en annonces de verrouillage.
Lors du montage de serveurs ne gerant pas le protocole NLM ou lorsqu'on
monte un serveur NFS a travers un pare-feu qui bloque le port du
service NLM, il faut utiliser l'option nolock de mount. Le verrouillage
NLM doit etre desactive grace a l'option nolock lorsqu'on utilise NFS
pour monter /var, puisque /var contient les fichiers utilises par NLM
dans son implementation sous Linux.
L'utilisation de l'option nolock est parfois conseillee pour ameliorer
les performances d'une application proprietaire qui ne tourne que sur
un seul client mais qui utilise intensement les verrous de fichiers.
Les caract'eristiques du cache de la version 4 de NFS.
Le comportement du cache des donnees et des metadonnees des clients NFS
version 4 est identique a celui des precedentes versions. Toutefois, la
version 4 de NFS offre deux nouveaux dispositifs pour ameliorer le
comportement du cache : attributs de changement et d'el'egation de
fichier.
L'attribut de changement est un nouvel element des metadonnees de
fichiers et de repertoires NFS qui enregistre les modifications des
donnees. Il se substitue a l'utilisation de l'horodatage des
modifications et changements du fichier pour offrir aux clients la
validation du contenu de leur cache. Cependant, ces attributs de
changement ne sont pas lies a la gestion de l'horodatage ni sur le
client ni sur le serveur.
La d'el'egation de fichier est un contrat qui lie un client NFS version 4
et le serveur, offrant temporairement au client le traitement d'un
fichier comme s'il etait le seul a y acceder. Le serveur s'engage a
prevenir le client (grace a une requete de rappel, ou << callback >>)
si un autre client tente d'acceder a ce meme fichier. Une fois qu'un
fichier a ete delegue a un client, ce client peut memoriser (mettre en
cache) les donnees et les metadonnees de ce fichier de facon agressive
sans avoir a contacter le serveur.
Il y a deux types de delegations : lecture et 'ecriture. Une delegation
en lecture indique que le serveur avertira le client si d'autres
clients veulent ecrire dans ce fichier. Une delegation en 'ecriture
indique que le client sera prevenu des tentatives de lecture ou
d'ecriture.
Les serveurs offrent les delegations de fichier sitot qu'un fichier est
ouvert et peuvent annuler ces delegations n'importe quand des lors
qu'un autre client desire acceder a un fichier d'une maniere qui entre
en conflit avec les delegations deja attribuees. Les delegations de
repertoires ne sont pas gerees.
Afin de pouvoir gerer les alertes de delegations (<< delegation
callback >>), le serveur verifie le chemin retour vers le client au
moment du contact initial de celui-ci. Si le retour vers le client ne
peut pas etre etabli, le serveur n'attribue purement et simplement
aucune delegation a ce client.
CONSID'ERATIONS DE S'ECURIT'E.
Les serveurs NFS controlent l'acces aux donnees des fichiers, mais leur
offre de gestion de l'authentification des requetes NFS depend de leur
implementation des RPC. Les controles d'acces NFS traditionnels imitent
les controles d'acces binaires standards offerts par les systemes de
fichiers locaux. L'authentification RPC traditionnelle utilise un
nombre pour representer chaque utilisateur (normalement l'uid propre a
cet utilisateur), un nombre pour representer le groupe de cet
utilisateur (le gid de l'utilisateur) et un ensemble d'au maximum
16 nombres de groupes additionnels pour representer les groupes
auxquels cet utilisateur peut appartenir.
Traditionnellement, les donnees du fichier et l'ID de l'utilisateur ne
sont pas chiffrees sur le reseau (en clair). Qui plus est, les
versions 2 et 3 de NFS utilisent des protocoles auxiliaires separes
pour le montage, le verrouillage et le deverrouillage des fichiers, et
pour renvoyer les valeurs de retour systeme des clients et serveurs.
Ces protocoles auxiliaires n'utilisent pas d'authentification.
En plus d'avoir integre ces deux protocoles auxiliaires dans le
protocole NFS principal, la version 4 de NFS offre des formes plus
avancees de controle d'acces, d'authentification, et de protection lors
du transfert des donnees. La specification de la version 4 de NFS
requiert les ACLs NFSv4, l'authentification RPCGSS, et les diverses
securites RPCGSS permettant le controle d'integrite et le chiffrement
via RPC. Puisque la version 4 de NFS ajoute les fonctionnalites de ces
protocoles au coeur du protocole NFS, les nouvelles caracteristiques de
securite s'appliquent a toutes les operations de NFS version 4,
incluant donc le montage, le verrouillage des fichiers, et ainsi de
suite. L'authentification RPCGSS peut aussi etre utilisee avec les
versions 2 et 3 de NFS, mais ne protege pas les protocoles associes.
L'option de montage sec indique que le mode de securite RPCGSS est
actif sur ce point de montage NFS. L'ajout de sec=krb5 fournit la
preuve chiffree de l'identite de l'utilisateur pour chaque requete RPC.
Ce dispositif offre une verification forte de l'identite des
utilisateurs qui accedent aux donnees du serveur. Notez que des
configurations supplementaires a cet ajout de l'option de mount sont
necessaires pour activer la securite Kerberos. Consultez la page de
manuel de rpc.gssd(8) pour plus de details.
Deux dispositifs additionnels de la securite Kerberos sont pris en
charge : krb5i et krb5p. Le dispositif de securite krb5i offre une
garantie de chiffrement fort contre la falsification des donnees pour
chaque requete RPC. Le dispositif de securite krb5p chiffre chaque
requete RPC afin d'eviter qu'elle soit exposee pendant son transfert
sur le reseau. Toutefois, le chiffrement ou la verification de
l'integrite entrainent des baisses de performance. D'autres formes de
securite par chiffrement (telles que lipkey ou SPKM3) sont aussi prises
en charge.
Le protocole NFS version 4 permet aux clients et aux serveurs la
negociation de multiples dispositifs de securite lors du processus de
montage. Cependant, Linux n'implemente pas encore une telle
negociation. Le client Linux indique un seul dispositif de securite au
moment du montage qui restera ensuite actif pour toute la duree du
montage. Si le serveur ne gere pas ce dispositif, la requete de montage
initiale est refusee par le serveur.
Utiliser un port source non privil'egi'e
Le client NFS communique normalement avec le serveur par des tuyaux
reseaux (network sockets). A chaque bout du tuyau est associe un port,
qui est un simple nombre entre 1 et 65535, ce qui permet de distinguer
des tuyaux pointant sur la meme adresse IP. Un tuyau est identifie de
maniere unique par un n-uplet comprenant le protocole de passage (TCP
ou UDP) et les ports et adresses IP de chaque bout.
Le client NFS peut choisir n'importe quel port d'origine pour ses
tuyaux, mais il choisit en general un port privil'egi'e (c'est-a-dire
avec une valeur inferieure a 1024). Seul un processus tournant avec des
droits du superutilisateur peut creer un tuyau a partir d'un port
privilegie.
La fourchette des ports potentiellement choisis est configuree par une
paire de sysctls pour eviter l'utilisation de ports bien connus, tel
celui de SSH. Cela signifie que le nombre de ports source potentiels
pour le client NFS, et donc pour le nombre de connexions par tuyau
disponible a un moment donne est en pratique de l'ordre d'une centaine.
Comme decrit plus haut, le schema d'authentification NFS traditionnel
(connu sous le nom d'AUTH_SYS), compte sur l'envoi d'UID et de GID
locaux pour identifier les utilisateurs a l'origine de requetes. Un
serveur NFS suppose que si une connexion provient d'un port non
privilegie, les numeros UID et GID de la requete NFS ont deja ete
verifies par le noyau du client ou tout autre programme systeme local.
Ce systeme est facile a contourner, mais sur un reseau securise
d'ordinateurs de confiance, c'est parfaitement adapte.
En gros, un tuyau est utilise pour chaque point de montage NFS. Si un
client peut aussi utiliser un port source non privilegie, le nombre de
tuyaux autorises (et donc le nombre maximal de points de montages en
paralleles) sera beaucoup plus important.
Utiliser un port source non privilegie peut quelque peu compromettre la
securite du serveur, car n'importe quel utilisateur d'un point de
montage sur AUTH_SYS peut maintenant se faire passer pour un autre
comme source de la requete. C'est pourquoi les serveurs NFS ne le
prennent pas en charge par defaut. En regle generale, ils l'autorisent
explicitement a l'aide d'une option de partage.
Pour garder un bon niveau de securite tout en ouvrant un maximum de
points de montages, il est preferable d'autoriser les connexions
clients sur un port non privilegie seulement si le serveur et le client
utilisent tous deux une authentification forte, comme celle fournie par
Kerberos.
Montage `a travers un pare-feu
Un pare-feu peut se trouver entre un client NFS et le serveur, ou alors
le client ou le serveur peuvent bloquer certains de leurs propres ports
grace a des regles de filtrage IP. Il est toujours possible de monter
un serveur NFS a travers un pare-feu, bien que les mecanismes de
decouverte automatique des terminaisons d'acces (<< endpoints >>) de la
commande mount(8) peuvent ne pas fonctionner. Il vous faudra alors
fournir des details specifiques a ces terminaisons d'acces
(<< endpoints >>) grace aux options de mount.
Les serveurs NFS lancent habituellement un service (daemon) portmapper
ou rpcbind pour annoncer aux clients les terminaisons (endpoints) des
services. Les clients se servent du demon rpcbind pour determiner :
Le port reseau utilise par chaque service base sur les RPC
Le protocole de transport utilise par chaque service base sur
les RPC
Le demon rpcbind utilise un port bien connu (111) afin d'aider les
clients a trouver la terminaison (endpoint) d'un service. Bien que NFS
utilise souvent un numero de port standard (2049), des services
auxiliaires tels que NLM peuvent choisir au hasard des numeros de port
inutilises.
Les configurations habituelles des pare-feu bloquent le port bien connu
de rpcbind. En l'absence du service rpcbind, l'administrateur du
serveur definit un numero de port pour les services lies a NFS afin que
le pare-feu puisse permettre l'acces aux ports des services specifiques
NFS. Les administrateurs des clients pourront alors indiquer le numero
du port du service mountd grace a l'option mountport de la commande
mount(8). Il peut etre necessaire d'imposer l'utilisation de TCP ou
d'UDP si le pare-feu bloque l'un de ces transports.
D'esactiver le traitement des ACL (Access Control List).
Solaris permet aux clients NFS version 3 l'acces direct aux Access
Control Lists (ACL) POSIX stockes dans son systeme de fichiers local.
Ce protocole auxiliaire proprietaire, connu sous le nom de NFSACL,
offre un controle d'acces plus riche que le mode binaire. Linux
implemente ce protocole dans un but de compatibilite avec
l'implementation NFS de Solaris. Cependant, le protocole NFSACL n'est
jamais devenu une partie standard de la specification NFS version 3.
La specification de NFS version 4 impose une nouvelle version des
Access Control Lists qui sont semantiquement plus riches que les ACL
POSIX. Les ACL de NFS version 4 ne sont pas totalement compatibles avec
les ACL POSIX. De ce fait, des traductions entre les deux sont
obligatoires dans un environnement qui melange a la fois les ACL POSIX
et NFS version 4.
OPTION DE REMONTAGE
Les options de montage generique comme rw et sync peuvent etre
modifiees par les points de montage utilisant l'option remount. Voir
mount(8) pour plus d'information sur les options generiques de montage.
Sauf quelques exceptions, les options specifiques a NFS ne peuvent pas
etre modifiees pendant un remontage. Par example, le transport
sous-jacent ou la version NFS ne peuvent pas etre changes par un
remontage.
Effectuer un remontage sur un systeme de fichiers NFS monte avec
l'option noac peut avoir des consequences inattendues. L'option noac
est une combinaison de l'option generique sync et de l'option
specifique NFS actimeo=0.
D'emontage apr`es remontage
Pour les points de montage qui utilisent NFS versions 2 ou 3, la
sous-commande de demontage NFS depend de la connaissance de l'ensemble
initial des options de montage utilisees pour effectuer l'operation
MNT. Ces options sont stockees sur le disque par la sous-commande de
montage NFS, et peuvent etre effacees par un remontage.
Afin de s'assurer que les options de montage enregistrees ne sont pas
effacees lors d'un remontage, il faut specifier au remontage le
repertoire de montage local, ou le serveur hote et le chemin
d'exportation, mais pas les deux. Par exemple,
mount -o remount,ro /mnt
fusionne l'option de montage ro avec les options de montage deja
enregistrees sur le disque pour le serveur NFS monte dans /mnt.
FICHIERS
/etc/fstab Table des systemes de fichiers
BOGUES
Le client NFS anterieur a 2.4.7 ne gerait pas NFS sur TCP.
Le client NFS anterieur a 2.4.20 utilisait une heuristique pour savoir
si les donnees memorisees d'un fichier (en cache) etaient toujours
valides plutot qu'utiliser la methode standard de coherence de cache
close-to-open decrite ci-dessus.
Depuis la version 2.4.22, Le client NFS utilise une estimation RTT de
type Van Jacobsen pour definir les delais de depassement de temps
(timeout) lorsqu'il utilise NFS sur UDP.
Le client NFS Linux anterieur a 2.6.0 ne gerait pas NFS version 4.
Le client NFS anterieur a 2.6.8 n'utilisait les lectures et ecritures
synchrones que lorsque les reglages de rsize et wsize etaient
inferieurs a la taille des pages du systeme.
Le client NFS Linux ne prend toujours pas en charge certaines
caracteristiques optionnelles du protocole NFS version 4, telles que la
negociation de securite, les soumissions de serveurs et les attributs
nommes.
VOIR AUSSI
fstab(5), mount(8), umount(8), mount.nfs(5), umount.nfs(5), exports(5),
netconfig(5), ipv6(7), nfsd(8), sm-notify(8), rpc.statd(8),
rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)
RFC 768 concernant la specification UDP.
RFC 793 concernant la specification TCP.
RFC 1094 concernant la specification de NFS version 2.
RFC 1813 concernant la specification de NFS version 3.
RFC 1832 concernant la specification XDR.
RFC 1833 concernant la specification RPC bind.
RFC 2203 concernant la specification du protocole de l'API GSS RPCSEC.
RFC 3530 concernant la specification de NFS version 4.
TRADUCTION
Cette page de manuel a ete traduite et mise a jour par Christophe
Blaess entre 1997 et 2003. La version presente dans Debian est
maintenue par Sylvain Cherrier <sylvain DOT cherrier AT free DOT fr> et
les membres de la liste <debian-l10n-french AT lists DOT debian DOT
org>. Veuillez signaler toute erreur de traduction par un rapport de
bogue sur le paquet manpages-fr-extra.
2 novembre 2007 NFS(5)