<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//FR">
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="lfparser_2.8">
<META NAME="LFCATEGORY" CONTENT="System Administration">
<TITLE>lf164, System Administration: NFS - Network File System</TITLE>
<!-- stylesheet added by lfparser: -->
<style type="text/css">
<!--
pre { font-familiy:monospace,Courier }
-->
</style>
</HEAD>
<BODY bgcolor="#ffffff" text="#000000">
<!-- this is generated html code. NEVER use this file for your
translation work. Instead get the file with the same article number
and .meta.shtml in its name. Translate this meta file and then
use lfparser program to generate the final article -->
<!-- lfparser can be obtained from http://main.linuxfocus.org/~guido/dev/lfparser.html -->
<!-- 2pdaIgnoreStart -->
<MAP name="top">
<AREA shape="rect" coords="367,9,418,30" alt="Sommaire" href="../index.shtml">
<AREA shape="rect" coords="423,9,457,30" alt="Carte" href="../map.html">
<AREA shape="rect" coords="463,9,508,30" alt="Index" href="../Themes/index.html">
<AREA shape="rect" coords="514,9,558,30" alt="Recherche" href="../Search/index.html">
</MAP>
<MAP name="bottom">
<AREA shape="rect" coords="78,0,163,15" alt="Nouvelles" href="../News/index.shtml">
<AREA shape="rect" coords="189,0,284,15" alt="Archives" href="../Archives/index.html">
<AREA shape="rect" coords="319,0,395,15" alt="Liens" href="../Links/index.html">
<AREA shape="rect" coords="436,0,523,15" alt="A propos" href="../aboutus.html">
</MAP>
<!-- IMAGE HEADER -->
<CENTER>
<IMG src="../../common/images/Topbar-fr.gif" width="600" height="40" border="0" alt="[Barre Superieure]" ismap usemap="#top" ><BR>
<IMG src="../../common/images/Bottombar-fr.gif" width="600" height="21" border="0" alt="[Barre Inferieure]" ismap usemap="#bottom">
</CENTER>
<!-- SSI_INFO -->
<!-- tr_staticssi include virtual -->
<!-- tr_staticssi exec cmd -->
<!-- addedByLfdynahead ver 1.1 --><TABLE ALIGN="right" border=0><TR><TD ALIGN="right"><FONT SIZE="-1" FACE="Arial,Helvetica">Cet article est disponible en: <A href="../../English/November2000/article164.shtml">English</a> <A href="../../Castellano/November2000/article164.shtml">Castellano</a> <A href="../../Deutsch/November2000/article164.shtml">Deutsch</a> <A href="../../Francais/November2000/article164.shtml">Francais</a> <A href="../../Nederlands/November2000/article164.shtml">Nederlands</a> <A href="../../Russian/November2000/article164.shtml">Russian</a> <A href="../../Turkce/November2000/article164.shtml">Turkce</a> </FONT></TD></TR></TABLE><br>
<!-- 2pdaIgnoreStop -->
<!-- SHORT BIO ABOUT THE AUTHOR -->
<TABLE ALIGN=LEFT BORDER=0 hspace=4 vspace=4 WIDTH="30%" >
<TR>
<TD>
<!-- 2pdaIgnoreStart -->
<!-- PALM DOC -->
<TABLE BORDER=0 hspace=4 vspace=4> <TR> <TD>
<font size=1> <img src="../../common/images/2doc.gif" width=34 align=left border=0 height=22 alt="convert to palm"><a href="http://cgi.linuxfocus.org/cgi-bin/2ztxt">Convert to GutenPalm</a><br>or <a href="http://cgi.linuxfocus.org/cgi-bin/2pda">to PalmDoc</a></font>
</TD> </TR> </TABLE>
<!-- END PALM DOC -->
<!-- 2pdaIgnoreStop -->
<br>
<img SRC="../../common/images/Frederic_Raynal.png" >
<BR>par <a href="mailto:pappy@users.sourceforge.net">Frédéric Raynal</a>
<BR><BR>
<I>L´auteur:</I><BR>
<P><a href="mailto:frederic.raynal@inria.fr">Frédéric Raynal</a>
prépare une thèse en informatique sur le tatouage d'images
à l'<a href="http://www.inria.fr">INRIA</a>. Il lit un très
bon roman policier qui met en scène Th. Roosevelt au début du siècle
alors qu'il était préfet de police. L'ambiance est très sombre. Il
s'agit d'une enquête d'un groupe de personnes pour
retrouver un tueur en série qui s'attaque à des enfants. Ce groupe
s'appuie sur des techniques nouvelles (psychologies, empreintes
digitales, etc...) pour parvenir à ces fins. Ce roman de
de Caleb Carr, L'ange des ténèbres, dresse un portrait surprenant du
début du siècle.
<BR><i>Sommaire</i>:
<UL>
<LI><A HREF="#lfindex0">
Le serveur</A></LI>
<LI><A HREF="#lfindex1">
Le client</A></LI>
<LI><A HREF="#lfindex2">
Les précautions</A></LI>
<LI><A HREF="#lfindex3">
Références</A></LI>
<LI><A HREF="http://cgi.linuxfocus.org/cgi-bin/lftalkback?anum=164&lang=fr">Discussion sur cet article</A></LI>
</UL>
</TD></TR></TABLE>
<!-- HEAD OF THE ARTICLE -->
<H2>NFS - Network File System</H2>
<img src="../../common/images/illustration164.gif" width="100" heigth=100>
<!-- ABSTRACT OF THE ARTICLE -->
<P><i>Résumé</i>:
<P>
<P>Le <i>Network File System</i> (NFS) permet de gérer des fichiers
distribués sur plusieurs ordinateurs d'un réseau comme s'ils
étaient sur un disque dur local. Ainsi, l'utilisateur n'a plus à
se soucier de savoir où sont physiquement ses fichiers pour y accéder.
</P>
<HR size="2" noshade align="right"><BR>
<!-- BODY OF THE ARTICLE -->
<h1>Introduction</h1>
<P>NFS permet très simplement de partager des données entre
plusieurs machines. Par exemple, un utilisateur qui se connecte sur un
réseau n'aura plus à se logger sur une machine précise
: via NFS, son <i>home directory</i> lui sera livré (on dit en fait
exporté) sur la machine où il se connecte.
<p>NFS n'est toutefois pas un protocole très performant et n'est
pas utilisable de manière confortable au travers une connexion par
modem. En revanche, sur un réseau local, son utilisation offre une
grande souplesse tant aux utilisateurs qu'aux administrateurs.
<p>Il faut néanmoins prendre quelques précautions par rapport
à ce service. En effet, permettre à n'importe qui d'écrire
des données sur son réseau n'est pas franchement conseillé
;-) Certaines mesures indispensables limitent les risques.
<p>Cet article commence donc par une très brève introduction
sur les systèmes de fichiers. Ensuite, nous verrons le fonctionnement
du protocole NFS. La partie suivante, moins théorique, détaillera
l'installation d'un serveur et d'un client NFS, ainsi que les précautions
minimum à prendre. Enfin, nous illustrerons dans un exemple, comment
combiner NFS, NIS et autofs.
<br>
<h1>
Présentation générale et non-exhaustive de la notion
de <i>système de fichiers</i></h1>
Avant de parler de NFS, il est nécessaire de bien comprendre la
notion de <i>système de fichiers</i>. Ce terme désigne la
manière dont les données sont stockées sur un support,
dont elles sont organisées et gérées. Il en existe
toute une pléthore, certains plus utilisés que d'autres (New
Technology FileSystem (NTFS), High Performance FileSystem (HPFS), DOS,
FAT 12/16/32, VFAT, Macintosh Hierarchical Filesystem (HFS), ISO 9660 (pour
les CD-ROM), extended filesystems (Ext, Ext2, Ext3), et encore de nombreux
autres).
<p>Par exemple, on peut envisager tout support physique de données
(un disque dur par exemple) comme un suite de petites cases contenant des
informations : on parle de <i>blocs</i> (<i>blocks</i> en Anglais). Chaque
système de fichiers gère ces blocs différemment. Par
exemple, dans la figure <a href="#frag">1</a> , on cherche à insérer
un fichier tenant sur 2 blocs. Dans l'illustration supérieure, le
fichier a été placé après le dernier bloc occupé,
laissant des espaces vides au début. A l'inverse, dans le schéma
inférieur, il a été placé au premier endroit
pouvant le contenir. Si le terme "fragmentation" vous évoque quelque
chose, vous savez maintenant ce qu'il représente ;-)
<br>
<br>
<br>
<br>
<center>
<p><img SRC="../../common/images/image164-1.png" height=387 width=461>
<br><a NAME="frag"></a>Fig. 1 : 2 politiques différentes pour insérer
des blocs</center>
<p><br>
<br>
<br>
<br>
<br>
<br>
<br>
<p>Le système de fichiers le plus commun sous Linux s'appelle <i>ext2fs</i>
(extended 2 file system). Chaque fichier y est représenté
par un <i>inode<a NAME="foot1" href="#foot1"></a></i><sup><a href="#foot1" NAME="foot1">1</a></sup>.
Les répertoires contiennent des listes de fichiers, l'accès
aux devices se fait par l'intermédiaire d'opérations de lecture/écriture
sur des fichiers particuliers.
<p>Le rôle d'un serveur NFS est donc de distribuer à ses clients
les inodes des fichiers auxquels ils veulent accéder. Toutefois,
le client ne pourrait fonctionner correctement s'il ne recevait que l'inode
de ces fichiers! Un serveur NFS offre donc une couche réseau supplémentaire
pour permettre à des machines distantes de manipuler ses inodes.
<br>
<h1>
Le protocole NFS</h1>
Ce que nous appelons communément NFS se compose en fait de 4 protocoles
distincts. Chacun repose sur les <i>Remote Procedure Calls
</i>(RPC) et
donc <font face="Courier New,Courier">portmap</font> (aussi appelé
<font face="Courier New,Courier">rpc.portmap</font>).
Rappelons que ce programme convertit les numéros de programmes RPC
en numéros de ports. Quand un serveur RPC démarre, il va
préciser à <font face="Courier New,Courier">portmap</font>
quel port il utilisera et les numéros de programmes RPC qu'il gère.
Quand un client souhaite envoyer une requête RPC vers un numéro
de programme donné, il contacte d'abord le serveur <font face="Courier New,Courier">portmap</font>
pour obtenir le numéro de port sur lequel tourne le programme souhaité.
Ensuite, il adresse les paquets RPC au port correspondant.
<p>Les 4 services permettant à NFS de fonctionner sont :
<br>
<br>
<table BORDER WIDTH="100%" NOSAVE >
<tr>
<td><b><font size=+1>Protocole</font></b></td>
<td>
<center><b><font size=+1>Description</font></b></center>
</td>
<td>
<center><b><font size=+1>Démon</font></b></center>
</td>
</tr>
<tr>
<td><b>nfs</b></td>
<td>Ce protocole est la base qui permet la création de fichier,
leur recherche, leur lecture ou leur écriture. Ce protocole gère
donc également l'authentification et les statistiques sur
les fichiers.</td>
<td>
<center>nfsd</center>
</td>
</tr>
<tr>
<td><b>mountd</b></td>
<td>Celui-ci s'occupe du montage des systèmes exportés auxquels
on accédera par <b>nfs</b>. Il envoie donc des requêtes de
type <font face="Courier New,Courier">mount</font> et <font face="Courier New,Courier">umount</font>
au serveur, qui doit donc conserver des informations sur les systèmes
de fichiers exportés (voir section sur XXX).</td>
<td>
<center>mountd</center>
</td>
</tr>
<tr>
<td><b>nsm</b>
<br>(Network Status Monitor) </td>
<td>Il sert à monitorer les noeuds du réseau pour connaître
l'état d'une machine (cliente ou serveur) pour signaler, par exemple,
qu'elle redémarre.</td>
<td>
<center>statd</center>
</td>
</tr>
<tr>
<td><b>nlm</b>
<br>(Network Lock Manager) </td>
<td>Pour éviter que des données soient altérées
par plusieurs clients en même temps, ce protocole gère un
système de locks (<i>serrure</i> ou <i>fermeture</i> en Anglais)
qui permettent de signaler les systèmes de fichiers utilisés.
Ainsi, à l'aide du protocole <b>nsm</b> qui sait quand un client
redémarre, il libère tous les locks du client avant de les
lui restituer si une nouvelle requête est émise.</td>
<td>
<center>lockd</center>
</td>
</tr>
</table>
<p>Le démon <font face="Courier New,Courier">knfsd</font>, disponible
avec les dernières versions du noyau, supporte directement les protocoles
<b>nfs</b>
et <b>nlm</b>. En revanche, <b>mountd</b> et <b>nsm</b> ne le sont pas
encore. Une fois le serveur NFS installé et démarré,
on peut vérifier que tout fonctionne ainsi :
<br>
<blockquote><font face="Courier New,Courier">>> ps auxwww | egrep "nfs|mount|lock|stat"</font>
<br><font face="Courier New,Courier">root
1370 0.0 0.2 1176 580 ?
S 22:28 0:00 rpc.mountd --no-nfs-version
3</font>
<br><font face="Courier New,Courier">root
1379 0.0 0.0 0 0
pts/0 SW 22:28 0:00 [nfsd]</font>
<br><font face="Courier New,Courier">root
1380 0.0 0.0 0 0
pts/0 SW 22:28 0:00 [nfsd]</font>
<br><font face="Courier New,Courier">root
1381 0.0 0.0 0 0
pts/0 SW 22:28 0:00 [nfsd]</font>
<br><font face="Courier New,Courier">root
1382 0.0 0.0 0 0
pts/0 SW 22:28 0:00 [nfsd]</font>
<br><font face="Courier New,Courier">root
1383 0.0 0.0 0 0
pts/0 SW 22:28 0:00 [nfsd]</font>
<br><font face="Courier New,Courier">root
1384 0.0 0.0 0 0
pts/0 SW 22:28 0:00 [nfsd]</font>
<br><font face="Courier New,Courier">root
1385 0.0 0.0 0 0
pts/0 SW 22:28 0:00 [nfsd]</font>
<br><font face="Courier New,Courier">root
1386 0.0 0.0 0 0
pts/0 SW 22:28 0:00 [nfsd]</font>
<br><font face="Courier New,Courier">root
1399 0.0 0.0 0 0
pts/0 SW 22:28 0:00 [lockd]</font>
<br><font face="Courier New,Courier">root
1409 0.0 0.2 1156 560 ?
S 22:28 0:00 rpc.statd</font>
<br><font face="Courier New,Courier">root
1652 0.0 0.1 1228 484 pts/3 S
22:49 0:00 egrep nfs|mount|lock|stat</font></blockquote>
Il existe actuellement 2 versions de NFS (versions 2 et 3 - que nous noterons
respectivement NFSv2 et NFSv3 quand nous voudrons les différencier).
Le serveur NFS de Linux ne supporte pour l'instant que la version 2 (d'où
l'option sur la ligne du <font face="Courier New,Courier">mountd</font>
de l'exemple précédent).
<p>L'objet au centre de toutes les préoccupations de NFS s'appelle
un <i>file handle</i>. Il s'agit d'une suite de bits relativement ésotérique
permettant de désigner de manière unique chacun des objets
du systèmes de fichiers (donc un fichier entre autre, mais pas uniquement).
Il contient par exemple, l'inode du fichier, mais également un fichier
représentant le device où se trouve ce fichier. On peut donc
voir NFS comme un système de fichiers qui en encapsule un autre.
<h1>
Installation</h1>
<A NAME="lfindex0"> </A>
<H2>
Le serveur</H2>
La toute première chose à faire, comme nous l'avons vu, est
de démarrer <font face="Courier New,Courier">portmap</font> puisque
les protocoles nécessaires à l'utilisation de NFS se servent
des RPCs.
<blockquote><font face="Courier New,Courier">root >>/usr/sbin/rpcinfo -p</font>
<br><font face="Courier New,Courier">rpcinfo: can't contact portmapper:
RPC: Remote system error - Connection refused</font>
<br><font face="Courier New,Courier">root >>/sbin/portmap</font>
<br><font face="Courier New,Courier">root >>/usr/sbin/rpcinfo -p</font>
<br><font face="Courier New,Courier"> program vers proto
port</font>
<br><font face="Courier New,Courier"> 100000
2 tcp 111 portmapper</font>
<br><font face="Courier New,Courier"> 100000
2 udp 111 portmapper</font></blockquote>
La commande <font face="Courier New,Courier">rpcinfo</font> permet de connaître
les services RPC qui fonctionnent sur la machine spécifiée
en argument (l'option <font face="Courier New,Courier">-p</font>). On constate
donc que <font face="Courier New,Courier">portmap</font> ne tourne pas
encore : on le démarre (la plupart des distributions de Linux mettent
en place des scripts qui permettent de faire ceci de manière automatique
au démarrage de la machine) et on vérifie qu'il fonctionne
correctement. Une autre possibilité expliquant la réponse
négative reçue suite à l'appel de <font face="Courier New,Courier">rpcinfo</font>
est tout simplement l'interdiction faite au portmapper de répondre,
par l'entremise des fichiers <font face="Courier New,Courier">/etc/hosts.{allow,
deny}</font>.
<p>Avant de démarrer NFS proprement dit, il faut le configurer.
Le seul fichier de configuration s'appelle <font face="Courier New,Courier">/etc/exports</font>.
Chaque ligne contient l'emplacement à exporter suivi d'une liste
de clients autorisés à y accéder . Il est possible,
voire indispensable, de rajouter des options à la suite de chaque
nom de client. La page <font face="Courier New,Courier">man exports</font>
décrit clairement les syntaxes valides pour les noms de clients
et les options.
<p>Les formulations acceptées pour les noms des clients sont :
<ul>
<li>
un nom de machine ;</li>
<li>
des wildcards sur un nom de domaine (ex : linux-*.mondomaine.fr) ;</li>
<li>
un <i>netgroup</i>, sous la forme <font face="Courier New,Courier">@group</font>,
si NIS est utilisé et en défini ;</li>
<li>
une adresse IP ...</li>
</ul>
Nous ne détaillerons pas ici toutes les options de montage possibles,
mais voici les plus importantes :
<ul>
<li>
<font face="Courier New,Courier">rw</font> (read write) : le client peut
lire et écrire sur le système exporté ;</li>
<li>
<font face="Courier New,Courier">ro</font> (read only) : le client
peut seulement lire sur le système exporté ;</li>
<li>
<font face="Courier New,Courier">root_squash</font> : il est préférable
que l'utilisateur <i>root</i> d'un client ne puisse pas être assimilé
au <i>root</i> du serveur. Pour éviter ceci, l'UID/GID 0 (i.e. celui
de <i>root</i>) devient celui de l'utilisateur <i>nobody</i>. Cette option
est active par défaut mais peut être annulée par <font face="Courier New,Courier">no_root_squash</font>
;</li>
<li>
<font face="Courier New,Courier">all_squash</font> : tous les clients accédant
au système exporté utilisent l'UID/GID de nobody ;</li>
<li>
<font face="Courier New,Courier">anonuid</font>, <font face="Courier New,Courier">anongid</font>
: l'utilisateur <i>nobody</i> dispose maintenant de l'UID/GID transmis
par ces options.</li>
</ul>
Il reste maintenant à démarrer les démons <font face="Courier New,Courier">rpc.mountd</font>
et <font face="Courier New,Courier">rpc.nfs</font> pour avoir un serveur
NFS en place. On vérifie que tout tourne correctement toujours avec
la commande <font face="Courier New,Courier">rpcinfo</font>. On peut également
initialiser les serveurs pour les protocoles <b>nsm</b> et <b>nlm</b> (respectivement
<font face="Courier New,Courier">rpc.statd</font>
et <font face="Courier New,Courier">rpc.lockd</font>). Ils ne sont pas
indispensables au fonctionnement d'un serveur NFS ... mais fortement conseillés
au cas où une machine tomberait en panne, rebooterait intempestivement,
etc...
<p>Lorsqu'on modifie le fichier de configuration <font face="Courier New,Courier">/etc/exports</font>,
il faut signaler aux démons concernés que des changements
se sont produits. La commande <font face="Courier New,Courier">exportfs</font>
transmet ces informations aux serveurs. L'option <font face="Courier New,Courier">-r</font>
synchronise le fichier <font face="Courier New,Courier">/etc/mtab<a NAME="foot2" href="#foot2"></a></font><sup><a href="#foot2" NAME="foot2">2</a></sup>
avec le fichier <font face="Courier New,Courier">/etc/exports</font>. L'option
<font face="Courier New,Courier">-v</font>
permet de connaître les systèmes de fichiers exportés
avec leurs options.
<p>Une fois que tout est en place, certains fichiers contiennent des informations
importantes :
<ul>
<li>
<font face="Courier New,Courier">/var/lib/nfs/rmtab</font> : chaque ligne
contient le nom d'un client et le système de fichiers qu'il importe
de ce serveur ;</li>
<li>
<font face="Courier New,Courier">/var/lib/nfs/etab</font> : le fichier
<font face="Courier New,Courier">/etc/exports</font>
ne contient qu'une liste de voeux. Il est crée par <font face="Courier New,Courier">exportfs</font>
qui y retranscrit sur chaque ligne toutes les informations liées
à l'exportation vers un unique client (et donc également
les options par défaut). C'est le fichier de référence
dont se sert <font face="Courier New,Courier">rpc.mountd</font> lors de
son initialisation ;</li>
<li>
<font face="Courier New,Courier">/proc/fs/nfs/exports</font> fournit la
liste des clients reconnus par le noyau ;</li>
<li>
<font face="Courier New,Courier">/var/lib/nfs/xtab</font> : il sert à
la même chose que le précédent. Plus précisément,
alors que <font face="Courier New,Courier">etab</font> contient indifféremment
des noms de clients et des groupes de machines (via les wildcards ou les
netgroups), ce fichier ne contient que des noms de machines explicites.</li>
</ul>
Quand un client souhaite accéder à un système de fichiers,
il commence par le demander à <font face="Courier New,Courier">mountd</font>.
Celui-ci recherche alors dans <font face="Courier New,Courier">etab</font>
si la requête est accessible. Il vérifie également
auprès du noyau que le client a légitimement le droit de
présenter cette requête (contrôle des <font face="Courier New,Courier">hosts</font>.{<font face="Courier New,Courier">allow</font>,
<font face="Courier New,Courier">deny</font>},
règles de pare-feu, ...). Le noyau emploie <font face="Courier New,Courier">exportfs</font>
pour cette vérification, ce qui lui permet en même temps de
mettre à jour le fichier <font face="Courier New,Courier">/var/lib/nfs/etab</font>.
Si, dans ce fichier, le système exporté est destiné
à un groupe auquel appartient le client, <font face="Courier New,Courier">mountd</font>
restreint alors la requête au client. et en informe le noyau qui
met à jour
<font face="Courier New,Courier">xtab</font> avec ce
nouvel hôte.
<A NAME="lfindex1"> </A>
<H2>
Le client</H2>
Rien à faire ... en général. L'accès à
un système de fichiers exporté par NFS est directement géré
à partir du noyau qui sait comment accéder à des données
sur un support physique via les systèmes de fichiers adéquates.
Pour connaître ceux supportés par votre noyau, le répertoire
<font face="Courier New,Courier">/lib/modules/<version
du noyau>/fs</font> contient tous les modules liés aux systèmes
de fichiers. Le fichier <font face="Courier New,Courier">/proc/filesystems</font>
liste tous ceux supportés directement dans le noyau. Il faut donc
uniquement préciser au noyau qu'on souhaite accéder à
un système exporté par NFS.
<p>La commande <font face="Courier New,Courier">mount</font> permet d'accéder
à différents systèmes de fichiers. Elle signale au
noyau qu'un nouveau système de fichier est utilisable en indiquant
son type, son <i>device</i> et un point de montage. L'option <font face="Courier New,Courier">-t</font>
permet de préciser le système auquel un client veut accéder.
Seuls les modules évoqués ci-dessus sont reconnus par le
noyau. Pour un système NFS, l'argument s'écrit donc : <font face="Courier New,Courier">-t
nfs</font>.
<p><font face="Courier New,Courier">mount</font> dispose d'options propres
à NFS. Par exemple, les options <font face="Courier New,Courier">rsize</font>
et <font face="Courier New,Courier">wsize</font> permettent de modifier
les tailles des blocs en lecture et en écriture. On peut combiner
les options spécifiques à NFS avec des options plus générales,
comme <font face="Courier New,Courier">intr</font>,
<font face="Courier New,Courier">noexec</font>
ou <font face="Courier New,Courier">nosuid</font>. La page man de <font face="Courier New,Courier">mount</font>
contient toutes ces options.
<p>Supposons que la machine <i>charly</i> dispose d'un serveur NFS et exporte
son répertoire <font face="Courier New,Courier">/usr/local</font>.
Nous souhaitons y accéder de la machine <i>jill</i>, il suffit alors
de monter le répertoire exporté de <i>charly</i> sur <i>jill</i>
:
<blockquote><font face="Courier New,Courier">root@jill >> mount -t nfs
-o nosuid,hard,intr charly:/usr/local /usr/local</font></blockquote>
La commande indique donc que nous allons monter un système de fichiers
de type NFS (<font face="Courier New,Courier">-t nfs</font>), avec les
options <font face="Courier New,Courier">nosuid</font>, <font face="Courier New,Courier">hard</font>
et <font face="Courier New,Courier">intr</font>. Les 2 derniers arguments
sont les plus intéressants. Le premier spécifie le <i>device</i>
qui doit être monté. Dans le cas de NFS, la syntaxe diffère
de l'usage habituel de <font face="Courier New,Courier">mount</font>. En
effet, on commence par stipuler un serveur, puis un répertoire de
ce serveur (Attention : un répertoire n'est normalement pas un device).
Le dernier argument indique l'endroit auquel correspond ce système
de fichiers sur le client. On vient donc de partager le <font face="Courier New,Courier">/usr/local</font>
de <i>charly</i> avec <i>jill</i>, ce qui évite d'avoir à
installer plusieurs fois certains programmes. Pour que ceci soit établi
de manière permanente, on peut également le spécifier
dans le fichier /<font face="Courier New,Courier">etc/fstab</font> de <i>jill</i>
qui contient tous les devices à installer au démarrage. Ainsi,
de manière équivalente, le fichier <font face="Courier New,Courier">/etc/fstab</font>
contiendrait la ligne :
<br>
<blockquote><font face="Courier New,Courier"># device
point de système de options
dump fsckorder</font>
<br><font face="Courier New,Courier">#
montage fichiers</font>
<br><font face="Courier New,Courier">charly:/usr/local
/usr/local nfs
nosuid,hard,intr 0 0</font></blockquote>
<A NAME="lfindex2"> </A>
<H2>
Les précautions</H2>
Un problème fondamental de NFS vient du fait qu'il existe une relation
de confiance, par défaut, entre un client et un serveur NFS. Dans
ce cas, si le compte <i>root</i> du serveur est compromis, celui du client
le sera également. Le NFS-HOWTO décrit un ensemble de mesures
élémentaires nécessaires à prendre.
<p>Un client ne peut croire aveuglément un serveur, il faut donc
préciser des options contraignantes lors de l'utilisation de la
commande <font face="Courier New,Courier">mount</font>. Nous avons déjà
vu la première : <font face="Courier New,Courier">nosuid</font>.
Elle annule l'effet des bits SUID et SGID. Ainsi, une personne <i>root</i>
sur le serveur doit se connecter d'abord en tant qu'utilisateur quelconque
sur le client pour ensuite seulement redevenir <i>root</i>. Une autre option,
plus contraignante, est <font face="Courier New,Courier">noexec</font>.
Elle interdit l'exécution des programmes contenus sur le système
exporté. Cette option n'est utilisable que pour les systèmes
contenant uniquement des données.
<p>Du côté du serveur NFS, on peut également spécifier
qu'on ne fait pas confiance au compte <i>root</i> des clients. On doit
alors préciser dans le <font face="Courier New,Courier">/etc/exports</font>
l'option <font face="Courier New,Courier">root_squash</font>. Ainsi, si
un utilisateur avec l'UID 0 (celui de <i>root</i>) sur le client accède
au système exporté par le serveur, il se voit attribuer
l'UID de <i>nobody</i> pour effectuer les requêtes sur les fichiers.
Cette option est active par défaut sous Linux mais s'annule par
l'option <font face="Courier New,Courier">no_root_squash</font>. Notons
qu'on peut préciser une plage d'UID pour lesquels l'option s'applique.
Rappelons également que les options <font face="Courier New,Courier">anonuid</font>
et <font face="Courier New,Courier">anongid</font> permettent de changer
l'UID/GID de l'utilisateur <i>nobody</i> en celui souhaité.
<p>Certaines mesures sont d'un ordre plus général et concernent
plutôt le <font face="Courier New,Courier">portmapper</font>. Par
exemple, on interdit l'accès à ce service à toutes
les machines par la ligne suivante dans le fichier
<font face="Courier New,Courier">/etc/hosts.deny</font>
:
<br>
<blockquote><font face="Courier New,Courier"># hosts.deny : interdiction
absolue pour tout le monde de</font>
<br><font face="Courier New,Courier">#
se servir du portmap</font>
<br><font face="Courier New,Courier">portmap: ALL</font></blockquote>
<p><br>Ensuite, dans le <font face="Courier New,Courier">/etc/hosts.allow</font>,
on contrebalance cette interdiction drastique en autorisant l'accès
à toutes les machines souhaitées.
<p>Des règles de firewalling adéquates contribuent également
à une meilleure protection. Il faut prendre garde aux ports employés
par les divers services ainsi qu'aux protocoles utilisés :
<br>
<center><table BORDER WIDTH="60%" NOSAVE >
<tr>
<td><b>Service RPC</b></td>
<td><b>Port</b></td>
<td><b>Protocoles</b></td>
</tr>
<tr>
<td>portmap</td>
<td>111</td>
<td>upd / tcp</td>
</tr>
<tr>
<td>nfsd</td>
<td>2049</td>
<td>udp</td>
</tr>
<tr>
<td>mountd</td>
<td>variable</td>
<td>udp / tcp</td>
</tr>
</table></center>
<h1>
Application : NIS, NFS et autofs</h1>
Pour illustrer notre propos, reprenons le réseau mis en place lors
du précédent article sur NIS. Le serveur principal s'appelle
"<i>charly</i>", les 3 autres machines du sous-réseau sont "<i>sabrina</i>",
"<i>jill</i>" et "<i>kelly</i>". Nous avons configuré
<i>charly</i>
comme serveur NIS du domaine <i>bosley</i>. Les autres machines sont uniquement
des clients NIS de <i>charly</i> (en pratique, nous devrions avoir un serveur
NIS esclave, mais là n'est pas le propos aujourd'hui).
<p>Voyons d'abord la configuration sur notre serveur <i>charly</i>. Nous
commençons par définir quelques maps NIS qui contiendront
toutes les informations dont nous avons besoin.
<p>Le fichier <font face="Courier New,Courier">/etc/netgroup</font> contient
des groupes de machines ayant des caractéristiques communes (une
même architecture par exemple). Il s'agit d'une map de NIS très
pratique à utiliser pour NFS. Il suffit juste de rassembler dans
un groupe toutes les machines pouvant accéder à un même
système de fichiers exporté. Ce groupe sert ensuite dans
le /<font face="Courier New,Courier">etc/exports</font> plutôt que
de préciser tous les client un à un :
<blockquote><font face="Courier New,Courier"># /etc/netgroup</font>
<br><font face="Courier New,Courier">charlysangels (sabrina,,) (jill,,)
(kelly)</font></blockquote>
Concernant NFS, nous savons que la configuration est assez restreinte.
Le fichier <font face="Courier New,Courier">/etc/exports</font> de <i>charly</i>
contient :
<blockquote><font face="Courier New,Courier"># /etc/exports</font>
<br><font face="Courier New,Courier">/usr/local @charlysangels(ro)</font></blockquote>
Par ailleurs, nous décidons d'utiliser l'<font face="Courier New,Courier">automount</font>
pour accéder au répertoire <font face="Courier New,Courier">/usr/local</font>
ainsi exporté. En effet, plutôt que de monter directement
ce système au boot, ce sera fait automatiquement si un utilisateur
accède à un fichier de ce répertoire. Nous créons
le fichier <font face="Courier New,Courier">/etc/auto.map</font> pour définir
ce qui sera accessible à la fois par <font face="Courier New,Courier">automount</font>
et par NIS :
<blockquote><font face="Courier New,Courier"># /etc/auto.map</font>
<br><font face="Courier New,Courier">charly
charly:/usr/local</font></blockquote>
Comme nous voulons que ces informations (les nouveaux <font face="Courier New,Courier">auto.map</font>
et <font face="Courier New,Courier">netgroup</font>) soient intégrées
dans la base de données de NIS, nous devons modifier le <font face="Courier New,Courier">Makefile</font>
avant de la reconstruire. En effet, il faut s'assurer que <font face="Courier New,Courier">netgroup</font>
sera bien ajouté à la base. Concernant <font face="Courier New,Courier">auto.map</font>,
ce fichier n'est pas défini par défaut, il faut signaler
son existence. Il suffit pour cela d'ajouter une nouvelle entrée
dans le <font face="Courier New,Courier">Makefile</font>, ainsi que la
règle associée (en prenant modèle sur ce qui existe
déjà) :
<blockquote>#A ajouter dans le Makefile des Yellow Pages</blockquote>
<blockquote>AUTO_MAP = $(YPSRCDIR)/auto.map
<br># ...
<br>#...
<br><font face="Courier New,Courier">auto.map: $(AUTO_MAP) $(YPDIR)/Makefile</font></blockquote>
<blockquote><font face="Courier New,Courier">
@echo "Updating $@..."</font>
<br><font face="Courier New,Courier">
-@sed -e "/^#/d" -e s/#.*$$// $(AUTO_MAP) | $(DBLOAD) \</font>
<br><font face="Courier New,Courier">
-i $(AUTO_MAP) -o $(YPMAPDIR)/$@ - $@</font>
<br><font face="Courier New,Courier">
-@$(NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@</font></blockquote>
Cette règle de production se contente d'enlever les commentaires,
d'ajouter une nouvelle entrée à la base de données
puis de transmettre l'information à tous les serveurs.
<p>Il ne reste plus qu'à exécuter un <font face="Courier New,Courier">make</font>
dans le répertoire <font face="Courier New,Courier">/var/yp</font>.
<p>Au tour de nos trois clients <i>sabrina</i>,
<i>jill
</i>et
<i>kelly</i>.
Là, il n'y a presque rien à faire :) Nous devons préciser
à
<font face="Courier New,Courier">autofs</font> qu'il doit gérer
une nouvelle map qui lui sera fournie via les YPs. Dans chacun des <font face="Courier New,Courier">/etc/auto.master</font>
des clients, la ligne suivante permet de signaler la présence d'une
map auto.map qui sera obtenue via les services des YPs.
<blockquote><font face="Courier New,Courier">#/etc/auto.master</font>
<br><font face="Courier New,Courier">/usr/local yp auto.map
--intr,nosuid,nodev</font></blockquote>
puis il faut redémarrer <font face="Courier New,Courier">autofs</font>
pour que cette nouvelle map soit prise en compte.
<p>Ainsi, il existe un unique répertoire <font face="Courier New,Courier">/usr/local</font>
physiquement sur <i>charly</i>. Du coup, pour installer des programmes
très spécifiques, en les disposant sur <i>charly</i>, toutes
nos machines pourront également en profiter.
<p>Cet exemple peut aller beaucoup plus loin en n'installant qu'un seul
système <font face="Courier New,Courier">/usr</font>, <font face="Courier New,Courier">/usr/doc</font>
ou d'autres, mais la pratique montre que ce n'est pas très raisonnable.
Les installations nécessitent souvent de modifier des fichiers dans
le répertoire <font face="Courier New,Courier">/etc</font> ou autres.
Il faudrait donc aller faire des retouches sur toutes les machines pour
mettre à jour les fichiers non-exportés, ce qui devient vite
très fastidueux.
<br>
<A NAME="lfindex3"> </A>
<H3>
Références</H3>
<u>Systèmes de Fichiers</u>
<ul>
<li>
Filesystems-HOWTO : <a href="http://www.linuxdoc.org">www.linuxdoc.org</a></li>
<li>
Design and Implementation of the Second Extended Filesystem : un excellent
article de Rémy Card, Théodore Ts'o et Stephen Tweedie, les
créateurs du ext2fs : <a href="http://khg.redhat.com/HyperNews/get/fs/ext2intro.html">http://khg.redhat.com/HyperNews/get/fs/ext2intro.html</a></li>
</ul>
<p><br><u>NFS</u>
<ul>
<li>
NFS-HOWTO : <a href="http://www.linuxdoc.org">www.linuxdoc.org</a></li>
<li>
The Linux kernel NFSD implementation : pour aller (beaucoup) plus loin,
une bonne et complète description de la programmation et du fonctionnement
de NFS pour Linux : <a href="http://www.cse.unsw.edu.au/~neilb/oss/linux-commentary/nfsd.html">http://www.cse.unsw.edu.au/~neilb/oss/linux-commentary/nfsd.html</a></li>
</ul>
<p><br>
<hr>
<h4>
Footnotes</h4>
<dl>
<dt>
<a NAME="foot1"></a>... inode<a NAME="foot1" href="#foot1"></a><sup><a href="#foot1" NAME="foot1">1</a></sup></dt>
<dd>
Il s'agit d'un descripteur (une suite de bits) contenant, entre autre,
les droits d'accès au fichier, son propriétaire, les adresses
des blocs physiques contenant les données, etc ...</dd>
</dl>
<dl>
<dt>
<a NAME="foot2"></a>... /etc/mtab<a NAME="foot2" href="#foot2"></a><sup><a href="#foot2" NAME="foot2">2</a></sup></dt>
<dd>
Ce fichier contient la liste de tous les systèmes de fichiers qui
sont montés par le noyau, que ce soit "en dur" (par un mount, comme
c'est le cas avec les systèmes décrits dans la fstab), ou
par des moyens moins permanents (via <font face="Courier New,Courier">autofs</font>/<font face="Courier New,Courier">automount</font>).</dd>
</dl>
<hr>
<!-- 2pdaIgnoreStart -->
<A NAME="talkback"> </a>
<h2>Discussion sur cet article</h2>
Chaque article possède sa page de discussion. Vous pouvez y soumettre un commentaire ou lire ceux d´autres lecteurs:
<center>
<table border="0" CELLSPACING="2" CELLPADDING="1">
<tr BGCOLOR="#C2C2C2"><td align=center>
<table border="3" CELLSPACING="2" CELLPADDING="1">
<tr BGCOLOR="#C2C2C2"><td align=center>
<A href="http://cgi.linuxfocus.org/cgi-bin/lftalkback?anum=164&lang=fr"><b> page de discussion </b></a>
</td></tr></table>
</td></tr></table>
</center>
<HR size="2" noshade>
<!-- ARTICLE FOOT -->
<CENTER><TABLE WIDTH="95%">
<TR><TD ALIGN=CENTER BGCOLOR="#9999AA">
<A HREF="../../common/lfteam.html">Site Web maintenu par l´équipe d´édition LinuxFocus</A>
<BR><FONT COLOR="#FFFFFF">© Frédéric Raynal, <a href="../../common/copy.html">FDL</a> <BR><a href="http://www.linuxfocus.org">LinuxFocus.org</a></FONT>
<BR><a href="http://cgi.linuxfocus.org/cgi-bin/lfcomment?lang=fr&article=article164.shtml" target="_TOP">Cliquez ici pour signaler une erreur ou envoyer un commentaire à Linuxfocus</A><BR></TD>
<!-- OLD FORMAT, NO TRANSLATION INFO -->
</TR></TABLE></CENTER>
<p><font size=1>2001-03-18, generated by lfparser version 2.8</font></p>
<!-- 2pdaIgnoreStop -->
</BODY>
</HTML>