NOM¶
nfs - Format de fstab et options pour les systèmes de fichiers
nfs
SYNOPSIS¶
/etc/fstab
DESCRIPTION¶
NFS est un protocole standard de l'Internet créé par Sun Microsystem
en 1984. NFS a été développé pour permettre le partage de
fichiers entre des systèmes connectés à un réseau local.
Le client NFS de Linux gère trois versions du protocole : NFS
version 2 [RFC1094], NFS version 3 [RFC1813], et NFS version 4
[RFC3530].
La commande
mount(8) lie un système de fichiers au point de montage
donné dans l'espace de noms hiérarchisé du système. Le
fichier
/etc/fstab décrit la façon dont
mount(8) doit
recréer la hiérarchie de l'espace de noms du système de
fichiers à partir de systèmes de fichiers indépendants (dont
ceux partagés par des serveurs NFS). Chacune des lignes du fichier
/etc/fstab décrit un unique système de fichiers, son point de
montage, et un ensemble d'options par défaut pour ce point de montage.
Dans le cas des montages de systèmes de fichiers NFS, une ligne dans le
fichier
/etc/fstab indique le nom du serveur, le chemin du
répertoire partagé à monter, le répertoire local qui sera
le point de montage, le type de système de fichiers à monter et la
liste des options de montage qui indique la façon dont le système de
fichiers sera monté et quel sera le comportement du client NFS lorsqu'il
accédera aux fichiers du point de montage. Le cinquième et le
sixième champs de chaque ligne ne sont pas utilisés par NFS, et par
conséquent contiennent par convention la valeur zéro. Par
exemple :
serv:chemin /pt_montage type_fs option,option,... 0 0
Le nom du serveur et le chemin de partage sont séparés par un deux
points, tandis que les options de montage sont séparées par des
virgules. Les champs restants sont séparés par des espaces ou des
tabulations.
Le nom du serveur peut être un nom d'hôte non qualifié, un nom de
domaine pleinement qualifié (« fully qualified domain
name »), une adresse IPv4, ou une adresse IPv6 entourée par des
crochets. Les adresses IPv6 de liens locaux ou de sites locaux doivent
être accompagnées d'un identifiant d'interface.
Référez-vous à
ipv6(7) pour des détails quant
à l'écriture des adresse IPv6 brutes.
Le champ
fstype contient « nfs ». La valeur
« nfs4 » est obsolète.
OPTIONS DE MONTAGE¶
Consultez
mount(8) pour la description des options de montage
génériques disponibles pour tous les systèmes de fichiers. Si
vous n'avez pas besoin d'indiquer d'options de montage particulières,
utilisez l'option générique
defaults dans
/etc/fstab.
Options prises en charge par toutes les versions¶
Les options suivantes peuvent être utilisées avec n'importe quelle
version de NFS.
- soft / hard
- Définir le comportement de récupération du
client NFS lorsqu'une requête NFS ne répond pas
(« time out »). Si aucune option n'est indiquée
(ou si c'est l'option hard qui a été choisie), les
requêtes NFS sont retentées indéfiniment. Si par contre
l'option soft a été choisie, le client NFS lèvera un
échec après l'envoi de retrans retransmissions,
entraînant alors le retour d'une erreur à l'application
appelante.
- NB : Un délai expiré
« soft » peut provoquer dans certains cas des erreurs
de données non signalées. C'est pourquoi l'option soft
doit être utilisée uniquement si la réactivité du
client est plus importante que l'intégrité des données.
L'utilisation de NFS avec TCP ou l'augmentation de la valeur de l'option
retrans peut diminuer les risques liés à l'utilisation de
l'option soft.
- timeo=n
- Le temps en dixièmes de seconde où le client NFS
attend une réponse avant qu'il réessaie une requête
NFS.
- Pour NFS sur TCP, la valeur timeo est de 600
par défaut (60 secondes). Le client NFS effectue une progression
linéaire : après chaque retransmission la temporisation est
augmentée de timeo jusqu'au maximum de 600 secondes.
- Cependant, dans le cas de NFS sur UDP, le client utilise un
algorithme évolutif pour estimer la valeur appropriée de
dépassement de temps (« timeout ») pour les types
de requêtes fréquemment utilisées (les requêtes READ
et WRITE par exemple), mais utilise le réglage timeo pour les
requêtes moins courantes (comme FSINFO). Si l'option timeo
n'est pas définie, les types de requêtes moins courantes sont
ré-émises après 1,1 secondes. Après chaque
ré-émission, le client NFS double la valeur de dépassement
de temps pour cette requête, jusqu'à atteindre un maximum de
60 secondes.
- retrans=n
- Nombre de tentatives de ré-émission de la
requête avant que le client NFS n'enclenche une action de
récupération. Si l'option retrans n'est pas définie,
le client NFS essaye chaque requête trois fois.
- Le client NFS génère un message « le
serveur ne répond pas » après retrans
tentatives, puis enclenche la récupération (qui dépend de
l'activation de l'option hard de mount).
- rsize=n
- Nombre maximal d'octets pour chaque requête
réseau en LECTURE que peut recevoir le client NFS lorsqu'il lit les
données d'un fichier sur le serveur NFS. La taille réelle de la
charge utile de données pour chaque requête NFS en LECTURE est
plus petite ou égale au réglage rsize. La plus grande
charge utile gérée par le client NFS Linux est de
1 048 576 octets (un méga-octet).
- La valeur de rsize est un entier positif multiple de
1024. Les valeurs de rsize inférieures à 1024 sont
remplacées par 4096, et celles supérieures à
1 048 576 sont remplacées par 1 048 576. Si la
valeur indiquée est bien dans la plage gérée, mais qu'elle
n'est pas un multiple de 1024, elle sera arrondie au multiple de 1024
inférieur le plus proche.
- Si la valeur de rsize n'est pas définie, ou si
la valeur de rsize dépasse le maximum qu'à la fois le
client et le serveur peuvent gérer, le client et le serveur
négocient la plus grande valeur de rsize qu'ils puissent
gérer ensemble.
- L'option rsize de mount telle qu'elle a
été définie sur la ligne de commande lors du
mount(8) apparaît dans le fichier /etc/mtab. D'autre
part, la valeur réelle de rsize négociée entre le
client et le serveur est indiquée dans le fichier
/proc/mounts.
- wsize=n
- Nombre maximal d'octets par requête d'ÉCRITURE
réseau que le client NFS peut envoyer quand il écrit des
données dans un fichier sur un serveur NFS. La taille réelle de
la charge utile de données pour chaque requête NFS en
ÉCRITURE est plus petite ou égale au réglage wsize.
La plus grande charge utile gérée par le client NFS Linux est de
1 048 576 octets (un méga-octet).
- Comme pour rsize, la valeur de wsize est un
entier positif multiple de 1024. Les valeurs de wsize
inférieures à 1024 sont remplacées par 4096, et celles
supérieures à 1 048 576 par 1 048 576. Si la
valeur définie est bien dans l'étendue valide mais qu'elle n'est
pas multiple de 1024, elle est arrondie au multiple de 1024 inférieur
le plus proche.
- Si la valeur de wsize n'est pas définie, ou si
la valeur wsize indiquée est supérieure au maximum que
soit le client soit le serveur peut gérer, le client et le serveur
négocient la plus grande valeur de wsize qu'ils peuvent tous
les deux gérer.
- L'option wsize de mount telle qu'elle a
été indiquée sur la ligne de commande du mount(8)
apparaît dans le fichier /etc/mtab. D'autre part, la valeur
réelle de wsize négociée par le client et le serveur
est indiquée dans le fichier /proc/mounts.
- ac / noac
- Définir si le client peut mémoriser (cache) les
attributs des fichiers. Si aucune option n'est indiquée (ou si c'est
ac qui est choisi), le client mémorise les attributs des
fichiers.
- Afin d'améliorer les performances, les clients NFS
mémorisent (mettent en cache) les attributs des fichiers. Toutes les
quelques secondes, un client NFS vérifie les attributs de chaque
fichier de la version du serveur afin de se mettre à jour. Les
modifications qui interviennent pendant ces petits intervalles restent
inaperçues tant que le client n'a pas relancé sa
vérification sur le serveur. L'option noac empêche la
mémorisation des attributs de fichiers par le client, ce qui permet
aux applications de détecter plus rapidement les modifications des
fichiers sur le serveur.
- En plus d'empêcher le client de mémoriser les
attributs des fichiers, l'option noac force l'écriture
synchronisée pour les applications afin que les modifications sur un
fichier soient immédiatement visibles sur le serveur. De cette
façon, les autres clients peuvent rapidement détecter les
nouvelles écritures lors de la vérification des attributs du
fichier.
- L'usage de l'option noac offre une plus grande
cohérence du cache aux clients NFS qui accèdent aux mêmes
fichiers, mais au prix d'une pénalisation significative des
performances. C'est pour cette raison qu'une utilisation judicieuse des
verrouillages (« locking ») de fichiers est
préférable. La section COHÉRENCE DES DONNÉES ET DES
MÉTADONNÉES contient une présentation
détaillée de ces approches.
- acregmin=n
- Durée minimale (en seconde) de mémorisation
(cache) des attributs d'un fichier normal avant leur actualisation depuis
le serveur. La valeur par défaut est de 3 secondes, si cette
option n'est pas définie.
- acregmax=n
- Durée maximale (en seconde) de mémorisation
(cache) des attributs d'un fichier normal avant leur actualisation depuis
le serveur. La valeur par défaut est de 60 secondes, si cette
option n'est pas définie.
- acdirmin=n
- Durée minimale (en seconde) de mémorisation
(cache) des attributs d'un répertoire avant leur actualisation depuis
le serveur. La valeur par défaut est de 30 secondes, si cette
option n'est pas définie.
- acdirmax=n
- Durée maximale (en seconde) de mémorisation
(cache) des attributs d'un répertoire avant leur actualisation depuis
le serveur. La valeur par défaut est de 60 secondes, si cette
option n'est pas définie.
- actimeo=n
- L'utilisation de actimeo configure toutes les
durées acregmin, acregmax, acdirmin et
bacdirmax à la même valeur. Si cette option n'est pas
définie, le client utilisera les valeurs par défaut de chacune
des options, telles que décrites ci-dessus.
- bg / fg
- Déterminer le comportement de la commande
mount(8) dans le cas d'un échec d'une tentative de montage
d'un partage. L'option fg entraîne l'arrêt de
mount(8) avec un statut d'erreur si la moindre partie de la
requête de montage dépasse le temps alloué ou échoue
d'une quelconque autre manière. C'est ce que l'on appelle le montage
en « premier plan (foreground) », et c'est le
comportement par défaut si ni fg ni bg n'est
indiqué.
- Si l'option bg est indiquée, un
dépassement du temps alloué (timeout) ou un échec
entraînera la création d'un fils (fork) qui continuera à
essayer de monter le partage. Le père s'interrompt immédiatement
en renvoyant un code de sortie à zéro. C'est ce que l'on appelle
le montage en « arrière-plan (background) ».
- Si le répertoire servant de point de montage local
n'existe pas, la commande mount(8) se comporte comme si la
requête était restée sans réponse (timeout). Cela
permet aux montages NFS imbriqués définis dans /etc/fstab
de s'exécuter dans n'importe quel ordre lors de l'initialisation du
système, même si certains serveurs NFS ne sont pas encore
disponibles. On peut aussi gérer ces problèmes grâce à
un auto-monteur (consultez automount(8) pour plus de
détails).
- retry=n
- Durée, en minute, pendant laquelle le montage NFS sera
tenté par la commande mount(8), en arrière-plan ou au
premier plan, avant d'abandonner. Si l'option n'est pas définie, la
valeur par défaut pour le premier plan est de 2 minutes, et
celle pour l'arrière-plan est 10 000 minutes, soit environ
une semaine, à 80 minutes près. La commande mount(8)
s'arrêtera dès le premier échec si on lui passe la valeur
0.
- sec=mode
- Le type de sécurité RPCGSS à utiliser pour
accéder aux fichiers de ce point de montage. Si l'option sec
n'est pas définie, ou si sec=sys est choisie, le client NFS
utilise le type de sécurité AUTH_SYS pour toute requête NFS
sur ce point de montage. Les types de sécurité gérés
sont none, sys, krb5, krb5i et krb5p.
Consultez la section CONSIDÉRATIONS DE
SÉCURITÉ.
- sharecache / nosharecache
- Déterminer comment le client partage ses caches de
données et d'attributs de fichiers lorsqu'un même partage est
monté plus d'une fois en même temps. L'utilisation d'un seul
cache réduit les besoins en mémoire sur le client et
présente aux applications un contenu identique lorsque le même
fichier partagé est accédé via différents points de
montage.
- Si aucune des options n'est indiquée, ou si l'option
sharecache est demandée, un seul cache est utilisé pour
tous les points de montage qui accèdent au même partage. Si
l'option nosharecache est indiquée, ce point de montage
utilise son propre cache. Notez que lorsque les caches des données et
des attributs sont partagés, les options de montage du premier point
de montage s'appliquent pour les futurs montages de ce même partage,
tant que celui-ci est monté.
- En ce qui concerne le noyau 2.6.18, le comportement
défini par nosharecache est le comportement historique normal.
Ceci est considéré comme dangereux pour les données puisque
de multiples copies mémorisées du même fichier sur le
même client peuvent se désynchroniser suite à une mise
à jour locale d'une des copies.
- resvport / noresvport
- Indiquer si le client NFS doit utiliser un port source
privilégié quand il communique avec un serveur NFS pour ce point
de montage. Si cette option n'est pas précisée, ou si l'option
resvport est précisée, le client NFS utilise un port
source privilégié. Si l'option noresvport est
activée, le client NFS utilise un port source non
privilégié. Cette option est permise par les noyaux 2.6.28 et
suivants.
- Utiliser un port source non privilégié permet
d'augmenter le nombre maximal de points de montages permis par client,
mais les serveurs NFS doivent être configurés pour permettre la
connexion de clients par des ports source non privilégiés.
- Veuillez consulter la section CONSIDÉRATIONS DE
SÉCURITÉ pour d'importantes précisions.
- lookupcache=mode
- Préciser comment le noyau s'occupe du cache des
entrées de répertoire pour un point de montage donné.
mode peut être 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 résultats
des requêtes NFS LOOKUP. Si le répertoire indiqué existe
sur le serveur, le résultat renvoyé est positif
(« positive »), sinon c'est négatif
(« negative »).
- Si cette option n'est pas précisée, ou si
all est précisé, le client suppose que les deux types
d'entrées ( positif ou négatif) du cache de
répertoire sont valables jusqu'à ce que le cache de leur
répertoire parent expire.
- Si pos ou positive est précisé, le
client suppose que les entrées positives sont valables jusqu'à
ce que le cache de leur répertoire parent expire, mais valide les
entrées négatives avant qu'une application les utilise.
- Si none est précisé, le client valide
à nouveau les deux types d'entrées de cache de répertoire
avant qu'une application puisse les utiliser. Cela permet une
détection rapide des fichiers qui ont été créés
ou supprimés par d'autres clients, mais peut avoir des
répercussions sur ces applications et les performances du
serveur.
- La partie COHÉRENCE DES DONNÉES ET DES
MÉTADONNÉES contient un propos détaillé sur ces
échanges.
Options pour les versions NFS 2 et 3 uniquement¶
Utilisez ces options ainsi que les options de la sous-section
précédente uniquement pour les systèmes 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 requêtes au serveur NFS pour ce
point de montage. Si un serveur NFS a en même temps une adresse IPv4
et une IPv6, l'utilisation d'un identifiant réseau idreseau
entraînera le choix d'IPv4 ou d'IPv6 pour communiquer avec ce
serveur.
- Si la prise en charge de TI-RPC est compilée dans la
commande mount.nfs, netid doit être un identifiant
réseau valable présent dans le fichier /etc/netconfig. On
peut fournir une valeur à « rdma ». Si la
commande mount.nfs ne gère pas TI-RPC, netid doit
valoir « tcp », « udp » ou
« rdma », et on utilisera alors uniquement une adresse
IPv4.
- Chaque protocole de transport utilise différents
réglages de retransmission et de timeo. Merci de vous
référer à la description de ces deux options de
montage
- En plus de contrôler la façon dont le client NFS
transmet les requêtes au serveur, cette option de mount gère
aussi la façon dont la commande mount(8) communique avec les
services rpcbind et mountd du serveur. Indiquer un id réseau qui
utilise TCP entraîne l'utilisation de TCP par tout le trafic passant
par la commande mount(8) ou le client NFS. Réciproquement,
indiquer UDP entraîne l'utilisation d'UDP par tout le trafic.
- avant d'utiliser NFS sur UDP, consultez la section
MÉTHODES DE TRANSPORT.
- Si l'option proto de mount n'est pas
définie, la commande mount(8) découvrira quels protocoles
sont acceptés par le serveur et choisira un transport approprié
pour chacun des services. Consultez la section MÉTHODES DE
TRANSPORT pour plus de détails.
- udp
- L'option udp est une variante pour proto=udp,
compatible avec d'autres systèmes d'exploitation.
- avant d'utiliser NFS sur UDP, consultez la section
MÉTHODES DE TRANSPORT.
- tcp
- L'option tcp est une variante pour proto=tcp,
compatible avec d'autres systèmes d'exploitation.
- rdma
- L'option rdma est une variante pour
proto=rdma.
- port=n
- Valeur numérique du port du service NFS sur le
serveur. Si le service NFS du serveur n'est pas accessible sur le port
indiqué, la requête de montage échoue.
- Si cette option n'est pas définie, ou si le port
indiqué est 0, le client NFS utilise le numéro du port du
service NFS publié par le service rpcbind du serveur. La requête
de montage échoue si le service rpcbind du serveur n'est pas
accessible, si le service NFS du serveur n'est pas enregistré dans
son service rpcbind, ou si le service NFS du serveur n'est pas accessible
sur le port publié.
- mountport=n
- Valeur numérique du port de mountd sur le serveur. Si
le service mountd du serveur n'est pas présent sur le port
indiqué, la requête de montage échoue.
- Si cette option n'est pas définie, ou si le port
indiqué est 0, la commande mount(8) utilise le numéro du
port du service mountd publié par le service rpcbind du serveur. La
requête de montage échoue si le service rpcbind du serveur n'est
pas accessible, si le service mountd du serveur n'est pas enregistré
dans son service rpcbind, ou si le service mountd du serveur n'est pas
accessible sur le port publié.
- Cette option peut être utilisée pour les montages
sur un serveur NFS à 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 requêtes au service mountd
d'un serveur NFS quand il lance cette requête de montage, puis quand
il démontera ensuite ce montage.
- Si la prise en charge pour TI-RPC est compilée dans la
commande mount.nfs, idreseau peut être un identifiant
réseau valide parmi ceux listés dans /etc/netconfig.
Sinon, idreseau doit valoir « tcp » ou
« udp », et IPv4 sera utilisé.
- Cette option peut être utilisée pour monter un
serveur NFS à travers un pare-feu qui bloque des transferts
spécifiques. Utilisé avec l'option proto, différents
modes de transfert peuvent être choisis pour les requêtes vers
mountd et NFS. Si le serveur ne propose pas de service pour le mode
indiqué, la requête de montage échoue.
- Veuillez consulter la section MÉTHODES DE
TRANSPORT pour plus de renseignements sur la manière dont
l'option de montage mountproto interagit avec l'option
proto.
- mounthost=nom
- Le nom d'hôte de la machine qui exécute le
mountd. Si cette option n'est pas définie, la commande
mount(8) considère que le service mountd est assuré par
la machine qui offre le service NFS.
- mountvers=n
- Numéro de version des RPC utilisé pour contacter
le mountd du serveur. Si cette option n'est pas définie, le client
utilise un numéro de version approprié à la version du NFS
contacté. Cette option est utile quand de nombreux services NFS sont
offerts par un seul et même serveur.
- namlen=n
- La taille maximale d'un composant du nom de chemin ce
montage. Si cette option n'est pas définie, la taille maximale est
négociée avec le serveur. Dans la plupart des cas, cette taille
maximale est 255 caractères.
- Des versions précédentes de NFS ne gèrent
pas cette négociation. L'utilisation de cette option garantit que
pathconf(3) donnera bien la longueur maximale aux applications pour
ces versions.
- nfsvers=n
- Le numéro de version du protocole NFS utilisé
pour contacter le service NFS du serveur. Si le serveur ne gère pas
la version demandée, la requête de montage échoue. Si cette
option n'est pas définie, le client tente de trouver une version
adaptée 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 systèmes 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
indiquée (ou si c'est lock qui est choisi), le verrouillage
NLM est activé pour ce point de montage. Si on utilise l'option
nolock, les applications peuvent verrouiller les fichiers, mais ces
verrous n'ont de portée que pour les applications qui tournent sur ce
même client. Les applications distantes ne sont pas informées de
ces verrous.
- Le verrouillage NLM doit être désactivé lors
de l'utilisation de l'option nolock si /var est monté
via NFS, parce que /var contient des fichiers utilisés par
l'implémentation de NLM sous Linux. L'usage de nolock est
aussi requis lors des montages de partages de serveurs NFS ne gérant
pas le protocole NLM.
- intr / nointr
- Indiquer si les signaux peuvent interrompre les
opérations sur le fichier pour ce point de montage. Si aucune option
n'est indiquée (ou si nointr est choisi), les signaux
n'interrompent pas les opérations NFS sur les fichiers. Si
intr est indiqué, les appels systèmes renvoient EINTR si
une opération NFS en cours est interrompue par un signal.
- L'utilisation de l'option intr est
préférable à celle de l'option soft car le risque de
corruption des données est moins important.
- Les options de montage intr/ nointr sont
obsolètes pour des noyaux ultérieurs au 2.6.25. Seul un signal
de terminaison SIGKILL peut interrompre une opération NFS en cours
sur ces noyaux, et, si précisée, cette option est ignorée
pour assurer une compatibilité ascendante sur des anciens
noyaux.
- cto / nocto
- Indiquer s'il faut utiliser la sémantique de
cohérence de cache close-to-open. Si aucune option n'est
indiquée (ou si c'est cto qui est choisi), le client utilise
la sémantique de cohérence 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 changé sur le
serveur.
- L'utilisation de l'option nocto peut améliorer
les performances des montages en lecture seule, mais devrait être
limitée au cas où les données sur le serveur ne changent
qu'occasionnellement. La section COHÉRENCE DES DONNÉES
ET DES MÉTADONNÉES expose le comportement de cette option en
détails.
- acl / noacl
- Indiquer s'il faut utiliser le protocole auxiliaire NFSACL
sur ce point de montage. Le protocole auxiliaire NFSACL est un protocole
propriétaire mis en œuvre dans Solaris et qui gère les
listes de contrôle d'accès (les ACLs). NSFACL n'est jamais
devenu un élément standard de la spécification du protocole
NFS.
- Si ni acl ni noacl ne sont
précisées, le client NFS négocie avec le serveur afin de
savoir si le protocole NFSACL est actif, et l'utilise dans ce cas. La
désactivation du protocole auxiliaire NFSACL est parfois rendue
nécessaire quand la négociation pose des problèmes sur le
client ou sur le serveur. Consultez la section CONSIDÉRATIONS DE
SÉCURITÉ pour plus de détails.
- rdirplus / nordirplus
- Indiquer s'il faut utiliser les requêtes READDIRPLUS
de NFS version 3. Si cette option n'est pas définie, le client
NFS utilisera les requêtes READDIRPLUS sur les montages en NFS
version 3 pour la lecture des petits répertoires. Certaines
applications sont plus efficaces si le client n'utilise que des
requêtes READDIR pour tous les répertoires.
- local_lock=mécanisme
- Précise si le verrouillage local doit être
utilisé pour les mécanismes flock, POSIX, ou les deux.
mechanism peut être 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 portée que pour les applications qui tournent sur ce
même client. Les applications distantes ne sont pas informées de
ces verrous.
- Si cette option n'est pas précisée, ou si
none est précisé, le client suppose que les verrous ne
sont pas locaux.
- Si all est spécifié, le client suppose que
les deux types de verrous flock et POSIX sont locaux.
- Si flock est spécifié, le client suppose
que seuls les verrous flock sont locaux, et utilise le protocole NLM
associé pour verrouiller les fichiers quand les verrous POSIX sont
utilisés.
- Si posix est spécifié, le client suppose
que les verrous POSIX sont locaux, et utilise le protocole NLM
associé pour verrouiller les fichiers quand les verrous flock sont
utilisés.
- Pour supporter le comportement flock de façon
semblable à 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 partagé en mode
verrouillé flock. Puisque les clients NFS > 2.6.12 utilise flock
en émulant les verrous POSIX, il y aura un conflit de verrous.
- NOTE : Quand elles sont utilisées ensemble,
l'option de montage 'local_lock' sera écrasée par l'option de
montage 'nolock'/'lock'.
Options pour NFS version 4 uniquement¶
Utilisez ces options ainsi que les options de la première sous-section
ci-dessus pour les systèmes de fichiers de type NFS version 4 et
plus récents.
- proto=idreseau
- Le nom et la famille du protocole de transport qu'utilise
le client NFS pour transmettre ses requêtes au serveur NFS pour ce
point de montage. Si un serveur NFS a en même temps une adresse IPv4
et une IPv6, l'utilisation d'un identifiant réseau idreseau
entraînera le choix d'IPv4 ou d'IPv6 pour communiquer avec ce
serveur.
- Si la prise en charge pour TI-RPC est compilée dans la
commande mount.nfs, idreseau peut être un identifiant
réseau valide parmi ceux listés dans /etc/netconfig.
Sinon, idreseau doit valoir « tcp » ou
« udp », et IPv4 sera utilisé.
- Les serveurs NFS version 4 doivent prendre en charge
TCP, donc si cette option n'est pas précisée, le client NFS
utilise le protocole TCP. Veuillez vous référer à la
section MÉTHODES DE TRANSPORT pour plus de détails.
- port=n
- Valeur numérique du port du service NFS sur le
serveur. Si le service NFS du serveur n'est pas accessible sur le port
indiqué, la requête de montage échoue.
- Si cette option de montage n'est pas définie, le
client NFS utilisera le numéro de port standard de NFS (2049) sans
vérifier de prime abord le service rpcbind du serveur. Cette option
permet à un client NFS version 4 de contacter un serveur NFS
version 4 à travers un pare-feu qui bloquerait les requêtes
rpcbind.
- Si la valeur du port indiquée est 0, le client NFS
utilisera le numéro de port du service NFS publié par le service
rpcbind du serveur. La requête de montage échouera si le service
rpcbind du serveur n'est pas disponible, si le service NFS du serveur
n'est pas enregistré dans son service rpcbind, ou si le service NFS
du serveur n'est pas accessible sur le port publié.
- intr / nointr
- Indiquer si les signaux peuvent interrompre les
opérations sur les fichiers pour ce point de montage. Si aucune
option n'est indiquée (ou si intr est choisi), les appels
systèmes renvoient EINTR si une opération NFS en cours est
interrompue par un signal. Si nointr est indiqué, les signaux
n'interrompent pas les opérations NFS.
- L'utilisation de l'option intr est
préférable à celle de l'option soft car le risque de
corruption des données est moins important.
- Les options de montage intr/ nointr sont
obsolètes pour des noyaux ultérieurs au 2.6.25. Seul un signal
de terminaison SIGKILL peut interrompre une opération NFS en cours
sur ces noyaux, et, si précisée, cette option est ignorée
pour assurer une compatibilité ascendante sur des anciens
noyaux.
- cto / nocto
- Indiquer s'il faut utiliser la sémantique de
cohérence du cache close-to-open pour les répertoires NFS de ce
point de montage. Si ni cto ni nocto ne sont indiquées,
la sémantique de cohérence du cache close-to-open sera
utilisée par défaut pour les répertoires.
- La politique de mise en cache des données des fichiers
n'est pas concernée par cette option. La section COHÉRENCE
DES DONNÉES ET DES MÉTADONNÉES décrit le
comportement de cette option en détails.
- clientaddr=n.n.n.n
- Indiquer une seule adresse IPv4 en quatre parties
séparées 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 requêtes NFSv4 de rappel sur les fichiers de ce point de montage.
Si le serveur ne peut pas établir de connexion de rappel
(« callback ») sur ces clients, les performances
peuvent être dégradées ou les accès à ces
fichiers temporairement suspendus.
- Si cette option n'est pas indiquée, la commande
mount(8) essaie de découvrir automatiquement une adresse de
rappel (« callback ») appropriée. La
procédure de découverte automatique n'est cependant pas
parfaite. Dans le cas d'interfaces réseau multiples, de directives de
routages spéciales ou de typologie réseau atypique, l'adresse
exacte à utiliser pour les rappels peut ne pas être triviale
à déterminer.
SYSTÈME DE FICHIERS DE TYPE nfs4¶
Le type
nfs4 de système de fichiers est une ancienne syntaxe
précisant l'utilisation de NFSv4. Il peut toujours être utilisé
avec toutes les options spécifiques à NFSv4, à l'exception de
l'option de montage
nfsvers
FICHIER DE CONFIGURATION DU MONTAGE¶
Si la commande de montage est configurée pour, toutes les options de
montage décrites dans la section précédente peuvent être
configurées dans le fichier
/etc/nfsmount.conf.
Référez-vous à
nfsmount.conf(5) pour plus de
détails.
EXEMPLES¶
Pour réaliser le montage d'un partage en NFS version 2, il faut
préciser que le type du système de fichiers est
nfs et
indiquer l'option de montage
nfsvers=2. Pour réaliser un montage
en NFS version 3, il faut préciser que le type du système de
fichiers est
nfs et indiquer l'option de montage
nfsvers=3. Pour
réaliser un montage en NFS version 4, il faut préciser que le
type du système de fichiers est
nfs, avec l'option de montage
nfsver=4, ou demander le système de fichiers
nfs4.
L'exemple de fichier
/etc/fstab qui suit permet à la commande mount
de négocier des valeurs par défaut 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 réaliser un montage NFS version 4 en TCP,
utilisant l'authentification réciproque de Kerberos 5.
serveur:/export /mnt nfs4 sec=krb5 0 0
Cet exemple peut servir à réaliser le montage de /usr grâce
à 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ÉTHODES DE TRANSPORT.¶
Les clients NFS envoient leurs requêtes aux serveurs NFS grâce aux
appels de procédures distantes (« Remote Procedure
Calls »), les
RPCs. Le client RPC découvre
automatiquement les entrées du service distant, gère
l'authentification requête par requête, ajuste les paramètres
des requêtes afin de gérer l'ordre des octets sur le client et le
serveur (« endianess »), et se charge de la retransmission
des requêtes qui pourraient s'être perdues dans le réseau ou
sur le serveur. Les requêtes et les réponses RPC circulent sur un
protocole de transport réseau.
Dans la plupart des cas, la commande
mount(8), le client NFS et le
serveur NFS peuvent négocier automatiquement les valeurs adéquates
de taille pour les transferts de données et de transport pour un point de
montage. Cependant, dans certains cas, il peut être efficace d'indiquer
explicitement ces valeurs grâce aux options de montage.
Anciennement, les clients NFS se servaient uniquement du transport UDP pour
transmettre des requêtes aux serveurs. Bien que son implémentation
soit simple, NFS sur UDP a de nombreuses limitations qui l'empêchent
d'obtenir de bonnes performances et un fonctionnement fluide dans certains
environnements de déploiement courants. Un taux de paquets perdus
même insignifiant entraîne la perte de requêtes NFS
complètes. On règle alors généralement le délai de
dépassement (« timeout ») à une valeur
inférieure à la seconde afin que les clients puissent
récupérer rapidement en cas de requêtes rejetées. Cela
peut entraîner une surcharge du trafic réseau et du serveur.
Cependant, UDP peut être assez efficace grâce à des réglages
spécifiques lorsque le MTU du réseau dépasse la taille de
transfert de données de NFS (par exemple dans les environnements
réseau qui utilisent les trames Ethernet Jumbo). Dans ces cas, il est
judicieux d'adapter les réglages
rsize et
wsize de
façon à ce que chaque requête de lecture ou d'écriture NFS
soit contenue dans quelques trames du réseau (voire même dans une
seule trame). Cela réduit la probabilité qu'une perte d'une simple
trame réseau de la taille de la MTU entraîne la perte complète
d'un grande requête en lecture ou écriture.
TCP est le protocole de transport utilisé par défaut dans toutes les
implémentations modernes de NFS. Il est efficace dans pratiquement tous
les environnements réseau concevables et offre d'excellentes garanties
contre la corruption de données que pourrait entraîner un incident
réseau. TCP est souvent requis pour accéder à un serveur à
travers un pare-feu.
Dans des conditions normales, les réseaux rejettent des paquets bien plus
souvent que les serveurs NFS ne rejettent de requêtes. C'est pourquoi un
réglage agressif de délai de dépassement
(« time-out ») de retransmission pour NFS sur TCP est
inutile. Les réglages habituels de délai de dépassement pour
NFS sur TCP varient entre une et dix minutes. Après qu'un client a
terminé ses retransmissions (la valeur de l'option
retrans de
mount), il considère que le réseau a subi une panne et tente de se
reconnecter au serveur grâce à une nouvelle interface de connexion
(« socket »). Puisque TCP fiabilise le transport de
données sur le réseau,
rsize et
wsize peuvent en toute
sécurité permettre par défaut la plus grande valeur
gérée à la fois par le client et par le serveur,
indépendamment de la taille du MTU du réseau.
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 séparé.
Le client Linux peut utiliser différents modes de transfert pour contacter
le service rpcbind d'un serveur, son service mountd, son gestionnaire de
verrou réseau (NLM) et son service NFS. Le mode de transport utilisé
par le client NFS de Linux pour chaque point de montage dépend des
options passées à mount, qui incluent
proto,
mountproto udp et
tcp.
Le client envoie des notifications au gestionnaire réseau de statut
(NSM : « network status manager ») via UDP, quel que
soit le mode de transfert précisé. Il écoute cependant les
notifications NSM du serveur à la fois sur UDP et TCP. Le protocole
gérant la liste de contrôle d'accès à NFS (NFACL :
« nfs access control list ») utilise le même mode de
transfert que le service NFS principal.
Si aucune option n'est précisée 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 défaut.
Si le serveur ne gère 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 géré par le client ou est mal configuré, la
requête de montage échoue. Si l'option
bg a été
passée, la commande mount passe en arrière-plan et continue
d'essayer la requête de montage demandée.
Quand l'une des options
proto,
udp ou
tcp est passée
mais que
mountproto ne l'est pas, le mode de transfert demandé est
utilisé à la fois pour contacter le service mountd du serveur et ses
services NLM et NFS.
Si l'option
mountproto est passée mais que ni
proto, ni
udp et ni
tcp n'est passée alors le mode demandé est
utilisé pour la requête mount initiale, mais la commande mount
essaye de découvrir quel mode de transfert est pris en charge pour le
protocole NFS, et préférera TCP si les deux modes sont
implémentés.
Si
mountproto et
proto (ou
udp ou
tcp) sont
passés en même temps, le mode de transport indiqué à
l'option
mountproto est utilisé pour la requête initiale de
mountd, et le mode indiqué à
proto (ou
udp ou
tcp) est utilisé pour NFS, quel que soit l'ordre de ces options.
Le programme ne cherchera pas à trouver les services si ces options sont
données.
Si l'une des options
proto,
udp,
tcp ou
mountproto
est passée plus d'une fois dans une même commande, alors la valeur
retenue sera celle la plus à droite.
Utiliser NFS sur UDP sur des connexions haut débit¶
Utiliser NFS sur UDP avec des connexions haut débit comme Gigabit
peut causer des corruptions de données silencieuses.
Le problème peut être déclenché lors de fortes charges, et
est causé par des difficultés dans le réassemblage de fragments
IP. Les lectures et écritures par NFS transmettent typiquement des
paquets UDP de 4 kilooctets ou plus, qui doivent être cassés en
plusieurs fragments pour être envoyés sur le lien Ethernet, pour
lequel la taille des paquets est limitée à 1500 octets par
défaut. Ce processus a lieu au niveau de la couche réseau IP et est
appelé fragmentation.
Afin d'identifier les fragments qui proviennent du même paquet, IP attribue
un identifiant IP (
IP ID) sur 16 bits à chaque paquet. Les
fragments générés à partir du même paquet UPD auront
le même identifiant IP. Le système destinataire récupère
ces fragments et les combine pour reformer les paquets UPD originaux. Ce
processus est appelé réassemblage. Le délai d'expiration par
défaut pour le réassemblage de paquets est de 30 secondes. Si
la pile réseau ne reçoit pas tous les fragments d'un paquet
donné pendant cet intervalle de temps, elle suppose que les fragments
manquants se sont perdus et rejette ceux qui ont déjà été
reçus.
Le problème que cela crée sur des connexions à haut débit
est dû au fait qu'il est possible d'envoyer plus de 655356 paquets
en 30 secondes. En fait, avec un trafic dense NFS, les identifiants IP se
répètent au bout d'environ 5 secondes.
Cela a de sérieux effets sur le réassemblage : si un fragment se
perd, un autre fragment
d'un paquet différent mais avec le
même identifiant IP arrivera avant l'expiration au bout de
30 secondes, et la pile réseau combinera ces fragments pour former
un nouveau paquet. La plupart du temps, les couches réseau au-dessus d'IP
détecteront ce réassemblage non assorti — dans le cas
d'UPD, la somme de contrôle UDP sur 16 bits sur la charge utile du
paquet ne correspondra pas, et UDP rejettera le mauvais paquet.
Cependant, comme la somme de contrôle UDP est sur uniquement 16 bits,
il y a une chance sur 655356 qu'elle coïncide même si la charge
utile du paquet est complètement aléatoire (ce qui très souvent
n'est pas vrai). Si tel est le cas, une corruption de données silencieuse
se sera produite.
Cette possibilité doit être prise au sérieux, au moins sur
Ethernet Gigabit. Les débits réseau de 100 Mbit/s devraient
être considérés comme moins problématiques, car dans la
plupart des situations, l'épuisement des identifiants IP prendra bien
plus que 30 secondes.
Il est donc fortement recommandé d'utiliser
NFS sur TCP là où
c'est possible, car TCP n'effectue pas de fragmentation.
Si vous devez absolument utiliser NFS sur UDP sur un réseau Gigabit
Ethernet, quelques actions peuvent être effectuées pour limiter le
problème et réduire la probabilité de corruption :
- trames Jumbo :
- Beaucoup de cartes réseau Gigabit sont capables de
transmettre des trames plus grandes que la limite traditionnelle sur
Ethernet de 1500 octets (typiquement 9000 octets). Utiliser ces
grandes trames (Jumbo) vous permettra de faire fonctionner NFS sur UDP
avec une taille de page de 8 ko sans fragmentation. Bien sûr,
cela n'est possible que si toutes les stations impliquées gèrent
les trames Jumbo.
- Pour activer l'envoi de trames Jumbo sur une machine avec
une carte réseau qui les gère, il suffit de configurer
l'interface avec une valeur MTU de 9000.
- diminution du délai avant expiration de
réassemblage :
- Le réassemblage incorrect de fragments peut être
aussi évité en diminuant ce délai sous le temps
nécessaire à la réinitialisation des identifiants IP. Pour
ce faire, écrivez simplement la nouvelle valeur du délai (en
seconde) dans le fichier /proc/sys/net/ipv4/ipfrag_time.
- Une valeur de 2 secondes diminuera fortement la
probabilité d'une collision d'identifiants IP sur un seul lien
Gigabit, tout en permettant un délai d'expiration raisonnable lors de
la réception d'un trafic fragmenté depuis des serveurs
distants.
COHÉRENCE DES DONNÉES ET DES MÉTADONNÉES¶
Certains systèmes de fichiers en grappes (cluster) récents offrent une
cohérence absolue du cache à leurs clients. La cohérence
parfaite de cache aux clients NFS « disparates » est
difficile à obtenir, surtout sur les réseaux de grandes tailles
(WAN). Dans ce cas, NFS est réglé pour la plus faible cohérence
de cache qui satisfait les contraintes de la plupart des types de partage de
fichiers. Habituellement, le partage de fichiers est totalement
séquentiel : le premier client A ouvre un fichier, écrit
quelque chose dedans, puis le ferme. Ensuite, un client B ouvre ce même
fichier, puis lit les modifications.
Cohérence de cache
« close-to-open »¶
Quand une application ouvre un fichier stocké sur un serveur NFS, le client
NFS vérifie qu'il existe toujours sur le serveur et que l'utilisateur qui
ouvre ce fichier en a bien le droit, grâce à des requêtes
GETATTR ou ACCESS. Quand l'application ferme le fichier, le client NFS
écrit toutes les modifications en attente afin que le prochain à
ouvrir ce fichier puisse en voir les changements. Cela donne
l'opportunité au client NFS de prévenir l'application de toute
erreur en écriture sur le serveur, via le code de retour de
close(2). Ce système de vérification à l'ouverture et de
purge à la fermeture est connu sous le nom de cohérence de cache
« close-to-open » (close-to-open cache consistency).
Faible cohérence de cache¶
Il y a toujours des cas dans lesquels le cache de données du client
contient des données incohérentes. Dans la version 3 du
protocole NFS est apparue la « faible cohérence de
cache » (appelée aussi WCC), offrant une méthode efficace
de vérification des attributs d'un fichier avant et après une
requête unique. Cela permet à un client une meilleure perception des
modifications qui ont pu être réalisées par les autres clients.
Quand un client génère beaucoup d'opérations concomitantes qui
modifient le même fichier au même moment (par exemple grâce
à des écritures asynchrones en arrière-plan), il est difficile
de savoir si le fichier a été modifié par ce client ou par un
autre.
Mémorisation (cache) des attributs¶
L'utilisation de l'option
noac de mount permet de réaliser la
cohérence de la mémorisation (cache) des attributs pour de multiples
clients. Pratiquement toutes les opérations de système de fichiers
vérifient les informations d'attributs de fichiers. Le client garde cette
information en mémoire (cache) pendant un certain temps afin de
réduire la charge du serveur et du réseau. Quand
noac est
activée, le cache des attributs de fichier est désactivé sur le
client et chaque opération qui doit vérifier les attributs des
fichiers doit impérativement s'adresser au serveur. Ceci permet au client
de voir rapidement les modifications sur un fichier, en contrepartie d'une
augmentation importante des opérations réseaux.
Soyez attentif à ne pas confondre l'option
noac avec « pas
de mémorisation de données (no data caching) ». L'option
noac de mount empêche la mise en cache par le client des
métadonnées du fichier, mais il existe toujours des cas dans
lesquels des incohérences de données cachées peuvent survenir
entre le client et le serveur.
Le protocole NFS n'a pas été conçu pour gérer la
cohérence absolue des caches pour des grappes (clusters) de systèmes
de fichiers sans qu'il soit nécessaire d'utiliser des types particuliers
de sérialisation au niveau applicatif. Si la cohérence absolue du
cache est nécessaire 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 désactiver totalement la mise en cache
des données.
Mettre en cache les entrées répertoires¶
Le client NFS Linux garde en cache les résultats d'une requête NFS
LOOKUP. Si la requête pointe sur un répertoire existant sur le
serveur, le résultat sera noté
positif. Sinon, si le
répertoire n'existe pas (c'est-à-dire si le serveur retourne
ENOENT), le résultat sera noté
négatif.
Afin de détecter l'ajout ou la suppression de répertoires sur le
serveur, le client NFS Linux regarde la date de modification
(« mtime ») du répertoire. Si le client détecte
un changement dans cette date, le client supprime tous les résultats
LOOKUP encore en cache concernant ce répertoire. Comme la date de
modification est un attribut conservé en cache, il est possible qu'un peu
de temps se passe avant que le client remarque le changement.
Référez-vous aux descriptions des options de montage
acdirmin,
acdirmax et
noac pour plus d'informations quant
à la manière dont le temps de modification est mis en cache.
Mettre en cache les entrées des répertoires améliore 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 répertoires, cependant, peut interférer avec des applications
qui tournent simultanément sur de nombreux clients et qui doivent
détecter rapidement la création ou la suppression de fichiers.
L'option de montage
lookupcache permet de personnaliser certains
comportements de mise en cache de répertoires.
Avant la version 2.6.28 du noyau, le client NFS Linux cherchait uniquement les
résultats de recherches positifs. Cela permettait aux applications de
détecter rapidement de nouvelles entrées de répertoires
créées par d'autres clients, tout en fournissant une partie des
bénéfices dus à la mise en cache. Si une application
dépend de cet ancien comportement, vous pouvez utiliser l'option
lookupcache=positive.
Si le client ignore son cache et valide toutes les requêtes de recherche
avec le serveur, il peut alors détecter immédiatement toute
création ou suppression de répertoire par un autre client. Vous
pouvez forcer ce comportement avec l'option
lookupcache=none. L'absence
de mise en cache des répertoires entraîne une augmentation du nombre
de requêtes NFS, et donc une perte de performances. Empêcher 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
manière dont le client NFS met en cache les attributs d'un fichier.
L'option de montage sync¶
Le client NFS gère l'option de montage
sync différemment que
d'autres systèmes de fichiers (consultez
mount(8) pour une
description générique des options de montage
sync et
async). Si ni
sync ni
async ne sont indiquées (ou si
l'option
async est indiquée), le client NFS retarde l'envoi au
serveur des ordres d'écriture des applications jusqu'à ce que l'un
de ces événements survienne :
- La saturation en mémoire entraîne une demande de
ressources mémoire au système.
- Une application met à jour
(« flush ») les données d'un fichier de
manière explicite avec sync(2), msync(2) ou
fsync(3).
- Une application ferme un fichier avec close(2).
- Le fichier est verrouillé/déverrouillé
grâce à fcntl(2).
Autrement dit, dans les conditions normales d'utilisation, des données
écrites par une application peuvent ne pas apparaître
instantanément sur le serveur qui héberge le fichier.
Si l'option
sync est précisée pour un point de montage, tout
appel système qui écrit des données dans des fichiers de ce
point de montage entraîne la purge des données sur le serveur avant
de revenir en espace utilisateur (« user space »). Cela
offre une meilleure cohérence du cache des données, mais a un impact
certain sur les performances.
Les applications peuvent utiliser le drapeau d'ouverture O_SYNC afin que les
écritures d'un fichier précis soient immédiatement 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 Réseaux (NLM, Network Lock Manager) est un
protocole auxiliaire séparé servant à gérer les verrous
sur les fichiers dans les versions 2 et 3 de NFS. Pour gérer la
récupération des verrous après le redémarrage d'un client
ou du serveur, un second protocole (connu sous le nom de protocole Network
Status Manager) est nécessaire. Dans la version 4 de NFS, le
verrouillage des fichiers est directement implanté dans le protocole NFS,
et les protocoles NLM et NSM ne sont plus utilisés.
Dans la plupart des cas, les services NLM et NSM sont démarrés
automatiquement et aucune configuration additionnelle n'est requise. La
configuration en noms de domaine complètement définis (FQDN) de tous
les clients NFS est nécessaire pour permettre aux serveurs NFS de
retrouver leurs clients, afin de les prévenir en cas de redémarrage.
NLM ne gère 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 grâce
à
flock(2) en annonces de verrouillage.
Lors du montage de serveurs ne gérant pas le protocole NLM ou lorsqu'on
monte un serveur NFS à travers un pare-feu qui bloque le port du service
NLM, il faut utiliser l'option
nolock de mount. Le verrouillage NLM
doit être désactivé grâce à l'option
nolock
lorsqu'on utilise NFS pour monter
/var, puisque
/var contient
les fichiers utilisés par NLM dans son implémentation sous Linux.
L'utilisation de l'option
nolock est parfois conseillée pour
améliorer les performances d'une application propriétaire qui ne
tourne que sur un seul client mais qui utilise intensément les verrous de
fichiers.
Les caractéristiques du cache de la version 4 de
NFS.¶
Le comportement du cache des données et des métadonnées des
clients NFS version 4 est identique à celui des
précédentes versions. Toutefois, la version 4 de NFS offre deux
nouveaux dispositifs pour améliorer le comportement du cache :
attributs de changement et
délégation de
fichier.
L'
attribut de changement est un nouvel élément des
métadonnées de fichiers et de répertoires NFS qui enregistre
les modifications des données. Il se substitue à 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 liés à la gestion de l'horodatage ni sur
le client ni sur le serveur.
La
délégation 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 était le seul à y accéder. Le serveur
s'engage à prévenir le client (grâce à une requête de
rappel, ou « callback ») si un autre client tente
d'accéder à ce même fichier. Une fois qu'un fichier a
été délégué à un client, ce client peut
mémoriser (mettre en cache) les données et les métadonnées
de ce fichier de façon agressive sans avoir à contacter le serveur.
Il y a deux types de délégations :
lecture et
écriture. Une délégation en
lecture indique que
le serveur avertira le client si d'autres clients veulent écrire dans ce
fichier. Une délégation en
écriture indique que le
client sera prévenu des tentatives de lecture ou d'écriture.
Les serveurs offrent les délégations de fichier sitôt qu'un
fichier est ouvert et peuvent annuler ces délégations n'importe
quand dès lors qu'un autre client désire accéder à un
fichier d'une manière qui entre en conflit avec les délégations
déjà attribuées. Les délégations de répertoires
ne sont pas gérées.
Afin de pouvoir gérer les alertes de délégations
(« delegation callback »), le serveur vérifie le
chemin retour vers le client au moment du contact initial de celui-ci. Si le
retour vers le client ne peut pas être établi, le serveur n'attribue
purement et simplement aucune délégation à ce client.
CONSIDÉRATIONS DE SÉCURITÉ.¶
Les serveurs NFS contrôlent l'accès aux données des fichiers,
mais leur offre de gestion de l'authentification des requêtes NFS
dépend de leur implémentation des RPC. Les contrôles
d'accès NFS traditionnels imitent les contrôles d'accès
binaires standards offerts par les systèmes de fichiers locaux.
L'authentification RPC traditionnelle utilise un nombre pour représenter
chaque utilisateur (normalement l'uid propre à cet utilisateur), un
nombre pour représenter le groupe de cet utilisateur (le gid de
l'utilisateur) et un ensemble d'au maximum 16 nombres de groupes
additionnels pour représenter les groupes auxquels cet utilisateur peut
appartenir.
Traditionnellement, les données du fichier et l'ID de l'utilisateur ne sont
pas chiffrées sur le réseau (en clair). Qui plus est, les
versions 2 et 3 de NFS utilisent des protocoles auxiliaires
séparés pour le montage, le verrouillage et le déverrouillage
des fichiers, et pour renvoyer les valeurs de retour système des clients
et serveurs. Ces protocoles auxiliaires n'utilisent pas d'authentification.
En plus d'avoir intégré ces deux protocoles auxiliaires dans le
protocole NFS principal, la version 4 de NFS offre des formes plus
avancées de contrôle d'accès, d'authentification, et de
protection lors du transfert des données. La spécification de la
version 4 de NFS requiert les ACLs NFSv4, l'authentification RPCGSS, et
les diverses sécurités RPCGSS permettant le contrôle
d'intégrité et le chiffrement via RPC. Puisque la version 4 de
NFS ajoute les fonctionnalités de ces protocoles au cœur du
protocole NFS, les nouvelles caractéristiques de sécurité
s'appliquent à toutes les opérations de NFS version 4, incluant
donc le montage, le verrouillage des fichiers, et ainsi de suite.
L'authentification RPCGSS peut aussi être utilisée avec les
versions 2 et 3 de NFS, mais ne protège pas les protocoles
associés.
L'option de montage
sec indique que le mode de sécurité RPCGSS
est actif sur ce point de montage NFS. L'ajout de
sec=krb5 fournit la
preuve chiffrée de l'identité de l'utilisateur pour chaque
requête RPC. Ce dispositif offre une vérification forte de
l'identité des utilisateurs qui accèdent aux données du
serveur. Notez que des configurations supplémentaires à cet ajout de
l'option de mount sont nécessaires pour activer la sécurité
Kerberos. Consultez la page de manuel de
rpc.gssd(8) pour plus de
détails.
Deux dispositifs additionnels de la sécurité Kerberos sont pris en
charge :
krb5i et
krb5p. Le dispositif de
sécurité
krb5i offre une garantie de chiffrement fort contre
la falsification des données pour chaque requête RPC. Le dispositif
de sécurité
krb5p chiffre chaque requête RPC afin
d'éviter qu'elle soit exposée pendant son transfert sur le
réseau. Toutefois, le chiffrement ou la vérification de
l'intégrité entraînent des baisses de performance. D'autres
formes de sécurité par chiffrement sont aussi prises en charge.
Le protocole NFS version 4 permet aux clients et aux serveurs la
négociation de multiples dispositifs de sécurité lors du
processus de montage. Cependant, Linux n'implémente pas encore une telle
négociation. Le client Linux indique un seul dispositif de
sécurité au moment du montage qui restera ensuite actif pour toute
la durée du montage. Si le serveur ne gère pas ce dispositif, la
requête de montage initiale est refusée par le serveur.
Utiliser un port source non privilégié¶
Le client NFS communique normalement avec le serveur par des tuyaux réseaux
(network sockets). À chaque bout du tuyau est associé un port, qui
est un simple nombre entre 1 et 65535, ce qui permet de distinguer des tuyaux
pointant sur la même adresse IP. Un tuyau est identifié de
manière 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 général un port
privilégié
(c'est-à-dire avec une valeur inférieure à 1024). Seul un
processus tournant avec des droits du superutilisateur peut créer un
tuyau à partir d'un port privilégié.
La fourchette des ports potentiellement choisis est configurée par une
paire de sysctls pour éviter 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 à
un moment donné est en pratique de l'ordre d'une centaine.
Comme décrit plus haut, le schéma 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 à l'origine de requêtes. Un serveur NFS
suppose que si une connexion provient d'un port non privilégié, les
numéros UID et GID de la requête NFS ont déjà
été vérifiés par le noyau du client ou tout autre
programme système local. Ce système est facile à contourner,
mais sur un réseau sécurisé d'ordinateurs de confiance, c'est
parfaitement adapté.
En gros, un tuyau est utilisé pour chaque point de montage NFS. Si un
client peut aussi utiliser un port source non privilégié, le nombre
de tuyaux autorisés (et donc le nombre maximal de points de montages en
parallèles) sera beaucoup plus important.
Utiliser un port source non privilégié peut quelque peu compromettre
la sécurité 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 requête. C'est pourquoi les serveurs NFS ne le prennent pas
en charge par défaut. En règle générale, ils l'autorisent
explicitement à l'aide d'une option de partage.
Pour garder un bon niveau de sécurité tout en ouvrant un maximum de
points de montages, il est préférable d'autoriser les connexions
clients sur un port non privilégié seulement si le serveur et le
client utilisent tous deux une authentification forte, comme celle fournie par
Kerberos.
Montage à 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
grâce à des règles de filtrage IP. Il est toujours possible de
monter un serveur NFS à travers un pare-feu, bien que les mécanismes
de découverte automatique des terminaisons d'accès
(« endpoints ») de la commande
mount(8) peuvent ne
pas fonctionner. Il vous faudra alors fournir des détails
spécifiques à ces terminaisons d'accès
(« endpoints ») grâce 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 démon rpcbind pour déterminer :
- Le port réseau utilisé par chaque service
basé sur les RPC
- Le protocole de transport utilisé par chaque service
basé sur les RPC
Le démon rpcbind utilise un port bien connu (111) afin d'aider les clients
à trouver la terminaison (endpoint) d'un service. Bien que NFS utilise
souvent un numéro de port standard (2049), des services auxiliaires tels
que NLM peuvent choisir au hasard des numéros de port inutilisés.
Les configurations habituelles des pare-feu bloquent le port bien connu de
rpcbind. En l'absence du service rpcbind, l'administrateur du serveur
définit un numéro de port pour les services liés à NFS
afin que le pare-feu puisse permettre l'accès aux ports des services
spécifiques NFS. Les administrateurs des clients pourront alors indiquer
le numéro du port du service mountd grâce à l'option
mountport de la commande
mount(8). Il peut être
nécessaire d'imposer l'utilisation de TCP ou d'UDP si le pare-feu bloque
l'un de ces transports.
Désactiver le traitement des ACL (Access Control List).¶
Solaris permet aux clients NFS version 3 l'accès direct aux Access
Control Lists (ACL) POSIX stockés dans son système de fichiers
local. Ce protocole auxiliaire propriétaire, connu sous le nom de NFSACL,
offre un contrôle d'accès plus riche que le mode binaire. Linux
implémente ce protocole dans un but de compatibilité avec
l'implémentation NFS de Solaris. Cependant, le protocole NFSACL n'est
jamais devenu une partie standard de la spécification NFS version 3.
La spécification de NFS version 4 impose une nouvelle version des
Access Control Lists qui sont sémantiquement 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 mélange à la fois les ACL POSIX et NFS
version 4.
OPTION DE REMONTAGE¶
Les options de montage générique comme
rw et
sync
peuvent être modifiées par les points de montage utilisant l'option
remount. Voir
mount(8) pour plus d'informations sur les options
génériques de montage.
Sauf quelques exceptions, les options spécifiques à NFS ne peuvent pas
être modifiées pendant un remontage. Par example, le transport
sous-jacent ou la version NFS ne peuvent pas être changés par un
remontage.
Effectuer un remontage sur un système de fichiers NFS monté avec
l'option
noac peut avoir des conséquences inattendues. L'option
noac est une combinaison de l'option générique
sync et
de l'option spécifique NFS
actimeo=0.
Démontage après remontage¶
Pour les points de montage qui utilisent NFS versions 2 ou 3, la
sous-commande de démontage NFS dépend de la connaissance de
l'ensemble initial des options de montage utilisées pour effectuer
l'opération MNT. Ces options sont stockées sur le disque par la
sous-commande de montage NFS, et peuvent être effacées par un
remontage.
Afin de s'assurer que les options de montage enregistrées ne sont pas
effacées lors d'un remontage, il faut spécifier au remontage le
répertoire de montage local, ou le serveur hôte 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
déjà enregistrées sur le disque pour le serveur NFS monté
dans /mnt.
FICHIERS¶
- /etc/fstab
- Table des systèmes de fichiers
BOGUES¶
Le client NFS antérieur à 2.4.7 ne gérait pas NFS sur TCP.
Le client NFS antérieur à 2.4.20 utilisait une heuristique pour savoir
si les données mémorisées d'un fichier (en cache) étaient
toujours valides plutôt qu'utiliser la méthode standard de
cohérence de cache close-to-open décrite ci-dessus.
Depuis la version 2.4.22, Le client NFS utilise une estimation RTT de type
Van Jacobsen pour définir les délais de dépassement de temps
(timeout) lorsqu'il utilise NFS sur UDP.
Le client NFS Linux antérieur à 2.6.0 ne gérait pas NFS
version 4.
Le client NFS antérieur à 2.6.8 n'utilisait les lectures et
écritures synchrones que lorsque les réglages de
rsize et
wsize étaient inférieurs à la taille des pages du
système.
Le client NFS Linux ne prend toujours pas en charge certaines
caractéristiques optionnelles du protocole NFS version 4, telles que
la négociation de sécurité, les soumissions de serveurs et les
attributs nommés.
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 spécification UDP.
RFC 793 concernant la spécification TCP.
RFC 1094 concernant la spécification de NFS version 2.
RFC 1813 concernant la spécification de NFS version 3.
RFC 1832 concernant la spécification XDR.
RFC 1833 concernant la spécification RPC bind.
RFC 2203 concernant la spécification du protocole de l'API GSS RPCSEC.
RFC 3530 concernant la spécification de NFS version 4.
TRADUCTION¶
Cette page de manuel a été traduite et mise à jour par Christophe
Blaess entre 1997 et 2003. La version présente 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.