NOM
nfs - Format de fstab et options pour les systèmes de fichiers nfs et
nfs4
SYNOPSIS
/etc/fstab
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 le
comportement du client NFS lorsqu’il accède 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 :
serveur:chemin /point_de_montage type_de_fs option,option,... 0
0
Le nom du serveur et le répertoire partagé sont séparés par deux
points, alors 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 simple nom, un nom de
domaine complètement défini (FQDN) ou une adresse IPv4 en notation
pointée. Le champ fstype contient soit «nfs » (pour les montages NFS
version 2 ou 3), soit « nfs4 » (pour les montages NFS version 4). Les
types de systèmes de fichiers nfs et nfs4 partagent les mêmes options
de montage, qui sont décrites ci-dessous :
OPTIONS DE MONTAGE
Reportez vous à 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 de spécifier d’options de montage particulières,
indiquez l’option générique defaults dans /etc/fstab.
Options valides pour les systèmes de fichiers nfs ou nfs4
L’utilisation de ces options est valable à la fois pour les systèmes de
fichiers nfs et nfs4. Cela entraîne le même comportement et les mêmes
valeurs par défaut pour les deux systèmes de fichiers.
soft / hard Définit 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 sera en é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 Temps d’attente (en dixièmes de seconde) du client NFS
avant de ré-émettre la requête NFS. Si cette option
n’est pas définie, les requêtes sont ré-émises toutes
les 60 secondes dans le cas de NFS sur TCP. Le client
NFS ne fait aucune vérification du délai d’expiration
dans le cas de NFS sur TCP.
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équement 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 seconde. 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 maximum 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 maximum 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 une 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 (cachent) 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
inconnus 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 blocages (locking) de
fichiers est de préférence recommandée. La section
COHÉRENCE DES DONNÉES ET DES METADONNÉES contient une
présentation détaillée de ces approches.
acregmin=n Fixer (en secondes) la durée minimale de mémorisation
(cache) des attributs d’un fichier régulier avant de les
rafraîchir depuis le serveur. La valeur par défaut est
de 3 secondes, si cette option n’est pas définie.
acregmax=n Fixer (en secondes) la durée maximale de mémorisation
(cache) des attributs d’un fichier régulier avant de les
rafraîchir depuis le serveur. La valeur par défaut est
de 60 secondes, si cette option n’est pas définie.
acdirmin=n Fixer (en secondes) la durée minimale de mémorisation
(cache) des attributs d’un répertoire avant de les
rafraîchir depuis le serveur. La valeur par défaut est
de 30 secondes si cette option n’est pas définie.
acdirmax=n Fixer (en secondes) la durée maximale de mémorisation
(cache) des attributs d’un répertoire avant de les
rafraîchir 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 fixe 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écrit ci-dessus.
bg / fg Détermine 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 Fixer la durée, en minutes, pendant laquelle le montage
NFS sera tenté par la commande mount(8), en arrière-plan
ou en avant-plan, avant d’abandonner. Si l’option n’est
pas définie, la valeur par défaut pour l’avant-plan est
de 2 minutes. La valeur par défaut pour l’arrière-plan
est 10 000 minutes, soit environ une semaine, à 80
minutes près.
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és
gérées sont none, krb5, krb5i, krb5p, lkey, lkeyi,
lkeyp, spkm, spkmi et spkmp. 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 obtient un cache unique. 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 concurrents de ce
même partage.
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
Specifies whether the NFS client should use a privileged
source port when communicating with an NFS server for
this mount point. If this option is not specified, or
the resvport option is specified, the NFS client uses a
privileged source port. If the noresvport option is
specified, the NFS client uses a non-privileged source
port. This option is supported in kernels 2.6.28 and
later.
Using non-privileged source ports helps increase the
maximum number of NFS mount points allowed on a client,
but NFS servers must be configured to allow clients to
connect via non-privileged source ports.
Refer to the SECURITY CONSIDERATIONS section for
important details.
Options valides pour le système de fichiers nfs
Utilisez ces options ainsi que les options de la sous-section
précédente pour monter des systèmes de fichiers de type nfs.
proto=transport
Protocole de transport utilisé par le client NFS pour
transmettre les requêtes aux serveur NFS pour ce point
de montage. transport peut être soit udp soit tcp.
Chacun utilise différentes valeurs par défaut pour
retrans et timeo, consultez la description de ces deux
options de mount pour plus de détails.
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
proto=tcp force l’utilisation de TCP pour tout le
trafic entre la commande mount(8) et le client NFS.
Indiquer proto=udp force l’utilisation d’UDP pour tous
ces trafics.
Si l’option proto de mount n’est pas définie, la
commande mount(8) découvrira quels protocoles le serveur
accepte et choisira un transport approprié pour chacun
des services. Consultez la section MÉTHODES DE TRANSPORT
pour plus détails.
udp L’option udp est une variante pour proto=udp, compatible
avec d’autres systèmes d’exploitation.
tcp L’option tcp est une variante pour proto=tcp, compatible
avec d’autres systèmes d’exploitation.
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=transport
The transport the NFS client uses to transmit requests
to the NFS server’s mountd service when performing this
mount request, and when later unmounting this mount
point. transport can be either udp or tcp.
This option can be used when mounting an NFS server
through a firewall that blocks a particular transport.
When used in combination with the proto option,
different transports for mountd requests and NFS
requests can be specified. If the server’s mountd
service is not available via the specified transport,
the mount request fails. Refer to the TRANSPORT METHODS
section for more on how the mountproto mount option
interacts with the proto mount option.
mounthost=name 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 maximum du nom du chemin composant ce montage.
Si cette option n’est pas définie, la taille maximum est
négociée avec le serveur. Dans la plupart des cas, cette
taille maximum est 255 caractères.
Des versions précédentes de NFS ne supportent pas cette
négociation. L’utilisation de cette option garantit que
pathconf(3) donnera bien la longueur maximum aux
applications pour ces versions.
nfsvers=n Le numéro de version du protocole NFS utilisé pour
contacter le service NFS du serveur. Le client NFS de
Linux gère les versions 2 et 3 du protocole NFS
lorsqu’il utilise un système de fichiers de type nfs. 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 l’utilisation de la version 3, puis négocie
la version NFS avec le serveur si la gestion de la
version 3 n’est pas disponible.
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 blocage 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.
The intr / nointr mount option is deprecated after
kernel 2.6.25. Only SIGKILL can interrupt a pending NFS
operation on these kernels, and if specified, this mount
option is ignored to provide backwards compatibility
with older kernels.
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ÉTA-DONNÉ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 oeuvre 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és-activation du protocole auxiliaire NFSACL est
parfois rendu 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.
Options valides pour le système de fichiers nfs4
Utilisez ces options ainsi que les options de la première sous-section
ci-dessus pour monter des systèmes de fichiers de type nfs4.
proto=transport
Protocole de transport utilisé par le client NFS pour la
transmission des requêtes au serveur NFS pour ce point
de montage. transport peut valoir soit udp soit tcp.
Tous les serveurs NFS version 4 doivent implémenter TCP,
donc si cette option de montage n’est pas définie, le
client NFS version 4 utilisera le protocole de transport
TCP. Consultez 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.
The intr / nointr mount option is deprecated after
kernel 2.6.25. Only SIGKILL can interrupt a pending NFS
operation on these kernels, and if specified, this mount
option is ignored to provide backwards compatibility
with older kernels.
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é 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ÉTA-DONNÉ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. 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 et devra être spécifiée
explicitement avec cette option de montage.
EXEMPLES
Pour réaliser le montage d’un partage en NFS version 2, il faut
préciser que le système de fichiers est de type nfs et spécifier
l’option de montage nfsvers=2. Pour réaliser un montage en NFS version
3, il faut préciser que le système de fichiers est de type nfs et
spécifier l’option de montage nfsvers=3. Pour réaliser un montage en
NFS version 4, il faut préciser que le système de fichiers est de type
nfs4. L’option de montage nfsvers n’est alors pas accepté.
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.
server:/export /mnt nfs defaults 0 0
Voici un exemple, issu du fichier /etc/fstab, concernant un montage NFS
version 2 en UDP.
server:/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.
server:/export /mnt nfs4 sec=krb5 0 0
Cet exemple peut servir à réaliser le montage de /usr grâce à NFS.
server:/export /usr nfs ro,nolock,nocto,actimeo=3600 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 les entrées du service distant automatiquement,
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 NFS 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.
Par tradition, les clients NFS se servent exclusivement du transport
UDP pour la transmission des requêtes vers les serveurs. Bien que son
implémentation soit simple, NFS sur UDP a de nombreuses limitations qui
l’empêche 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. Le délai de dépassement (timeout) pour les retransmissions
est réglé inférieur à la seconde afin de permettre aux clients de
récupérer rapidement en cas de requêtes rejetées. Cela peut entraîner
une surcharge du trafic réseau et du serveur.
D’autre part, 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 de tels environnements, 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éseaux 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 sont entre une et dix minutes.
Après qu’un client ait 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 à un nouveau 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épendemment
de la taille du MTU du réseau.
Utilisation de l’option de montage mountproto
This section applies only to NFS version 2 and version 3 mounts since
NFS version 4 does not use a separate protocol for mount requests.
The Linux NFS client can use a different transport for contacting an
NFS server’s rpcbind service, its mountd service, its Network Lock
Manager (NLM) service, and its NFS service. The exact transports
employed by the Linux NFS client for each mount point depends on the
settings of the transport mount options, which include proto,
mountproto, udp, and tcp.
The client sends Network Status Manager (NSM) notifications via UDP no
matter what transport options are specified, but listens for server NSM
notifications on both UDP and TCP. The NFS Access Control List
(NFSACL) protocol shares the same transport as the main NFS service.
If no transport options are specified, the Linux NFS client uses UDP to
contact the server’s mountd service, and TCP to contact its NLM and NFS
services by default.
If the server does not support these transports for these services, the
mount(8) command attempts to discover what the server supports, and
then retries the mount request once using the discovered transports.
If the server does not advertise any transport supported by the client
or is misconfigured, the mount request fails. If the bg option is in
effect, the mount command backgrounds itself and continues to attempt
the specified mount request.
When the proto option, the udp option, or the tcp option is specified
but the mountproto option is not, the specified transport is used to
contact both the server’s mountd service and for the NLM and NFS
services.
If the mountproto option is specified but none of the proto, udp or tcp
options are specified, then the specified transport is used for the
initial mountd request, but the mount command attempts to discover what
the server supports for the NFS protocol, preferring TCP if both
transports are supported.
If both the mountproto and proto (or udp or tcp) options are
specified, then the transport specified by the mountproto option is
used for the initial mountd request, and the transport specified by the
proto option (or the udp or tcp options) is used for NFS, no matter
what order these options appear. No automatic service discovery is
performed if these options are specified.
If any of the proto, udp, tcp, or mountproto options are specified more
than once on the same mount command line, then the value of the
rightmost instance of each of these options takes effect.
COHÉRENCE DES DONNÉES ET DES MÉTA-DONNÉ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 apparu 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 modification 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éta-donné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.
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és (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 surviennent :
La saturation en mémoire entraîne une demande de ressources
mémoire au système.
Une application purge (flushes) 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éta-donné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
dlgation 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 dlgation 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 (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 (cacher) les
données et les méta-données de ce fichier de façon agressive sans avoir
à contacter le serveur.
Les délégations de fichiers sont de deux types : 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 (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 singent
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 crypté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 cryptage via
RPC. Puisque la version 4 de NFS ajoute les fonctionnalités de ces
protocoles au coeur 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 crypté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 supportés :
krb5i et krb5p. Le dispositif de sécurité krb5i offre une garantie de
cryptage fort contre la falsification des données pour chaque requête
RPC. Le dispositif de sécurité krb5p crypte chaque requête RPC afin
d’éviter qu’elle soit exposée pendant son transfert sur le réseau.
Toutefois, le cryptage ou la vérification de l’intégrité entraînent des
baisses de performance. La gestion similaire d’autres formes de
sécurités par cryptage (telles que lipkey ou SPKM3) sont aussi
disponibles.
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.
Using non-privileged source ports
NFS clients usually communicate with NFS servers via network sockets.
Each end of a socket is assigned a port value, which is simply a number
between 1 and 65535 that distinguishes socket endpoints at the same IP
address. A socket is uniquely defined by a tuple that includes the
transport protocol (TCP or UDP) and the port values and IP addresses of
both endpoints.
The NFS client can choose any source port value for its sockets, but
usually chooses a privileged port. A privileged port is a port value
less than 1024. Only a process with root privileges may create a
socket with a privileged source port.
The exact range of privileged source ports that can be chosen is set by
a pair of sysctls to avoid choosing a well-known port, such as the port
used by ssh. This means the number of source ports available for the
NFS client, and therefore the number of socket connections that can be
used at the same time, is practically limited to only a few hundred.
As described above, the traditional default NFS authentication scheme,
known as AUTH_SYS, relies on sending local UID and GID numbers to
identify users making NFS requests. An NFS server assumes that if a
connection comes from a privileged port, the UID and GID numbers in the
NFS requests on this connection have been verified by the client’s
kernel or some other local authority. This is an easy system to spoof,
but on a trusted physical network between trusted hosts, it is entirely
adequate.
Roughly speaking, one socket is used for each NFS mount point. If a
client could use non-privileged source ports as well, the number of
sockets allowed, and thus the maximum number of concurrent mount
points, would be much larger.
Using non-privileged source ports may compromise server security
somewhat, since any user on AUTH_SYS mount points can now pretend to be
any other when making NFS requests. Thus NFS servers do not support
this by default. They explicitly allow it usually via an export
option.
To retain good security while allowing as many mount points as
possible, it is best to allow non-privileged client connections only if
the server and client both require strong authentication, such as
Kerberos.
Montage à travers d’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 automatiques 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 RPCs
Le protocole de transport utilisé par chaque service basé sur
les RPCs
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-feux 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 (ACLs) 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 ACLs
POSIX. Les ACLs de NFS version 4 ne sont pas totalement compatibles
avec les ACLs POSIX. De ce fait, des traductions entre les deux sont
obligatoires dans un environnement qui mélange à la fois les ACLs POSIX
et NFS version 4.
FICHIERS
/etc/fstab Table des systèmes de fichiers
BOGUES
L’option générique remount n’est pas totalement gérée. Les options
génériques, comme rw ou ro peuvent être modifiées grâce à l’option
remount, mais les options spécifiques NFS ne sont pas toutes gérées.
Par exemple, le transport utilisé, ou la version NFS ne peuvent pas
être changés par un remount. L’exécution d’un remount sur un système de
fichiers NFS monté avec l’option noac peut avoir des conséquences
inattendues. L’option noac est un mélange d’option générique, de sync
et de l’option actimeo=0 spécifique à NFS.
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 supporte toujours pas certaines caractéristiques
optionnelles du protocole NFS version 4, tel 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),
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.
2 novembre 2007