/usr/share/doc/HOWTO/fr-html/NFS-HOWTO.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>Linux NFS HOWTO</title>
</head>
<body>
<h1>Linux NFS HOWTO</h1>
<h2>Nicolai Langfeldt <code>janl@linpro.no</code></h2>
v1.0, 1er octobre 1999
<hr>
<em>(30 novembre 1999. Adaptation française par Christophe Deleuze,
<code>Christophe.Deleuze@lip6.fr</code>). HOWTO décrivant
l'installation de serveurs et clients NFS.</em>
<hr>
<h2><a name="s1">1. Préambule</a></h2>
<h2><a name="ss1.1">1.1 Blabla légal</a></h2>
<p>(C)opyright 1997-1999 Nicolai Langfeldt et Ron Peters. Si vous
modifiez ce document signalez le dans le copyright, sa distribution
est libre à condition de conserver ce paragraphe. La section FAQ
est basée sur la FAQ NFS compilée par Alan Cox. La section
<em>Checklist</em> est basée sur une <em>checklist</em> des
problèmes de mount compilée par IBM Corporation. La section ``NFS
serveur sur disquette'' a été écrite par Ron Peters.</p>
<p>(C)opyright 1997-1999 Christophe Deleuze pour la version
française. Si vous lisez ce document sous le pont de l'Alma,
veillez à respecter les limitations de vitesse.</p>
<h2><a name="ss1.2">1.2 Dénégation</a></h2>
<p>Ni Nicolai Langfeldt, ni Ron Peters ni leurs employeurs, ni qui
que ce soit, n'assume de responsabilité pour les conséquences que
les instructions de ce document peuvent avoir. Si vous choisissez
de suivre ces instructions, bonne chance !</p>
<h2><a name="ss1.3">1.3 Retour</a></h2>
<p>Ce document ne sera jamais terminé, merci de m'envoyer par mail
vos problèmes et réussites, cela pourra améliorer ce HOWTO. Envoyez
argent, commentaires et questions à <a href=
"mailto:janl@math.uio.no">janl@math.uio.no</a>, ou <a href=
"mailto:rpeters@hevanet.com">rpeters@hevanet.com</a> pour ce qui
concerne les serveurs NFS sur disquette. Si vous m'envoyez un mail,
par pitié, <em>vérifiez</em> que l'adresse de retour soit correcte
et fonctionne. Vous ne vous imaginez pas combien de mes réponses
sont revenues à cause d'une adresse incorrecte.</p>
<h2><a name="ss1.4">1.4 Autre blabla</a></h2>
<p>Si vous voulez traduire ce HOWTO merci de me le signaler, que je
puisse savoir en quels langages j'ai été publié :-). [Ndt : c'est
fait...]</p>
<p>Remerciements à Olaf Kirch pour m'avoir convaincu d'écrire ceci,
puis fourni de bonnes suggestions.</p>
<p>Les commentaires sur la traduction sont à envoyer à Christophe
Deleuze, Christophe.Deleuze@lip6.fr.</p>
<h2><a name="intro"></a> <a name="s2">2. LISEZMOI.d_abord</a></h2>
<p>NFS, le système de fichiers par réseau, a trois caractéristiques
importantes :</p>
<ul>
<li>il permet le partage de fichiers sur un réseau ;</li>
<li>il marche suffisamment bien ;</li>
<li>il crée tout un tas de problèmes de sécurité bien connus des
crackers qui peuvent facilement les exploiter pour obtenir l'accès
(lecture, écriture et effacement) à tous vos fichiers.</li>
</ul>
<p>Je parlerai de ces deux aspects dans ce HOWTO. Lisez bien la
section sécurité et vous supprimerez quelques risques stupides. Ne
dites pas que je ne vous ai pas prévenus. Les passages sur la
sécurité sont parfois assez techniques et demandent quelques
connaissances en réseau IP. Si vous ne connaissez pas les termes
utilisés vous pouvez soit consulter le HOWTO réseau, improviser ou
vous procurer un livre sur l'administration de réseau TCP/IP pour
vous familiariser avec TCP/IP. C'est une bonne idée de toutes
façons si vous administrez des machines UNIX/Linux. Un très bon
livre sur le sujet est <em>TCP/IP Network Administration</em> par
Craig Hunt, publié par O'Reilly &amp; Associates, Inc. Et quand
vous l'aurez lu et compris, vous vaudrez plus cher sur le marché du
travail, vous ne pouvez qu'y gagner :-)</p>
<p>Il y a deux sections pour vous aider à régler vos problèmes NFS,
la <em>Mount Checklist</em> et les <em>FAQs</em>. Jetez-y un oeil
si quelque chose ne marche pas comme prévu.</p>
<p>Si vous voulez/avez besoin de le récupérer et compiler vous
même, le site de référence pour le nfsd Linux 2.0 est <a href=
"ftp.mathematik.th-darmstadt.de:/pub/linux/okir">ftp.mathematik.th-darmstadt.de:/pub/linux/okir</a>.</p>
<p>À propos de NFS sous Linux 2.2 voir <a href="#linuxtwotwo">la
section sur Linux 2.2</a>.</p>
<h2><a name="nfs-server"></a> <a name="s3">3. Installer un serveur
NFS</a></h2>
<h2><a name="ss3.1">3.1 Conditions préalables</a></h2>
<p>Avant de continuer à lire ce HOWTO, vous aurez besoin de pouvoir
faire des telnet dans les deux sens entre les machines que vous
utiliserez comme serveur et client. Si cela ne fonctionne pas,
voyez le HOWTO réseau (NET-3) et configurez correctement le
réseau.</p>
<h2><a name="ss3.2">3.2 Premiers pas</a></h2>
<p>Avant de faire quoi que ce soit d'autre, il nous faut un serveur
NFS installé. Si vous faites partie d'un département réseau d'une
université ou autre, il y a probablement un grand nombre de
serveurs NFS qui tournent déjà. Si votre but est d'utiliser un
serveur déjà installé alors vous pouvez sauter à <a href=
"#nfs-client">la section sur l'installation d'un client
NFS</a>.</p>
<p>Si vous devez installer un serveur sur une machine non Linux
vous devrez lire les pages de manuel du système pour trouver
comment configurer le serveur NFS et l'exportation des systèmes de
fichiers par NFS. Ce HOWTO contient une section décrivant les
manipulations nécessaires sur divers systèmes. Ceci fait, vous
pourrez passer à la section suivante. Ou continuer à lire cette
section vu que certaines des choses que je vais dire sont
pertinentes quel que soit le type de machine que vous utilisez
comme serveur.</p>
<p>Si vous utilisez Linux 2.2, voyez <a href="#linuxtwotwo">la
section sur Linux 2.2</a> avant de passer à la suite.</p>
<p>Nous allons maintenant configurer tout un tas de programmes.</p>
<h2><a name="ss3.3">3.3 Le portmapper</a></h2>
<p>Le portmapper de Linux est appelé soit <code>portmap</code> soit
<code>rpc.portmap</code>. La page de manuel sur mon système dit que
c'est un convertisseur de port DARPA vers numéro de programme RPC.
C'est là que se trouve la première faille de sécurité. La gestion
de ce problème est décrite à la section <a href="#nfs-security">sur
la sécurité</a>, que, encore une fois, je vous invite très
fortement à lire.</p>
<p>Lancez le portmapper. Il devrait être dans le répertoire
<code>/usr/sbin</code> (sur quelques machines il est appelé
rpcbind). Vous pouvez le lancer à la main pour cette fois mais il
devra être lancé à chaque démarrage de la machine, il faudra donc
créer ou éditer les scripts rc. Les scripts rc sont décrits dans la
page de manuel init, ils sont généralement dans
<code>/etc/rc.d</code>, <code>/etc/init.d</code> ou
<code>/etc/rc.d/init.d</code>. S'il y a un script qui a un nom du
genre <code>inet</code>, c'est probablement le script à éditer.
Mais ce qu'il faut écrire ou faire sort du cadre de ce HOWTO.
Lancez portmap, et vérifiez qu'il tourne avec <code>ps -aux</code>,
puis <code>rpcinfo -p</code>. Il y est ? Benissimo.</p>
<p>Encore une chose. L'accès distant à votre portmapper est
contrôlé par le contenu de vos fichiers
<code>/etc/hosts.allow</code> et <code>/etc/hosts.deny</code>. Si
<code>rcpinfo -p</code> échoue alors que le portmapper tourne,
vérifiez ces fichiers. Voyez la section <a href="#nfs-security">sur
la sécurité</a> pour les détails concernant ces fichiers.</p>
<h2><a name="ss3.4">3.4 Mountd et nfsd</a></h2>
<p>Les prochains programmes à lancer sont mountd et nfsd. Mais
d'abord il faut éditer un autre fichier, <code>/etc/exports</code>.
Disons que je veux que le système de fichiers
<code>/mn/eris/local</code> qui est sur la machine
<code>eris</code> soit disponible sur la machine
<code>apollon</code>. Je l'indique dans <code>/etc/exports</code>
sur eris :</p>
<hr>
<pre>
/mn/eris/local  apollon(rw)
</pre>
<hr>
<p>La ligne ci-dessus donne à <code>apollon</code> un accès en
lecture/écriture sur <code>/mn/eris/local</code>. Au lieu de
<code>rw</code> on pourrait mettre <code>ro</code> pour <em>read
only</em> (lecture seule, c'est la valeur par défaut). D'autres
options existent, et je parlerai de quelques unes liées à la
sécurité plus loin. Elles sont toutes décrites dans la page de
manuel <code>exports</code> qu'il faut lire au moins une fois dans
sa vie. Il y a de meilleures façons de faire que de lister tous les
hosts dans le fichier exports. Peuvent être autorisés à monter un
système de fichiers NFS, des groupes réseaux (<em>net groups</em>)
si vous utilisez NIS (ou NYS, auparavant connu sous le nom YP), des
noms de domaines avec jokers et des sous réseaux IP. Mais il faudra
vérifier qui peut obtenir un accès au serveur avec ce type
d'autorisations groupées.</p>
<p>Note : ce fichier exports n'utilise pas la même syntaxe que
d'autres Unix. Ce HOWTO contient une section sur la façon dont les
autres Unix <code>export</code>ent leurs fichiers.</p>
<p>Maintenant nous sommes prêts à lancer mountd (ou peut-être
s'appelle-t-il <code>rpc.mountd</code>), puis nfsd (qui s'appelle
peut-être <code>rpc.nfsd</code>). Ils liront tous deux le fichier
exports.</p>
<p>Si vous modifiez <code>/etc/exports</code>, vous devrez vous
assurer que nfsd et mountd savent que le fichier a changé. La façon
traditionnelle est de lancer <code>exportfs</code>. Beaucoup de
distributions Linux n'ont pas le programme exportfs. Si c'est le
cas sur votre machine, vous pouvez installer ce script :</p>
<hr>
<pre>
#!/bin/sh
killall -HUP /usr/sbin/rpc.mountd
killall -HUP /usr/sbin/rpc.nfsd
echo Volumes NFS réexportés
</pre>
<hr>
<p>Sauvez le dans <code>/usr/sbin/exportfs</code> par exemple, et
n'oubliez pas de lui appliquer <code>chmod a+rx</code>. Désormais,
chaque fois que vous changez votre fichier exports, lancez ensuite
exportfs en root.</p>
<p>Maintenant, vérifiez que mountd et nfsd fonctionnent
correctement. D'abord avec <code>rpcinfo -p</code>. Il devrait
donner quelque chose du genre :</p>
<hr>
<pre>
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp    745  mountd
    100005    1   tcp    747  mountd
    100003    2   udp   2049  nfs
    100003    2   tcp   2049  nfs
</pre>
<hr>
<p>On voit que le portmapper a annoncé ses services, de même que
mountd et nfsd.</p>
<p>Si vous obtenez : <code>rpcinfo: can't contact portmapper: RPC:
Remote system error - Connection refused</code>,
<code>RPC_PROG_NOT_REGISTERED</code> ou quelque chose du style
c'est que le portmapper ne tourne pas. OU, vous avez quelques chose
dans <code>/etc/hosts.{allow,deny}</code> qui interdit au
portmapper de répondre, voyez <a href="#nfs-security">la section
sécurité</a> à ce propos. Si vous obtenez <code>No remote programs
registered</code> alors soit le portmapper ne veut pas vous parler,
soit quelque chose ne marche pas. Tuez nfsd, mountd et le
portmapper et essayez de recommencer.</p>
<p>Après avoir vérifié que le portmapper rend compte des services
vous pouvez vérifier aussi avec <code>ps</code>. Le portmapper
continuera à afficher les services même si les programmes qui les
offrent ont crashé. Il vaut donc mieux vérifier par ps si quelque
chose ne marche pas.</p>
<p>Bien sur, vous devrez modifier vos fichiers systèmes rc pour
lancer mountd et nfsd au démarrage de la même façon que le
portmapper. Il y a de très fortes chances que les scripts existent
déjà sur votre machine, vous aurez juste à décommenter les bonnes
lignes ou les activer pour les bons <em>runlevels</em> (pardon
niveaux d'exécution) d'init.</p>
<p>Quelques pages de manuel avec lesquelles vous devriez être
familier : portmap, mountd, nfsd et exports.</p>
<p>Bon, si vous avez tout fait exactement comme j'ai dit vous êtes
prêts à enchaîner sur le client NFS.</p>
<h2><a name="nfs-client"></a> <a name="s4">4. Installer un client
NFS</a></h2>
<p>Tout d'abord il faudra compiler un noyau avec le système de
fichiers NFS, soit compilé dans le noyau, soit disponible sous
forme de module. Si vous n'avez encore jamais compilé un noyau vous
aurez peut être besoin de consulter le HOWTO du noyau. Si vous
utilisez une distribution très cool (comme Chapeau Rouge) et que
vous n'avez jamais trifouillé le noyau (pas toucher toucher) il y a
des chances que NFS soit automagiquement disponible.</p>
<p>Vous pouvez maintenant, à l'invite (prompt) du root, entrer la
commande <code>mount</code> appropriée et le système de fichiers
apparaîtra. Continuons avec l'exemple de la section précédente,
nous voulons monter <code>/mn/eris/local</code> depuis eris. La
commande est :</p>
<hr>
<pre>
mount -o rsize=1024, wsize=1024 eris:/mn/eris/local /mnt
</pre>
<hr>
<p>Nous reviendrons plus tard sur les options rsize et wsize. Le
système de fichiers est maintenant disponible sous /mnt et vous
pouvez faire un cd sur lui, puis un ls et regarder les fichiers
individuellement. Vous remarquerez que ce n'est pas aussi rapide
qu'avec un système de fichiers local, mais beaucoup plus pratique
que ftp. Si, au lieu de monter le système de fichiers, mount
renvoie un message d'erreur comme <code>mount: eris:/mn/eris/local
failed, reason given by server: Permission denied</code> alors le
fichier exports est incorrect, ou vous avez oublié de lancer
exportfs après avoir modifié le fichier exports. S'il dit
<code>mount: clntudp_ipdate: RPC: Program not registered</code>
cela signifie que nfsd ou mountd ne tourne pas sur le serveur, ou
que vous avez le problème avec les fichiers
<code>hosts.{allow,deny}</code> mentionné plus haut.</p>
<p>Pour vous débarrasser du système de fichiers, vous pouvez faire
:</p>
<hr>
<pre>
umount /mnt
</pre>
<hr>
<p>Pour que le système monte automatiquement un système de fichiers
NFS au démarrage, éditez <code>/etc/fstab</code> de la façon
habituelle. Par exemple avec une ligne comme celle-ci :</p>
<hr>
<pre>
# device       mountpoint    fs-type    options           dumps  sfckorder
...
eris:/mn/eris/local   /mnt   nfs     rsize=1024,wsize=1024   0   0
...
</pre>
<hr>
<p>C'est presque tout ce qu'il y a à savoir. Vous pouvez jeter un
coup d'oeil à la page de manuel <code>nfs</code>. Continuons
plize.</p>
<h2><a name="ss4.1">4.1 Options de montage</a></h2>
<p>Il y a trois comportements principaux des clients NFS en cas de
chute du serveur qui sont spécifiés par les options de montage
:</p>
<dl>
<dt><b>soft</b></dt>
<dd>
<p>Le client NFS renverra une erreur au processus concerné si après
quelques essais le serveur NFS persiste à ne pas répondre. Si vous
voulez utiliser cette option, vous devez vérifier que votre
logiciel la gère correctement. Je ne recommande pas ce réglage,
c'est un bon moyen de perdre des données et corrompre des fichiers.
En particulier, n'utilisez pas ça pour les disques où sont stockés
vos mails (si vous tenez à vos mails).</p>
</dd>
<dt><b>hard</b></dt>
<dd>
<p>Le client NFS réessaiera infiniment jusqu'à ce qu'il soit tué.
Les opérations reprendront normalement si le serveur NFS se
rétablit ou redémarre. Le client ne pourra pas être interrompu ou
tué.</p>
</dd>
<dt><b>hard,intr</b></dt>
<dd>
<p>Comme hard, mais Ctrl-C tuera le processus bloqué. Dans quelques
cas, notament un disque /usr/spool/mail monté par NFS cela ne
changera rien car le shell ignore le Ctrl-C quand il teste si vous
avez du mail. Je recommande cette option pour <b>tous</b> les
systèmes de fichiers NFS, y compris le <em>spool</em> du mail.</p>
</dd>
</dl>
<p>Reprenons l'exemple précédent, votre entrée fstab est maintenant
:</p>
<hr>
<pre>
# device       mountpoint   fs-type    options            dumps  sfckorder
...
eris:/mn/eris/local   /mnt  nfs   rsize=1024,wsize=1024,hard,intr 0   0
...
</pre>
<hr>
<h2><a name="optimizing"></a> <a name="ss4.2">4.2 Optimisation de
NFS</a></h2>
<p>Normalement, si les options rsize et wsize ne sont pas
précisées, NFS écrira et lira par blocs de 4096 ou 8192 octets.
Mais certaines combinaisons de noyau Linux et cartes réseau ne
peuvent pas fonctionner avec ces valeurs, de plus, même si cela
marche, cela peut ne pas être optimal du tout. Il nous faudra donc
expérimenter et trouver les valeurs de rsize et wsize qui
fonctionnent et donnent les transferts les plus rapides. Vous
pouvez tester la vitesse obtenue avec différentes valeurs des
options avec des commandes simples. La commande mount ci-dessus
ayant été exécutée, si vous avez l'accès en écriture sur le disque
vous pouvez tester les performances en écriture séquentielle :</p>
<hr>
<pre>
time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096
</pre>
<hr>
<p>Ceci crée un fichier de 64 Mo ne contenant que des 0. Faites le
quelques (5-10?) fois et prenez la moyenne des temps. C'est le
temps `elapsed' ou `wall clock' qui est le plus intéressant.
Ensuite vous pouvez tester les performances en lecture en relisant
le fichier :</p>
<hr>
<pre>
time dd if=/mnt/testfile of=/dev/null bs=16k
</pre>
<hr>
<p>faites le quelques fois et prenez la moyenne. Puis démontez
(<code>umount</code>) et remontez (<code>mount</code>) avec des
valeurs plus grandes pour rsize et wsize. Il vaut mieux prendre des
multiples de 1024, et probablement pas plus grand que 16384 octets,
car les gros blocs ralentissent les accès aléatoires. Immédiatement
après avoir re<code>mount</code>é avec une taille supèrieure,
placez vous (<code>cd</code>) dans le système de fichiers et faites
des trucs comme ls, explorez un peu pour vérifier que tout est bien
normal. Si la valeur de rsize/wsize est trop grande, les symptômes
sont <em>vraiment</em> bizarres et pas évidents. Un symptôme
typique est une liste de fichiers donnée par <code>ls</code>
incomplète sans aucun message d'erreur. Ou la lecture de fichier
qui échoue mystérieusement et sans message d'erreur. Après vous
être assurés que les wsize/rsize choisis fonctionnent, vous pouvez
faire les tests de rapidité. Différentes plateformes de serveur
auront peut-être des tailles optimales différentes. SunOS et
Solaris sont réputés pour être beaucoup plus rapides avec une
taille de 4096 octets.</p>
<p>Les noyaux Linux récents (depuis 1.3) font parfois des lectures
anticipées (<em>read ahead</em>) pour des rsizes supérieurs ou
égaux à la taille de page de la machine. Sur les processeurs Untel
la taille de la page est de 4096 octets. La lecture anticipée
augmentera <em>sensiblement</em> les performances en lecture. Sur
une machine Untel on devrait donc choisir un rsize de 4096 si c'est
possible.</p>
<p>Un truc pour augmenter les performances d'écriture de NFS est
d'invalider les écritures synchrones sur le serveur. Les
spécifications de NFS disent que les requêtes d'écriture de NFS ne
doivent pas être considérées comme terminées avant que les données
ne soient sur un médium non versatile (normalement le disque). Ceci
réduit les performances à l'écriture, les écritures asynchrones
sont plus rapides. Le nfsd Linux ne fait pas d'écritures synchrones
car l'implémentation du système de fichiers ne s'y prête pas, mais
sur les serveurs non Linux vous pouvez augmenter les performances
de cette façon dans votre fichier exports :</p>
<hr>
<pre>
/dir    -async, access=linuxbox
</pre>
<hr>
<p>ou quelque chose du genre. Référez vous à la page de manuel
exports de la machine concernée. Notez que ceci augmente les
risques de perte de données.</p>
<h2><a name="slow-lines"></a> <a name="s5">5. NFS sur les lignes à
faible débit</a></h2>
<p>Les lignes lentes (à faible débit) comprennent les modems, RNIS
et aussi sans doute les autres connexions longue distance.</p>
<p>Cette section est basée sur la connaissance des protocoles
utilisés mais pas sur des expérimentations. Faites moi savoir si
vous essayez ceci ;-)</p>
<p>La première chose à retenir est que NFS est un protocole lent.
Il a un grand <em>overhead</em> (sur-coût en bande passante).
Utiliser NFS, c'est presque comme utiliser kermit pour transférer
des fichiers. Il est <em>lent</em>. Presque tout est plus rapide
que NFS. FTP est plus rapide. HTTP est plus rapide. rcp est plus
rapide. ssh est plus rapide.</p>
<p>Vous voulez toujours l'essayer ? Ok.</p>
<p>Par défaut NFS est paramétré pour des lignes rapides et à faible
latence. Si vous utilisez les paramètres par défaut sur des lignes
à grande latence cela peut provoquer des erreurs, des annulations,
des rétrécissements de fichiers, et des comportements bizarres.</p>
<p>La première chose à faire est de ne <em>pas</em> utiliser
l'option de montage <code>soft</code>. Les temporisations
retourneront des erreurs au logiciel, qui, dans l'immense majorité
des cas, ne saura pas quoi en faire. C'est une bonne façon d'avoir
des problèmes bizarres. Utilisez plutôt l'option de montage
<code>hard</code>. Quand <code>hard</code> est actif les
temporisations déclenchent des essais infinis au lieu d'annuler ce
que le logiciel était en train de faire (quoi que ce soit). C'est
ce que vous voulez. Vraiment.</p>
<p>La deuxième chose à faire est d'ajuster les options de montage
<code>timeo</code> et <code>retrans</code>. Elles sont décrites
dans la page de manuel nfs(5), en voici un extrait (version
française) :</p>
<hr>
<pre>
       timeo=n        La valeur,  en  dixiemes  de  secondes,  du
                      delai   avant  de  declencher  la  premiere
                      retransmission d'une RPC.   La  valeur  par
                      defaut  est 7/10 de seconde. Apres une pre�
                      miere expiration, le delai  est  double  et
                      l'on recommence les retransmissions jusqu'a
                      ce que le delai atteigne la valeur maximale
                      de 60 secondes, ou que le nombre maximal de
                      retransmission soit depasse.  Il se produit
                      alors  une  erreur  d'expiration majeure de
                      delai.  Si le systeme est monte  "en  dur",
                      les  retransmissions  reprendront a nouveau
                      indefiniment.

                      On peut ameliorer les performances en  aug�
                      mentant  le delai sur un  reseau charge, si
                      le serveur est un  peu  lent,  ou  si  l'on
                      traverse plusieurs routeurs ou passerelles.

       retrans=n      Le  nombre  d'expirations  mineures  et  de
                      retransmissions  qui  doivent  se  produire
                      avant de declencher une expiration majeure.
                      La  valeur  par  defaut  est  3 expirations
                      mineures.  Quand  une  erreur  d'expiration
                      majeure  se  produit,  soit l'operation est
                      abandonnee, soit  un  message  "server  not
                      responding" est affiche sur la console.
</pre>
<hr>
<p>En d'autres mots : si une réponse n'est pas reçue avant la
temporisation de 0,7 seconde (700 ms), le client NFS répétera la
requête et doublera la temporisation à 1,4 seconde. Si la réponse
n'arrive pas dans les 1,4 seconde, la requête est répétée à nouveau
et la temporisation est doublée à 2,8 secondes.</p>
<p>La vitesse de la ligne peut être mesurée avec un ping ayant vos
valeurs de rsize/wsize comme taille de paquet.</p>
<hr>
<pre>
$ ping -s 8192 lugulbanda
PING lugulbanda.uio.no (129.240.222.99): 8192 data bytes
8200 bytes from 129.240.222.99: icmp_seq=0 ttl=64 time=15.2 ms
8200 bytes from 129.240.222.99: icmp_seq=1 ttl=64 time=15.9 ms
8200 bytes from 129.240.222.99: icmp_seq=2 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=3 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=4 ttl=64 time=15.0 ms

--- lugulbanda.uio.no ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 14.9/15.1/15.9 ms
</pre>
<hr>
<p>Le temps indiqué est celui que le paquet du ping a pris pour
aller et revenir de lugulbanda. 15 ms, c'est assez rapide. Sur une
ligne à 28 800 bps vous pouvez vous attendre à une valeur de
l'ordre de 4000-5000 ms, et si la ligne est chargée ce temps sera
encore plus élevé, facilement le double. En général, la latence
augmente avec la taille des paquets et la charge de la ligne. Si
vous comptez utiliser FTP et NFS en même temps il faudra mesurer
les temps du ping pendant un transfert FTP et augmenter
<code>timeo</code> en accord avec la latence de votre ligne.</p>
<h2><a name="nfs-security"></a> <a name="s6">6. NFS et la
sécurité</a></h2>
<p>Je ne suis en aucun cas un expert en sécurité informatique. Mais
j'ai traîné dans le secteur et j'ai un <em>petit</em> conseil pour
ceux qui se préoccupent de la sécurité. Mais attention. Ce n'est
pas absolument pas une liste complète des problèmes liés à NFS et
si vous pensez être en sécurité une fois que vous avez lu et mis en
pratique tout ceci alors j'ai un pilier de pont (presque neuf) à
vous vendre.</p>
<p>Cette section n'a probablement pas d'intérêt si vous êtes sur un
réseau <em>fermé</em> où vous avez confiance en tous les
utilisateurs, et que personne en qui vous n'avez pas confiance ne
peut obtenir un accès sur les machines du réseau. I.e., il ne
devrait y avoir aucun moyen de se connecter à votre réseau depuis
l'extérieur et il ne devrait être relié à aucun autre réseau où
vous n'avez pas confiance en tous les utilisateurs et en sa
sécurité. Vous pensez que je suis parano ? Pas du tout. C'est un
conseil de sécurité <em>de base</em>. Et rappelez-vous que c'est
juste le commencement. Un site <em>sûr</em> nécessite un
administrateur consciencieux et bien informé qui sait où trouver
l'information sur les problèmes de sécurité existants ou
potentiels.</p>
<p>Un problème de base de NFS est que le client, si on ne lui
demande pas le contraire, fera confiance au serveur NFS et vice
versa. Ça peut être mauvais. Cela signifie que si le compte root du
serveur est cassé (<em>broken into</em>) il peut être très facile
de casser le compte root du client. Et vice versa. Il y a quelques
moyens de gérer ce problème sur lesquels nous reviendrons.</p>
<p>Les documents consultatifs (<em>advisories</em>) du CERT sur NFS
sont une bonne source d'information, la plupart des problèmes (et
des solutions) évoquées ci-dessous sont traités dans ces documents.
Voyez <a href=
"ftp://ftp.cert.orf/01-README">ftp.cert.org:/01-README</a> pour une
liste à jour. En voici quelques-uns liés à NFS (il n'y a pas à ma
connaissance de version française) :</p>
<hr>
<pre>
CA-91:21.SunOS.NFS.Jumbo.and.fsirand                            12/06/91
     Vulnerabilities concerning Sun Microsystems, Inc. (Sun) Network
     File System (NFS) and the fsirand program.  These vulnerabilities
     affect SunOS versions 4.1.1, 4.1, and 4.0.3 on all architectures.
     Patches are available for SunOS 4.1.1.  An initial patch for SunOS
     4.1 NFS is also available. Sun will be providing complete patches
     for SunOS 4.1 and SunOS 4.0.3 at a later date.

CA-94:15.NFS.Vulnerabilities                                    12/19/94
     This advisory describes security measures to guard against several
     vulnerabilities in the Network File System (NFS). The advisory was
     prompted by an increase in root compromises by intruders using tools
     to exploit the vulnerabilities.

CA-96.08.pcnfsd                                                 04/18/96
     This advisory describes a vulnerability in the pcnfsd program (also
     known as rpc.pcnfsd). A patch is included.
</pre>
<hr>
<h2><a name="ss6.1">6.1 Sécurité du client</a></h2>
<p>Du côté client il y a quelques options de mount qui permettent
de ne pas faire trop confiance au serveur. L'option
<code>nosuid</code> interdit le démarrage de programmes suid depuis
le système de fichiers NFS. C'est une option à utiliser
systématiquement, car elle empêche le root du serveur de créer un
fichier suid sur le système de fichiers NFS, puis de se loger dans
le client en utilisateur et de lancer le programme suid pour
devenir root sur le client. Il est aussi possible d'interdire
l'exécution des fichiers du système de fichiers NFS avec l'option
<code>noexec</code>. Mais ceci est beaucoup moins utile que
<code>nosuid</code> car le système de fichiers contiendra très
probablement au moins <em>quelques</em> scripts ou programmes à
exécuter. Ces options se rentrent dans la colonne d'options, avec
<code>wsize</code> et <code>rsize</code>, séparées par des
virgules.</p>
<h2><a name="ss6.2">6.2 Sécurité du serveur : nfsd</a></h2>
<p>Du côté serveur on peut ne pas faire confiance au root du
client, avec l'option <code>root_squash</code> (rembarrage du root
:-) dans le fichier exports :</p>
<hr>
<pre>
/mn/eris/local apollon(rw, root_squash)
</pre>
<hr>
<p>Dans ce cas, si un utilisateur du client avec l'UID 0 essaye
d'accéder (en lecture, écriture ou effacement) au système de
fichiers, le serveur remplace l'UID par celui de l'utilisateur
`nobody' du serveur. Ceci signifie que l'utilisateur root du client
ne peut accéder/modifier les fichiers du serveur que seul le root
du serveur peut accéder/modifier. C'est bien, et vous aurez
probablement à utiliser cette option sur tous les systèmes de
fichiers que vous exportez. J'en entends un qui me dit : ``Mais
l'utilisateur root du client peut toujours utiliser 'su' pour
devenir n'importe qui et accéder à ses fichiers !'' Et là je
réponds : ``Oui, c'est comme ça, c'est Unix''. Ceci a une
conséquence importante : tous les fichiers et binaires importants
devraient appartenir à <code>root</code>, et pas <code>bin</code>
ou un compte autre que root, car le seul compte auquel le root du
client ne peut pas accéder est le compte root du serveur. Plusieurs
autres options permettant de ne pas faire confiance à qui ne vous
plait pas sont énumérées dans la page de manuel nfsd. Il y a aussi
des options pour rembarrer (<em>to squash</em>) des intervalles
d'UID ou GID.</p>
<p>Il est important aussi de s'assurer que nfsd vérifie que toutes
les requêtes viennent d'un port privilégié. S'il accepte les
requêtes de n'importe quel port du client, un utilisateur
quelconque peut exécuter un programme qu'il est facile de se
procurer sur l'Internet. Il parle le protocole NFS et pourra
prétendre être n'importe qui et être cru. Ça fait peur hein ? Le
nfsd Linux effectue cette vérification par défaut, sur d'autres
systèmes d'exploitation il faut la valider. Ça devrait être décrit
dans les pages du manuel de ce système.</p>
<p>Autre chose. N'exportez jamais un système de fichiers vers
`localhost' ou 127.0.0.1. Croyez-moi.</p>
<h2><a name="ss6.3">6.3 Sécurité du serveur : le
portmapper</a></h2>
<p>Le portmapper de base, en combinaison avec nfsd présente un
problème de conception qui rend possible de récupérer les fichiers
d'un serveur NFS sans avoir aucun privilège. Heureusement le
portmapper utilisé par la plupart des distributions Linux est
relativement sûr vis à vis de cette attaque, et peut être sécurisé
en configurant les listes d'accès au moyen de deux fichiers.</p>
<p>Toutes les distributions de Linux ne sont pas égales. Certaines
apparemment à jour n'incluent <em>pas</em> un portmapper sur, même
aujourd'hui, alors que le problème est connu depuis plusieurs
années. Au moins une distribution contient même la page de manuel
pour un portmapper sûr alors que le portmapper effectivement
installé n'est <em>pas</em> sûr. Pour déterminer simplement si
votre portmapper est le bon ou pas, lancez strings(1) et voyez s'il
lit les fichiers appropriés <code>/etc/hosts.deny</code> et
<code>/etc/hosts.allow</code>. Si votre portmapper est
<code>/usr/sbin/portmap</code> exécutez la commande <code>strings
/usr/sbin/portmap | grep hosts</code>. Sur ma machine cela donne
:</p>
<hr>
<pre>
/etc/hosts.allow
/etc/hosts.deny
@(#) hosts_ctl.c 1.4 94/12/28 17:42:27
@(#) hosts_access.c 1.20 96/02/11 17:01:27
</pre>
<hr>
<p>Tout d'abord, éditons <code>/etc/hosts.deny</code>. Il devrait
contenir la ligne :</p>
<hr>
<pre>
portmap: ALL
</pre>
<hr>
<p>qui refusera l'accès à <em>quiconque</em>. Maintenant qu'il est
fermé, lancez <code>rpcinfo -p</code> pour vérifier qu'il lit et se
conforme au contenu du fichier. rpcinfo ne devrait rien renvoyer,
ou peut être un message d'erreur. Il ne devrait <em>pas</em> y
avoir besoin de relancer le portmapper.</p>
<p>Fermer le portmapper à tous le monde est peut être un peu
excessif, nous ré-ouvrons donc quelque peu l'accès en éditant le
fichier <code>/etc/hosts.allow</code>. Mais il faut d'abord savoir
ce qu'on va y mettre. À la base, il devrait contenir les noms de
toutes les machines qui doivent avoir accès à votre portmapper. Sur
le système Linux moyen il y a très peu de machines qui ont une
bonne raison de demander cet accès. Le portmapper administre nfsd,
mountd, ypbind/ypserv, pcnfsd et les services ``en r'' comme
ruptime et rusers. Parmis ceux-ci, seuls nfsd, mountd,
ypbind/ypserv et peut-être pcnfsd ont de l'importance. Toutes les
machines qui ont besoin d'accéder à ces services sur votre machine
devraient y être autorisées. Disons que votre machine est
129.240.223.254 et que tout ce qui vit sur le sous réseau
129.240.223.0 doit pouvoir y accéder (si ceci n'est pas clair pour
vous, voyez le HOWTO réseau). On écrit :</p>
<hr>
<pre>
portmap: 129.240.223.0/255.255.255.0
</pre>
<hr>
<p>dans <code>hosts.allow</code>. C'est l'adresse de réseau que
vous donnez aussi à la commande <code>route</code> et le masque de
réseau que vous donnez à <code>ifconfig</code>. Pour le périférique
<code>eth0</code> sur cette machine <code>ifconfig</code> devrait
donner :</p>
<hr>
<pre>
...
eth0      Link encap:10Mbps Ethernet  HWaddr 00:60:8C:96:D5:56
          inet addr:129.240.223.254  Bcast:129.240.223.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:360315 errors:0 dropped:0 overruns:0
          TX packets:179274 errors:0 dropped:0 overruns:0
          Interrupt:10 Base address:0x320 
...
</pre>
<hr>
<p>et <code>netstat -rn</code> devrait donner :</p>
<hr>
<pre>
Kernel routing table
Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
...
129.240.223.0   0.0.0.0         255.255.255.0   U     0      0   174412 eth0
...
</pre>
<hr>
<p>(Adresse réseau dans la première colonne)</p>
<p>Les fichiers <code>hosts.deny</code> et <code>hosts.allow</code>
sont décrits dans les pages de manuel de mêmes noms.</p>
<p><b>IMPORTANT</b> : ne <em>rien</em> mettre d'autre que des
adresses IP (numériques) dans les lignes portmap de ces fichiers.
Les <em>host name lookup</em> (recherche d'adresse IP (numérique) à
partir de l'adresse alphanumérique ex. ftp.lip6.fr donne
132.227.77.2) peuvent indirectement déclencher une activité portmap
qui déclenchera un <em>host name lookup</em> qui déclenchera...</p>
<p>Ceci fait, votre serveur devrait être un peu plus solide. Le
dernier problème (mais oui !) est que quelqu'un casse le compte
root (ou boute MS-DOS) sur une machine de confiance et utilise ce
privilège pour envoyer des requêtes depuis un port sûr en se
faisant passer pour n'importe quel utilisateur.</p>
<h2><a name="ss6.4">6.4 NFS et les coupent-feu (firewalls)</a></h2>
<p>C'est une très bonne idée de bloquer les ports NFS et portmap
dans votre routeur ou firewall. nfsd utilise le port 2049, que ce
soit avec tcp ou udp. Le portmapper est au port 749 (tcp et udp) et
mountd aux port 745 et 747 (tcp et udp). Vérifiez les ports avec la
commande <code>rpcinfo -p</code>.</p>
<p>Si au contraire vous voulez que NFS traverse un firewall, il
existe des options sur les nfsd et mountd récents pour leur
spécifier le port à utiliser. Vous pouvez donc choisir un port qui
ne soit pas bloqué par le firewall.</p>
<h2><a name="ss6.5">6.5 Résumé</a></h2>
<p>Si vous configurez correctement votre installation
portmapper/NFS avec hosts.allow/deny, root_squash, nosuid et les
ports privilégiés, vous évitez beaucoup des bogues connues de NFS
et pouvez presque vous sentir en sécurité au moins pour
<em>ça</em>. Mais de toutes façons : quand un intrus obtient
l'accès à votre réseau, il/elle peut faire apparaître des commandes
bizarres dans votre .forward ou lire votre mail quand
<code>/home</code> ou <code>/var/spool/mail</code> sont exportés.
Pour la même raison, vous ne devriez jamais accéder à votre clé
privée PGP par NFS. Ou au moins vous devez savoir quel est le
risque. Et maintenant vous savez un peu.</p>
<p>NFS et le portmapper constituent un système complexe et il n'est
donc pas totalement exclu que de nouvelles bogues soient
découvertes, soit dans la conception soit dans l'implémentation que
nous utilisons. Il pourrait même y avoir des défauts de sécurité
connus, que quelqu'un utilise. Mais c'est la vie. Pour vous tenir
au courant, vous devriez au moins lire les forums
comp.os.linux.announce et comp.security.announce comme minimum
absolu (en français, consultez fr.comp.os.linux.annonces).</p>
<h2><a name="s7">7. ``Checklist'' mount</a></h2>
<p>Cette section est basée sur la <i>mount checklist</i> (liste des
problèmes liés à <code>mount</code>) de IBM Corp. Je les remercie
de m'autoriser à l'utiliser dans ce HOWTO. Si vous avez un problème
en montant un système de fichiers NFS, consultez cette liste avant
de poster votre problème sur les niouzes. Chaque point décrit un
type de problème et sa solution.</p>
<ol>
<li>Mount répète <code>RPC: Program not registered</code>
<p>Le portmapper tourne ?</p>
<p><b>Solution :</b> lancez-le.</p>
<p>mountd tourne ?</p>
<p><b>Solution :</b> lancez-le.</p>
<p>nfsd tourne ?</p>
<p><b>Solution :</b> lancez-le.</p>
<p><code>/etc/hosts.deny</code> empêche le portmapper de répondre
?</p>
<p><b>Solution :</b> vous pouvez enlever la règle en question dans
<code>hosts.deny</code> ou en ajouter une dans
<code>hosts.allow</code> de façon que le portmapper soit autorisé à
vous parler.</p>
</li>
<li>Système de fichier non exporté, ou non exporté au client en
question.
<p><b>Solution :</b> exportez le [Ndt : merci IBM !]</p>
</li>
<li>La résolution de noms ne s'accorde pas avec la liste des
exports.
<p>e.g.: la liste des exports dit d'exporter vers
<code>johnmad</code> mais le nom de <code>johnmad</code> est résolu
en <code>johnmad.austin.ibm.com</code>. La permission de monter est
refusée.</p>
<p><b>Solution :</b> exportez vers les deux formes du nom.</p>
<p>Cela peut aussi arriver si le serveur a deux interfaces avec des
noms différents et que les exports n'en spécifient qu'un.</p>
<p><b>Solution :</b> exportez les deux interfaces.</p>
<p>Cela peut aussi se produire si le serveur ne peut pas faire un
lookuphostbyname ou lookuphostbyaddr (ce sont des fonctions de
bibliothèque) sur le client. Assurez-vous que le client peut faire
<code>host &lt;name&gt;</code>; <code>host &lt;ip_addr&gt;</code>;
et que les deux donnent la même machine.</p>
<p><b>Solution :</b> mettez de l'ordre dans la résolution de
noms.</p>
</li>
<li>Le système de fichiers a été monté après que NFS soit lancé
(sur ce serveur). Dans ce cas le serveur exporte le point de
montage sous-jacent, pas le système de fichiers.
<p><b>Solution :</b> éteignez nfsd et relancez le.</p>
<p><b>Note :</b> les clients qui avaient monté le point de montage
sous-jacent auront des problèmes pour y accéder après le
redémarrage.</p>
</li>
<li>La date est très décalée sur une ou sur les deux machines (cela
peut mettre la pagaille pour make)
<p><b>Solution :</b> réglez correctement la date.</p>
<p>L'auteur du HOWTO recommande d'utiliser NTP pour synchroniser
les horloges. Vu qu'il y a des restrictions à l'exportation (au
sens commercial !) de NTP aux É.U., vous devez vous procurer NTP
pour Debian, Redhat ou Slakware depuis
<code>ftp://ftp.hacktic.nl/pub/replay/pub/linux</code> ou un
miroir.</p>
</li>
<li>Le serveur ne peut pas utiliser un mount d'un utilisateur qui
est dans plus de 8 groupes. <b>Solution :</b> diminuez le nombre de
groupes auxquels l'utilisateur appartient ou montez depuis un autre
utilisateur.</li>
</ol>
<h2><a name="s8">8. FAQ</a></h2>
<p>Voici la section FAQ. Elle est en partie basée sur une vieille
FAQ NFS écrite par Alan Cox.</p>
<p>Si vous avez un problème pour monter un système de fichier,
voyez si votre problème est décrit dans la section ``Checklist
mount''.</p>
<ol>
<li>J'obtiens un tas d'erreurs ``stale nfs handle'' quand j'utilise
Linux comme serveur NFS.
<p>Cela est dû à une bogue dans quelques vieilles versions de nfsd.
Elle est corrigée à partir de nfs-server2.2beta16.</p>
</li>
<li>Quand j'essaye de monter le système de fichiers j'obtiens
<blockquote>
<pre><code>
    can't register with portmap: system error on send
    
</code></pre></blockquote>
<p>Vous utilisez probablement un système Caldera. Il y a une bogue
dans les scripts rc. Contactez Caldera pour obtenir la
solution.</p>
</li>
<li>Pourquoi ne puis-je pas exécuter un fichier après l'avoir copié
sur le serveur NFS ?
<p>La raison est que nfsd cache les manipulations de fichiers pour
des raisons de performances (rappelons qu'il fonctionne dans
l'espace utilisateur). Ainsi, après une écriture le fichier peut ne
pas être fermé tout de suite, et tant qu'il est ouvert le noyau ne
vous autorisera pas à l'exécuter. Les nfsd plus récents que le
printemps 95 [Ndt : hum...] ferment les fichiers ouverts après
quelques secondes, les plus vieux pouvaient ne pas les relâcher
avant plusieurs jours...</p>
</li>
<li>Mes fichiers NFS sont tous en lecture seule.
<p>Le serveur NFS Linux est par défaut en lecture seule. Voyez les
sections ``Mountd et nfsd'' et ``Exporter des systèmes de fichier''
dans ce HOWTO et référez vous aux pages de manuel ``exports'' et
``nfsd''. Vous devrez modifier <code>/etc/exports</code>.</p>
</li>
<li>Je monte depuis un serveur NFS Linux, <code>ls</code> marche et
pourtant je ne peux pas lire ou écrire de fichiers.
<p>Sur les anciennes versions de Linux il faut monter un serveur
NFS avec <code>rsize=1024, wsize=1024</code>.</p>
</li>
<li>Je monte depuis un serveur NFS Linux avec une taille de bloc
comprise entre 3500 et 4000 et Linux crashe régulièrement.
<p>Bah alors ne le faites pas. Cela ne se produit pas avec les
noyaux 2.0 et 2.2 ni, autant que je sache avec les 1.2.</p>
</li>
<li>Est-ce que Linux peut utiliser NFS sur TCP ?
<p>Non, pas pour le moment.</p>
</li>
<li>J'ai des tonnes d'erreurs bizarres en essayant de monter depuis
un serveur Linux.
<p>Assurez-vous que vos utilisateurs sont dans 8 groupes au
maximum. C'est une limitation des vieux serveurs.</p>
</li>
<li>Quand je redémarre ma machine elle se bloque parfois en
essayant de démonter un serveur NFS bloqué (<em>hung</em>).
<p>Ne démontez <b>pas</b> les serveurs NFS en redémarrant ou
arrêtant la machine, ça ne créera pas de problèmes si vous ne le
faites pas. La commande est <code>umount -avt nonfs</code>.</p>
</li>
<li>Les clients NFS Linux sont très lents quand ils écrivent sur
des systèmes Sun ou BSD.
<p>Normalement les écritures NFS sont synchrones (vous pouvez le
désactiver si vous ne craignez pas de perdre des données). Les
noyaux dérivés de BSD ont tendance à ne pas savoir travailler avec
des petits blocs. Ainsi quand vous écrivez 4K de données depuis un
client Linux dans des paquets de 1K, BSD fait ceci :</p>
<blockquote>
<pre><code>
                lit une page de 4K
                traite 1K
                écrit 4K sur le disque
                lit une page de 4K
                traite 1K
                écrit 4K sur le disque
                ...
            
</code></pre></blockquote>
</li>
<li>Quand je connecte de nombreux clients à un serveur NFS Linux,
la performance diminue soudainement.
<p>Le protocole NFS utilise les paquets UDP fragmentés. Le noyau ne
conserve qu'un nombre limité de fragments de paquets incomplets
avant de commencer à jeter des paquets. En 2.2, ce paramètre est
réglable à l'exécution au moyen du système de fichier /proc :
<code>/proc/sys/net/ipv4/ipfrag_high_tresh</code> et
<code>ipfrag_low_tresh</code>. En 2.0 ce sont des constantes
définies à la compilation dans
<code>.../linux/net/ipv4/ip_fragment.c</code>,
<code>IPFRAG_HIGH_TRESH</code> et <code>IPFRAG_LOW_THRESH</code>.
La signification des ces valeurs est que quand la mémoire consommée
par les fragments UDP non réassemblés atteint
``ipfrag_high_thresh'' (en octets, 256K par défaut en 2.2.3 et
2.0.36) elle est ramenée à ``ipfrag_low_tresh'' d'un coup, en
jetant des fragments. Ainsi, si la borne supérieure (high_tresh)
est atteinte, la performance de votre serveur diminue
drastiquement.</p>
<p>256K est suffisant pour 30 clients. Si vous en avez 60, doublez
la valeur. Et doublez aussi la borne inférieure (low_tresh).</p>
</li>
<li>J'utilise Linux 2.2 (ou suivant) avec knfsd et ma machine AIX,
IRIX, Solaris, DEC-Unix, ... n'arrive pas à monter de volume.
<p>knfsd annonce qu'il implémente NFS version 3, alors que ce n'est
pas vrai. Utilisez l'option qui permet de stopper ces annonces, ou
mettez <code>"vers=2"</code> dans la liste d'options de montage de
votre client.</p>
</li>
<li>Ma machine AIX 4 n'arrive pas à monter depuis mon serveur NFS
Linux. Elle dit quelque chose du genre :
<blockquote>
<pre><code>
        mount: 1831-011 access denied for server:/dir
        mount: 1831-008 giving up on:
        server:/dir
        The file access permissions do not allow the specified action.
    
</code></pre></blockquote>
<p>AIX 4.2 utilise des ports réservés (&lt;1024) pour NFS. AIX
4.2.1 et 4.3 peuvent utiliser d'autres ports, et essaient de monter
par NFS3, NFS/TCP et finalement NFS/UDP.</p>
<p>Ajouter</p>
<hr>
<pre>
nfso -o nfs_use_reserved_ports=1
</pre>
<hr>
<p>à la fin de <code>rc.tcpip</code> la forcera à utiliser les
ports réservés (truc fourni par Brian Gorka).</p>
</li>
</ol>
<h2><a name="s9">9. Exporter un système de fichiers</a></h2>
<p>Bien sur, la façon d'exporter les systèmes de fichiers par NFS
n'est pas toujours la même sur toutes les plate-formes. Linux et
Solaris 2 sont les plus déviants. Cette section liste de manière
superficielle la façon de procéder sur la plupart des systèmes. Si
votre système n'est pas traité ici, cherchez dans vos pages de
manuel. Les mot-clés sont : nfsd, system administration tool, rc
scripts, boot scripts, boot sequence, /etc/exports, exportfs.
J'utiliserai le même exemple tout au long de cette section :
comment exporter /mn/eris/local vers apollon en
lecture/écriture.</p>
<h2><a name="ss9.1">9.1 IRIX, HP-UX, Digital-UNIX, Ultrix, SunOS 4
(Solaris 1), AIX</a></h2>
<p>Ces systèmes utilisent le format export traditionnel de Sun.
Dans <code>/etc/exports</code>, écrivez :</p>
<hr>
<pre>
/mn/eris/local -rw=apollon
</pre>
<hr>
<p>La documentation complète se trouve dans la page de manuel
<code>exports</code>. Après avoir édité le fichier, lancez
<code>exportfs -av</code> pour exporter les systèmes de
fichiers.</p>
<p>La rigueur de la syntaxe demandée par exportfs varie. Sur
certains systèmes vous verrez que la ligne précédente peut être
:</p>
<hr>
<pre>
/mn/eris/local apollon
</pre>
<hr>
<p>ou même quelque chose de dégénéré comme :</p>
<hr>
<pre>
/mn/eris/local rw=apollon
</pre>
<hr>
<p>Je recommande d'utiliser la syntaxe stricte. Il se peut que la
prochaine version de <code>exportfs</code> soit plus exigeante vis
à vis de la syntaxe et ne fonctionne plus.</p>
<h2><a name="ss9.2">9.2 Solaris 2</a></h2>
<p>Sun ont complètement réinventé la roue quand ils ont fait
Solaris 2, et donc c'est complètement différent des autres
systèmes. Il faut éditer le fichier <code>/etc/dfs/dfstab</code> et
y placer les commandes de partage (<em>share</em>) documentées dans
la page de manuel <code>share(1M)</code>, comme ceci :</p>
<hr>
<pre>
share -o rw=apollon -d "Eris Local" /mn/eris/local
</pre>
<hr>
<p>Lancez ensuite le programme <code>shareall</code> pour exporter
les systèmes de fichiers.</p>
<h2><a name="linuxtwotwo"></a> <a name="s10">10. NFS sous Linux
2.2</a></h2>
<p>Au moment où j'écris, la version courante du noyau est 2.2.12 et
utiliser NFS peut être assez pénible. Ou pas. J'ignore ce qu'il en
sera pour Linux 2.4.</p>
<p>La grosse nouveauté dans Linux 2.2 c'est le support d'un serveur
nfs dans le noyau, appelé knfsd 2.2. Ce type d'implémentation a des
avantages, principalement la rapidité, une machine Linux 2.2 avec
knfsd est un serveur NFS respectable. Vous pouvez cependant
toujours utiliser l'ancien nfsd avec Linux 2.2, et cela présente
quelques avantages aussi, dont la simplicité.</p>
<p>Si vous utilisez un paquetage noyau source ou binaire fabriqué
par quelqu'un comme RedHat (6.0 et suivantes), SuSE (6.1 et
suivantes il me semble) ou un autre intégrateur de système
professionnel ils auront probablement intégré complètement
``knfsd'' et vous n'avez pas de soucis à vous faire, cela marchera.
Pour l'essentiel. Jusqu'à ce que vous vouliez compiler un noyau
vous même. Si vous utilisez un noyau 2.2 standard (au moins jusqu'à
2.2.12) knfsd ne fonctionnera pas.</p>
<p>Pour le faire fonctionner vous même il vous faut le paquetage
knfsd de H.J. Lu. C'est un ensemble de patchs avec les utilitaires
requis pour 2.2 que Lu maintient bénévolement. Récupérez le depuis
votre miroir de noyau local, le site maître est <a href=
"ftp://ftp.kernel.org/pub/linux/devel/gcc/">ftp.kernel.org:/pub/linux/devel/gcc/</a>.
<b>Ce n'est pas destiné au grand public</b>. Si vous trouvez que
c'est trop compliqué, n'insistez pas et attentez qu'un paquetage
noyau soit disponible auprès de votre intégrateur (Redhat,
SuSE...).</p>
<p>Ne m'envoyez pas de question à ce sujet, je ne peux pas vous
aider, je n'ai aucun serveur basé sur knfsd qui tourne. Si vous
trouvez des erreurs ou omissions dans la documentation, écrivez-moi
et je corrigerai ce HOWTO.</p>
<p>Toujours là ? Ok. H.J. Lu annonce les nouvelles versions de son
paquetage sur la liste de diffusion linux-kernel, où il passe
d'autres choses liées à NFS dans Linux 2.2. Lisez-la.</p>
<h2><a name="ss10.1">10.1 Le client</a></h2>
<p>Le client est presque simple. Afin que les verrous
(<em>locks</em>) marchent correctement il faut que
<code>statd</code> (du paquetage knfsd) soit compilé, installé et
lancé depuis vos scripts de démarrage. Statd a besoin d'un
répertoire appelé <code>/var/lib/nfs</code> qu'il vous faudra créer
avant de le lancer (sans quoi il se termine immédiatement sans
message d'erreur).</p>
<p>Une fois que statd tourne vous pouvez utiliser le programme
<code>testlk</code> (dans <code>tools/locktest</code>) pour tester
si un verrou sur un fichier d'un volume monté par NFS fonctionne.
Ça devrait. S'il affiche <em>No locks available</em>, statd ne
fonctionne pas.</p>
<p>En fait, vous pouvez aussi vous passer des verrous (ce que je ne
recommande pas) en mettant <code>"nolock"</code> dans la liste des
options de montage.</p>
<p>Autant que je sache, c'est tout ce qu'il faut pour faire
fonctionner correctement le client.</p>
<p>Ah, si vous avez un serveur NFS Alpha ou Sparc vous verrez que
le client nfs de Linux 2.2 est vraiment de la merde. Les débits
sont extrêmement faibles, bien pire qu'avec Linux 2.0. Bien sur on
peut corriger le problème. Les noyaux 2.2 d'Alan Cox (un petit peu
plus expérimentaux que ceux de Linus) incluent un patch pour
améliorer la performance du client 2.2 avec un serveur Alpha ou
Sparc. Si vous voulez utiliser les noyaux d'Alan Cox, vous devriez
lire la liste de diffusion linux-kernel, et si c'est le cas vous
savez où les trouver. Le site de référence est <a href=
"http://www.uio.no/~trondmy/src/">http://www.uio.no/~trondmy/src/</a>,
au cas où vous voudriez essayer de l'appliquer à un noyau 2.2
standard. Ce patch ne sera probablement pas intégré dans Linux 2.4,
car il demande trop de changements dans le noyau pour être accepté
dans le cycle de développement actuel. Attendez Linux 2.5.</p>
<p><code>trondmy</code> propose des patchs pour utiliser NFS
version 3 avec Linux, et qui permettent aussi d'utiliser TCP comme
mécanisme de transport au lieu d'UDP. NFSv3 est très bien pour des
réseaux grande distance ou avec des taux de pertes non nuls, ou des
temps de latence élevés.</p>
<p>Si vous utilisez ces patchs, il vous faut lire linux-kernel, car
de sales bugs, qui mangent vos fichiers, sont parfois découverts.
Alors <b>soyez prudent</b>.</p>
<h2><a name="ss10.2">10.2 Le serveur</a></h2>
<p>Le serveur NFS de Linux 2.2 et suivants est appelé
<code>"knfsd"</code>. Il est difficile à configurer. Il faudra vous
débrouiller tout seul ou utiliser ce que SuSE, RedHat et autres
fournissent dans leurs paquetages 2.2. Désolé, mais vous pouvez
toujours utiliser l'ancien nfsd. Il est lent mais facile à
installer.</p>
<h2><a name="s11">11. Serveur NFS sur une disquette</a></h2>
<p>Cette section a été écrite par Ron Peters, <a href=
"mailto:rpeters@hevanet.com">rpeters@hevanet.com</a>. Elle explique
comment installer un serveur NFS en démarrant depuis une disquette.
L'objectif initial était de partager par NFS un cédérom d'une autre
machine pour installer Linux sur une machine sans lecteur de
cédérom.</p>
<h2><a name="ss11.1">11.1 Introduction</a></h2>
<p>Ce document a pour but d'aider ceux qui auront le même problème
que moi récemment. J'installais un serveur Linux sur une machine
sans lecteur de cédérom et sans moyen d'en installer un, à part
peut être un SCSI externe. Ce genre de situations sera sans doute
de plus en plus rare et ce document perdra donc de son intérêt,
mais j'aurais bien aimé l'avoir quand j'essayais d'installer ma
machine.</p>
<p>Vu que la machine n'avait pas de lecteur de cédérom, j'ai pensé
installer un serveur NFS pour Win95 afin de partager le lecteur de
cédérom juste le temps d'installer ma machine et de la mettre sur
le réseau. Je n'ai trouvé que deux produits (je ne citerai pas les
noms mais l'un est un freeware et l'autre avait une licence limitée
à 14 jours), l'un ne marcha pas ``clés en main'' et l'autre n'était
pas capable de gérer les conventions de nommage Linux suffisamment
bien pour mener à bien l'installation.</p>
<p>J'ai donc décidé d'essayer de redémarrer ma machine Win95 sous
Linux avec les disquettes boot/root et d'utiliser une disquette
supplémentaire pour installer un serveur NFS.</p>
<p>Cela a été remarquablement simple, la procédure est en fait
probablement plus simple que de lire cette introduction. Cependant,
je pense qu'il est intéressant de rassembler les information
nécessaires dans ce document.</p>
<h2><a name="ss11.2">11.2 Attentes</a></h2>
<p>J'ai utilisé les disquettes boot/root fournies dans une des
distributions de Slakware (InfoMagic developpers distributions). Le
noyau utilisé sur les disquettes était un 2.0.34, et les programmes
du serveur NFS venaient d'un serveur pour 2.0.30. J'ai toujours
utilisé la méthode d'installation Slakware, non pas qu'elle soit
plus facile ou meilleure ou pire, mais simplement qu'elle m'est
familière et que je n'ai jamais pris le temps d'apprendre à en
utiliser une autre.</p>
<p>Je ne pense pas qu'il puisse y avoir beaucoup de problèmes liés
à la version du système. Je recommanderais simplement d'utiliser un
système relativement récent, ce qui devrait être le cas si vous
utilisez les disquettes boot/root de la distribution à
installer.</p>
<h2><a name="ss11.3">11.3 Matériel nécessaire</a></h2>
<ul>
<li>Une machine et une disquette de boot supportant le réseau. La
machine devant jouer le rôle du serveur NFS doit avoir une carte
réseau reconnue pendant le démarrage. Pour plus d'informations,
voir le HOWTO sur le réseau (NET4-HOWTO).</li>
<li>Une deuxième disquette contenant rpc.portmap, rpc.mountd et
rpc.nfsd. Vous pouvez trouver facilement ces fichiers par un
ftpsearch sur le ouèbe.</li>
<li>Un cd (par exemple) Slakware (ou autre).</li>
</ul>
<h2><a name="ss11.4">11.4 Configuration du serveur</a></h2>
<h3>Démarrer le serveur NFS temporaire</h3>
<p>Démarrez la machine qui sera serveur NFS depuis la disquette de
démarrage et assurez-vous que la carte réseau est reconnue, de même
que le lecteur de cédérom. Dans la suite je suppose que la carte
réseau en question est eth0.</p>
<h3>Monter la disquette et le cédérom</h3>
<p>Une fois que le système est démarré, vous n'avez plus besoin des
disquette boot/root, le système étant complètement installé en
disque mémoire. Remplacez la disquette root par la disquette
supplémentaire, et montez la :</p>
<p><code>mount /dev/fd0 /floppy</code></p>
<p>Ceci fonctionne pour une disquette avec un système de fichiers
ext2. J'imagine que la disquette pourrait utiliser un système de
fichiers MSDOS mais je n'ai pas essayé. Je suppose que cela serait
plus simple que de faire une image disque. Dans ce cas, il faudrait
utiliser <code>mount -t msdos ...etc</code>.</p>
<p>Montez le cédérom :</p>
<p><code>mount -t iso9660 /dev/hdc /cdrom</code></p>
<p>J'ai utilisé les périphériques disquette et cédérom, on peut en
utiliser d'autres selon ce que l'on veut faire. Les points de
montage /floppy et /cdrom doivent exister sur l'image de la
disquette root. Si ce n'est pas le cas, créez-les, ou bien vous
pouvez utiliser n'importe quels autres points de montage.</p>
<h3>Configurer le réseau sur le serveur provisoire</h3>
<p>Il faut maintenant configurer le serveur NFS et le réseau. Il
n'y a que quelques commandes à lancer, et quelques informations
qu'il vous faudra rassembler auparavant (je donne ici des valeurs
d'exemple) :</p>
<p>IPADDR:172.16.5.100 #L'adresse du serveur temporaire.</p>
<p>NETMASK:255.255.255.0 #Le masque de réseau (netmask).</p>
<p>BROADCAST:172.16.5.255 #L'adresse de diffusion sur le réseau</p>
<p>ETHNETWORK:172.16.5.0 #L'adresse réseau</p>
<p>GATEWAY:172.16.5.251 #Nécessaire seulement si vous avez une
passerelle. Si c'est le cas, vous le savez. La plupart des réseau
``à la maison'' n'en ont pas.</p>
<p>Les commandes pour se connecter au réseau (utiliser les valeurs
données ci-dessus) :</p>
<p><code>ifconfig eth0 inet IPADDR arp netmask NETMASK broadcast
BROADCAST</code></p>
<p><code>route add -net ETHNETWORK netmask NETMASK eth0</code></p>
<p>Celle-ci uniquement si vous avez une passerelle et que vous
devrez la traverser :</p>
<p><code>route add default gw GATEWAY netmask 0.0.0.0
eth0</code></p>
<p>Si tout va bien, vous êtes maintenant sur le réseau et devriez
pouvoir faire des <code>ping</code> sur les autres machines.</p>
<h3>Configurer le volume NFS</h3>
<p>Choisissez le répertoire à partager. Dans mon exemple, c'était
<code>/cdrom/slakware</code>. Placez-le dans le fichier
<code>/etc/exports</code> :</p>
<p><code>echo "/cdrom/slakware" &gt; /etc/exports</code></p>
<h2><a name="ss11.5">11.5 Lancer le serveur NFS</a></h2>
<p>Allez dans <code>/floppy/usr/bin</code> et lancez :</p>
<p><code>./rpc.portmap</code></p>
<p><code>./rpc.mountd</code></p>
<p><code>./rpc.nfsd</code></p>
<h3>Prêt, commencez l'installation</h3>
<p>Normalement, le répertoire <code>/cdrom/slakware</code> est
maintenant partageable. Démarrez votre machine (celle à installer)
depuis les disquettes boot/root (j'ai utilisé les mêmes qui ont
servi à démarrer le serveur) et commencez l'installation.</p>
<p>Quand il faut choisir le média source à utiliser, choisissez
``serveur NFS''. Il vous demandera l'adresse IP du serveur, qui est
celle que vous avez appelé IPADDR pour le serveur. Il vous faut
aussi donner le répertoire à monter, qui est celui que vous avez
indiqué dans le fichier <code>/etc/exports</code> du serveur.</p>
<p>Le volume NFS devrait maintenant être monté, surveillez
l'apparition de messages d'erreur. Si tout va bien, continuez
l'installation.</p>
<h2><a name="ss11.6">11.6 Problèmes</a></h2>
<h3>Rien ici pour l'instant</h3>
<p>Je n'ai rien à dire à ce sujet pour le moment. Peut être si des
gens utilisent cette procédure, on aura des choses à ajouter.</p>
<h2><a name="ss11.7">11.7 À faire</a></h2>
<h3>Disquette DOS</h3>
<p>Voir si la disquette supplémentaire peut être au format DOS.</p>
<h3>Commandes RPC</h3>
<p>Vérifiez l'ordre dans lequel lancer les commandes rpc.* et si
toutes sont nécessaires.</p>
<h2><a name="s12">12. PC-NFS</a></h2>
<p>Vous ne voulez pas utiliser PC-NFS, mais plutôt samba.</p>
<p>Samba est bien meilleur que PC-NFS, il fonctionne avec
``Windows3 for Workgroups'' et les versions suivantes de Windows.
Il est plus rapide et plus sur. Utilisez plutôt samba.</p>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / NFS-HOWTO.html
