28.3. Système de fichiers réseau (NFS)

Réorganisé et augmenté par Tom Rhodes. Ecrit par Bill Swingle.

Parmi les différents systèmes de fichiers que FreeBSD supporte se trouve le système de fichiers réseau, connu sous le nom de NFS. NFS permet à un système de partager des répertoires et des fichiers avec d'autres systèmes par l'intermédiaire d'un réseau. En utilisant NFS, les utilisateurs et les programmes peuvent accéder aux fichiers sur des systèmes distants comme s'ils étaient des fichiers locaux.

Certains des avantages les plus remarquables offerts par NFS sont:

28.3.1. Comment NFS fonctionne

NFS consiste en deux éléments principaux: un serveur et un ou plusieurs clients. Le client accède à distance aux données stockées sur la machine serveur. Afin que tout cela fonctionne correctement quelques processus doivent être configurés et en fonctionnement.

Sur le serveur, les “daemons” suivants doivent tourner:

Daemon Description
nfsd Le “daemon” NFS qui répond aux requêtes des clients NFS.
mountd Le “daemon” de montage NFS qui traite les requêtes que lui passe nfsd(8).
rpcbind Ce “daemon” permet aux clients NFS de trouver le port que le serveur NFS utilise.

Le client peut également faire tourner un “daemon” connu sous le nom de nfsiod. Le “daemon” nfsiod traite les requêtes en provenance du serveur NFS. Ceci est optionnel, et améliore les performances, mais n'est pas indispensable pour une utilisation normale et correcte. Consultez la page de manuel nfsiod(8) pour plus d'informations.

28.3.2. Configurer NFS

La configuration de NFS est une opération relativement directe. Les processus qui doivent tourner peuvent tous être lancés au démarrage en modifiant légèrement votre fichier /etc/rc.conf.

Sur le serveur NFS, assurez-vous que les options suivantes sont configurées dans le fichier /etc/rc.conf:

rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"

mountd est automatiquement exécuté dès que le serveur NFS est activé.

Sur le client, assurez-vous que cette option est présente dans le fichier /etc/rc.conf:

nfs_client_enable="YES"

Le fichier /etc/exports indique quels systèmes de fichiers NFS devraient être exportés (parfois on utilise le terme de “partagés”). Chaque ligne dans /etc/exports précise un système de fichiers à exporter et quelles machines auront accès à ce système de fichiers. En plus des machines qui auront accès, des options d'accès peuvent également être présentes. Ces options sont nombreuses mais seules quelques unes seront abordées ici. Vous pouvez aisément découvrir d'autres options en lisant la page de manuel exports(5).

Voici quelques exemples d'entrées du fichier /etc/exports:

Les exemples suivants donnent une idée de comment exporter des systèmes de fichiers bien que certains paramètres peuvent être différents en fonction de votre environnement et votre configuration réseau. Par exemple, pour exporter le répertoire /cdrom pour les trois machines d'exemple qui appartiennent au même domaine que le serveur (d'où l'absence du nom de domaine pour chacune d'entre elles) ou qui ont une entrée dans votre fichier /etc/hosts. Le paramètre -ro limite l'accès en lecture seule au système de fichiers exporté. Avec ce paramètre, le système distant ne pourra pas écrire sur le système de fichiers exporté.

/cdrom -ro host1 host2 host3

La ligne suivante exporte /home pour les trois machines en utilisant les adresses IP. C'est une configuration utile si vous disposez d'un réseau privé sans serveur DNS configuré. Le fichier /etc/hosts pourrait éventuellement être configuré pour les noms de machines internes, consultez la page de manuel hosts(5) pour plus d'information. Le paramètre -alldirs autorise l'utilisation des sous-répertoires en tant que point de montage. En d'autres termes, il ne montera pas les sous-répertoires mais autorisera le client à ne monter que les répertoires qui sont nécessaires ou désirés.

/home  -alldirs  10.0.0.2 10.0.0.3 10.0.0.4

La ligne suivante exporte /a pour que deux clients d'un domaine différent puissent y accéder. Le paramètre -maproot=root autorise l'utilisateur root du système distant à écrire des données sur le système de fichiers exporté en tant que root. Si le paramètre -maproot=root n'est pas précisé, même si un utilisateur dispose d'un accès root sur le système distant, il ne pourra pas modifier de fichiers sur le système de fichiers exporté.

/a  -maproot=root  host.example.com box.example.org

Afin de pouvoir accéder à un système de fichiers exporté, le client doit avoir les permissions de le faire. Assurez-vous que le client est mentionné dans votre fichier /etc/exports.

Dans /etc/exports, chaque ligne représente l'information d'exportation d'un système de fichiers vers une machine. Une machine distante ne peut être spécifiée qu'une fois par système de fichiers, et ne devrait avoir qu'une seule entrée par défaut. Par exemple, supposons que /usr soit un seul système de fichiers. Le fichier /etc/exports suivant serait invalide:

# Invalide quand /usr est un système de fichiers
/usr/src   client
/usr/ports client

Un système de fichiers, /usr, a deux lignes précisant des exportations vers la même machine, client. Le format correct pour une telle situation est:

/usr/src /usr/ports  client

Les propriétés d'un système de fichiers exporté vers une machine donnée devraient apparaître sur une ligne. Les lignes sans client sont traitées comme destinée à une seule machine. Cela limite la manière dont vous pouvez exporter les systèmes de fichiers, mais pour la plupart des gens cela n'est pas un problème.

Ce qui suit est un exemple de liste d'exportation valide, où les répertoires /usr et /exports sont des systèmes de fichiers locaux:

# Exporte src et ports vers client01 et client02, mais seul
# client01 dispose des privilèges root dessus
/usr/src /usr/ports -maproot=root    client01
/usr/src /usr/ports               client02
# Les machines clientes ont les privilèges root et peuvent monter tout
# de /exports.  N'importe qui peut monter en lecture seule
# /exports/obj
/exports -alldirs -maproot=root      client01 client02
/exports/obj -ro

Le “daemon” mountd doit être forcé de relire le fichier /etc/exports à chacune de ses modifications, afin que les changements puissent prendre effet. Cela peut être effectué soit en envoyant un signal HUP au “daemon”:

# kill -HUP `cat /var/run/mountd.pid`

soit en invoquant la procédure rc(8) de mountd avec le paramètre approprié:

# /etc/rc.d/mountd onereload

Veuillez consulter la Section 11.7 pour plus d'information sur l'utilisation des procédures rc.

De plus, un redémarrage permettra à FreeBSD de tout configurer proprement. Un redémarrage n'est cependant pas nécessaire. Exécuter les commandes suivantes en tant que root devrait mettre en place ce qui est nécessaire.

Sur le serveur NFS:

# rpcbind
# nfsd -u -t -n 4
# mountd -r

Sur le client NFS:

# nfsiod -n 4

Maintenant il devrait être possible de monter un système de fichiers distant. Dans nos exemples le nom du serveur sera serveur et le nom du client client. Si vous voulez monter temporairement un système de fichiers distant ou vous voulez simplement tester la configuration, exécutez juste une commande comme celle-ci en tant que root sur le client:

# mount serveur:/home /mnt

Cela montera le répertoire /home situé sur le serveur au point /mnt sur le client. Si tout est correctement configuré vous devriez être en mesure d'entrer dans le répertoire /mnt sur le client et de voir tous les fichiers qui sont sur le serveur.

Si vous désirez monter automatiquement un système de fichiers distant à chaque démarrage de l'ordinateur, ajoutez le système de fichiers au fichier /etc/fstab. Voici un exemple:

server:/home	/mnt	nfs	rw	0	0

La page de manuel fstab(5) liste toutes les options disponibles.

28.3.3. Verrouillage

Certaines applications (par exemple mutt) ont besoin du verrouillage des fichiers pour fonctionner correctement. Dans le cas du NFS, rpc.lockd peut être utilisé pour assurer le verrouillage des fichiers. Pour l'activer, ajouter ce qui suit au fichier /etc/rc.conf sur les machines clientes et serveur (on suppose que les clients et le serveur NFS sont déjà configurés):

rpc_lockd_enable="YES"
rpc_statd_enable="YES"

Lancez l'application en utilisant:

# /etc/rc.d/nfslocking start

Si un verrouillage réel n'est pas nécessaire entre les clients et le serveur NFS, il est possible de laisser le client NFS effectuer le verrouillage localement en passant l'option -L à mount_nfs(8). Veuillez vous référer à la page de manuel mount_nfs(8) pour de plus amples détails.

28.3.4. Exemples pratiques d'utilisation

Il existe de nombreuses applications pratiques de NFS. Les plus communes sont présentés ci-dessous:

28.3.5. Montages automatiques avec amd

Contribution de Wylie Stilwell. Réécrit par Chern Lee.

amd(8) (“automatic mounter daemon”—“daemon” de montage automatique) monte automatiquement un système de fichiers distant dès que l'on accède à un fichier ou un répertoire contenu par ce système de fichiers. Les systèmes de fichiers qui sont inactifs pendant une certaine période seront automatiquement démontés par amd. L'utilisation d'amd offre une alternative simple aux montages permanents qui sont généralement listés dans /etc/fstab.

amd opère en s'attachant comme un serveur NFS aux répertoires /host et /net. Quand on accède à un fichier à l'intérieur de ces répertoires, amd recherche le montage distant correspondant et le monte automatiquement. /net est utilisé pour monter un système de fichiers exporté à partir d'une adresse IP, alors que /host est utilisé pour monter un système de fichiers exporté à partir d'un nom de machine distant.

Un accès à un fichier dans /host/foobar/usr demandera à amd de tenter de monter l'export /usr sur la machine foobar.

Exemple 28-2. Monter un systèmes de fichiers exporté avec amd

Vous pouvez voir les systèmes de fichiers exportés par une machine distante avec la commande showmount. Par exemple, pour voir les répertoires exportés par une machine appelée foobar, vous pouvez utiliser:

% showmount -e foobar
Exports list on foobar:
/usr                               10.10.10.0
/a                                 10.10.10.0
% cd /host/foobar/usr

Comme on le voit dans l'exemple, showmount liste /usr comme une exportation. Quand on change de répertoire pour /host/foobar/usr, amd tente de résoudre le nom de machine foobar et de monter automatiquement le système exporté désiré.

amd peut être lancé par les procédures de démarrage en ajoutant les lignes suivantes dans le fichier /etc/rc.conf:

amd_enable="YES"

De plus, des paramètres peuvent être passés à amd à l'aide de l'option amd_flags. Par défaut, l'option amd_flags est possitionnée à:

amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"

Le fichier /etc/amd.map définit les options par défaut avec lesquelles les systèmes exportés sont montés. Le fichier /etc/amd.conf définit certaines des fonctionnalités les plus avancées de amd.

Consultez les pages de manuel de amd(8) et amd.conf(5) pour plus d'informations.

28.3.6. Problèmes d'intégration avec d'autres systèmes

Contribution de John Lind.

Certaines cartes Ethernet ISA présentent des limitations qui peuvent poser de sérieux problèmes sur un réseau, en particulier avec NFS. Ce n'est pas une particularité de FreeBSD, mais FreeBSD en est également affecté.

Ce problème se produit pratiquement à chaque fois que des systèmes (FreeBSD) PC sont sur le même réseau que des stations de travail très performantes, comme celles de Silicon Graphics, Inc. et Sun Microsystems, Inc. Les montages NFS se feront sans difficulté, et certaines opérations pourront réussir, puis soudain le serveur semblera ne plus répondre au client, bien que les requêtes vers ou en provenance d'autres systèmes continueront à être traitées normalement. Cela se manifeste sur la machine cliente, que ce soit le système FreeBSD ou la station de travail. Sur de nombreux systèmes, il n'est pas possible d'arrêter le client proprement une fois que ce problème apparaît. La seule solution est souvent de réinitialiser le client parce que le problème NFS ne peut être résolu.

Bien que la solution “correcte” est d'installer une carte Ethernet plus performante et de plus grande capacité sur le système FreeBSD, il existe une solution simple qui donnera satisfaction. Si le système FreeBSD est le serveur, ajoutez l'option -w=1024 lors du montage sur le client. Si le système FreeBSD est le client, alors montez le système de fichiers NFS avec l'option -r=1024. Ces options peuvent être spécifiées dans le quatrième champ de l'entrée fstab sur le client pour les montages automatiques, ou en utilisant le paramètre -o de la commande mount(8) pour les montages manuels.

Il faut noter qu'il existe un problème différent, que l'on confond parfois avec le précédent, qui peut se produire lorsque les serveurs et les clients NFS sont sur des réseaux différents. Si c'est le cas, assurez-vous que vos routeurs transmettent bien les informations UDP nécessaires, ou vous n'irez nulle part, quoi que vous fassiez par ailleurs.

Dans les exemples suivants, fastws est le nom de la station de travail (interface) performante, et freebox celui d'une machine (interface) FreeBSD avec une carte Ethernet moins performante. /sharedfs est le système de fichiers NFS qui sera exporté (consulter la page de manuel exports(5)), et /project sera le point de montage sur le client pour le système de fichiers exporté. Dans tous les cas, des options supplémentaires, telles que hard soft et bg seront peut-être nécessaires pour vos applications.

Exemple d'extrait du fichier /etc/fstab sur freebox quand le système FreeBSD (freebox) est le client:

fastws:/sharedfs /project nfs rw,-r=1024 0 0

Commande de montage manuelle sur freebox:

# mount -t nfs -o -r=1024 fastws:/sharedfs /project

Exemple d'extrait du fichier /etc/fstab sur fastws quand le système FreeBSD est le serveur:

freebox:/sharedfs /project nfs rw,-w=1024 0 0

Commande de montage manuelle sur fastws:

# mount -t nfs -o -w=1024 freebox:/sharedfs /project

Presque n'importe quelle carte Ethernet 16 bits permettra d'opérer sans l'utilisation des paramètres restrictifs précédents sur les tailles des tampons de lecture et d'écriture.

Pour ceux que cela intéresse, voici ce qui se passe quand le problème survient, ce qui explique également pourquoi ce n'est pas récupérable. NFS travaille généralement avec une taille de “bloc” de 8 k (bien qu'il arrive qu'il les fragmente en de plus petits morceaux). Comme la taille maximale d'un paquet Ethernet est de 1500 octets, le “bloc” NFS est divisé en plusieurs paquets Ethernet, bien qu'il soit toujours vu comme quelque chose d'unitaire par les couches supérieures du code, et doit être réceptionné, assemblé, et acquitté comme tel. Les stations de travail performantes peuvent traiter les paquets qui composent le bloc NFS les uns après les autres, pratiquement aussi rapidement que le standard le permet. Sur les cartes les plus petites, de moindre capacité, les derniers paquets d'un même bloc écrasent les paquets précédents avant qu'ils aient pu être transmis à la machine et le bloc ne peut être réassemblé ou acquitté. Avec pour conséquence, le dépassement du délai d'attente sur la station de travail qui recommence alors la transmission, mais en renvoyant l'intégralité des 8 K, et ce processus se répète à l'infini.

En définissant la taille de bloc inférieure à la taille d'un paquet Ethernet, nous nous assurons que chaque paquet Ethernet complet sera acquitté individuellement, évitant ainsi la situation de blocage.

Des écrasements peuvent toujours survenir quand des stations de travail performantes surchargent un système PC de données, mais avec de meilleures cartes, de tels écrasements ne sont pas systématiques pour les “blocs” NFS. Quand un écrasement apparaît, les blocs affectés sont retransmis, et ils y a de fortes chances pour qu'ils soient reçus, assemblés et acquittés.

Ce document, ainsi que d'autres peut être téléchargé sur ftp.FreeBSD.org/pub/FreeBSD/doc/.

Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.