Installer et configurer un partage NFS (Mandriva 2007.1 à 2009.1)

Introduction

Le système de fichiers en réseau (Network File System) est un protocole qui permet à un ordinateur d'accéder à des fichiers situés sur d'autres ordinateurs à travers un réseau.
Les applications sont multiples :

  • travail collaboratif sur des mêmes documents
  • centralisation de documents sur un serveur de fichiers
  • stockages des sauvegardes d'un ordinateur sur un autre ordinateur du réseau
  • installation des nouveaux ordinateurs à partir d'un serveur local
  • ...

Le partage de fichier en réseau est un système avec plein de finesses.
Avant de vous lancer dans la configuration, prenez le temps de lire cette page et de réfléchir aux options que vous devez choisir dans votre cas.

menus Souvent, vous trouverez des images de taille réduite, à droite de l'écran. Survolez-les avec la souris, pour les agrandir.

Afin de ne pas encombrer la page avec une multitude d'images, vous trouverez souvent des écritures qui les symbolisent.

Ce tutorial comprend plusieurs chapitres :

Haut

Un peu de théorie

Processus mis en jeu

Ce paragraphe vous sera surtout utile si votre serveur ou votre client NFS comprend également un pare-feu.

NFS repose sur les Remote Procedure Calls (RPC) et donc sur portmap qui gère la correspondance entre les programmes RPC et les ports qu'ils utilisent.
Portmap écoute sur le port 111 (TCP et UDP)
Côté serveur, il y a 4 services (démons) qui tournent et qui scrutent chacun un port particulier :

  • nfsd : c'est la base qui permet la création de fichier, leur recherche, leur lecture ou leur écriture. Il gère également l'authentification et les statistiques sur les fichiers. Par défaut, il écoute sur le port 2049 (TCP et UDP).
  • mountd : il s'occupe du montage des systèmes exportés auxquels on accédera par nfs. Il envoie des requêtes de type mount et umount au serveur.
    Par défaut, le port est celui attribué par portmap et est aléatoire (TCP et UDP)
  • statd : sert à gérer les noeuds du réseau pour connaître l'état d'une machine (cliente ou serveur) pour signaler, par exemple, qu'elle redémarre.
    Par défaut, le port est celui attribué par portmap et est aléatoire (TCP et UDP)
  • lockd : 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 verrous qui permettent de signaler les systèmes de fichiers utilisés. Le verrouillage de fichiers NFS est maintenant effectué par le noyau.
    Le port attribué est aléatoire (TCP et UDP)

Remarque : Ces programmes ne sont pas tous nécessaires pour le service NFS. Les seuls services qui doivent être activés sont rpc.mountd, rpc.nfsd et portmap. Les autres démons offrent des fonctionnalités additionnelles, en fonction des exigences particulières de votre environnement serveur.

Côté client, quand un client souhaite envoyer une requête RPC vers un numéro de programme donné, il contacte d'abord le serveur portmap pour obtenir le numéro de port sur lequel tourne le programme souhaité. Ensuite, il adresse les paquets RPC au port correspondant.

En résumé, au moins 5 ports sont utilisés lors des communications liées à NFS, dont 3 sont indispensables. Ceci prend toute son importance lorsque vous avez un pare-feu où il faut libérer les ports adéquats.

Haut

Fonctionnement

Export de fichiers sur le serveur

  1. portmap démarre
  2. mountd démarre. Vous pouvez spécifier le port sur lequel ce démon doit écouter
  3. mountd s'enregistre auprès de portmap

Recherche des serveurs NFS

Avec l'assistant graphique, la première opération est la recherche des serveurs NFS.
Sur le client, l'assistant essaie de contacter le port 111 d'un éventuel serveur, par broadcast. Pour ceci, il utilise plusieurs ports à partir de 32770, sur le client.
Pour que la réponse puisse arriver, vous devrez désactiver momentanément le pare-feu du client, ou y ouvrir les ports 32770 à 32774. (Je n'ai pas réussi à trouver exactement lesquels et à quoi ils servent).

Montage du système de fichiers distant

Sur le poste client, le montage du système de fichiers distants se passe de la façon suivante :

  1. mount (client) fait une requête auprès de portmap distant
  2. portmap distant indique au client quel est le port à contacter
  3. mount (client) contacte mountd (distant sur le port qui lui a été spécifié
  4. mountd (distant) envoie à mount (client) un identifiant (handle) si le montage est possible
  5. l'accès au système de fichier distant est maintenant possible

Accès aux fichiers

Lorsqu'une application veut accéder à un fichier :

  1. elle sollicite le noyau
  2. le noyau détermine si le fichier est local ou distant
  3. si le fichier est distant, le noyau passe les coordonnées à NFS client
  4. le client NFS appelle le serveur NFS sur le port 111 (portmap)
  5. portmap transfère la demande vers NFS (partie serveur)
  6. NFS accède au fichier demandé

Dans un popup : Plus d'informations sur le principe de NFS : Cliquez

Haut

Sécurité : limiter l'accès à ces processus

Cette étape n'est pas obligatoire, mais est simplement une sécurité suppémentaire. Il faut également voir ce chapitre en cas de problèmes d'accès.

Linux prévoit la possibilité de limiter ou d'interdire l'accès à une machine ou à certains processus d'une machine.
Deux fichiers permattent de contrôler l'accès à la machine ou à un de ses processus : /etc/hosts.allow et /etc/hosts.deny
Le premier permet d'autoriser et le second d'interdire l'accès.

Le fonctionnement est le suivant :

  • chaque fichier de contrôle d'accès comprend 0 à plusieurs lignes
  • les lignes sont lues dans leur ordre d'apparition
  • les lignes vides ou commençant par # sont ignorées
  • le fichier /etc/hosts.allow est lu en premier
  • la lecture s'arrête dès qu'une concordance a été trouvée

La syntaxe des lignes est l'une des suivantes

  • liste_daemons : liste_clients
  • liste_daemons : liste_clients : commande_shell
    avec liste daemons = un ou plusieurs processus daemons
    avec liste_clients = un ou plusieurs clients (nom d'hôte ou adresse IP)
    avec commande_shell = commande à exécuter en cas de concordance
    les éléments des listes sont séparés par un espace ou une virgule

Les listes peuvent également être remplacées par des jockers dont voici les plus utilisés :

  • ALL : tout daemon ou tout client
  • LOCAL : tous les hôtes du réseau local

Voisi un exemple qui permet l'accès à tout le réseau local, mais interdit au restant du monde :
Fichier hosts.deny
#Interdire tout le monde sur les services portmap, nfsd et mountd
portmap: ALL
nfsd: ALL
mountd: ALL
Fichier hosts.allow
#Autoriser tout le réseau local sur les services portmap, nfsd et mountd
portmap: 192.168.0.0/255.255.255.0
nfsd: 192.168.0.0/255.255.255.0
mountd: 192.168.0.0/255.255.255.0

Haut

Règles de configuration du serveur

Pour que votre partage NFS fonctionne correctement, sa configuration doit correspondre à vos besoins.
C'est le fichier /etc/exports qui définit les conditions du partage de fichiers avec NFS.

Syntaxe des lignes de ce fichier

Il peut y avoir plusieurs plusieurs partages différents pour un même serveur. Le fichier /etc/exports comprendra autant de lignes qu'il y a de répertoires à partager.
Chaque ligne définit :

  • le nom complet du répertoire. Ex. /home/toto/Documents
  • quelle(s) machine(s) peu(ven)t y accéder. Ex 192.168.0.2
  • comment les machines peuvent y accéder. Ex (all_squash,ro)

Voici un exemple de ligne, autorisant deux machines bien définies à accéder à un répertoire :
/home/toto/Documents 192.168.0.2(all_squash,ro) 192.168.0.3(root_squash,rw)

Voyons maintenant plus en détail ces différents paramètres.

Répertoire à partager

Le répertoire auquel pourront accéder les clients sera indiqué avec toute son arborescence :
Ex. /home/Toto/Documents

Pour quelles machines

Les machines qui accèdent au partage sont appelées les clients. Vous pouvez les préciser de différentes façons :

  • si n'importe quel client peut accéder au partage:
    vous indiquerez :*
  • si un seul client peut accéder, vous le désignez par l'une des façons suivantes :
    • son nom abrégé connu de la résolution de noms
      tux
    • son nom complet qualifié (FQDN)
      tux.tuxworldsi votre réseau local n'est pas relié à internet et que vous l'avez baptisé tuxworld
      tux.tuxworld.frsi votre domaine est enregistré dans fr
    • son adresse IP
  • si un groupe de clients peut accéder, vous pouvez le désigner par :
    • un nom contenant des caractères jocker (? *)
      tux* pour touts les clients dont le nom commence par tux
  • si un réseau ou sous-réseau entier peut accéder, vous pouvez le désigner par :
    192.168.0.0/255.255.255.0ou192.168.0.0/24
Haut

Avec quels droits

Vous vous en souvenez, avec tous les Unix et donc Linux, tous les fichiers et répertoires appartiennent à un utilisateur et l'utilisateur fait partie d'un groupe.
Ces fichiers et répertoires possèdent des droit d'accès (lecture, écriture, exécution) pour le propriétaire, pour le groupe et pour les autres utilisateurs.
Avec NFS, l'utilisateur et le groupe ne sont pas reconnus par leurs noms, mais par leurs identifiants (UID et GID).
Il s'agit de définir de quels droits dispose l'utilisateur distant qui se connecte sur le serveur NFS : simple lecture (et téléchargement) ou droit de modifier et supprimer ?

Il va falloir gérer ces droits et la façon de les gérer dépend de la finalité du partage :

Les options de NFS permettent de gérer ces droits, par l'intermédiaire des identifiants de l'utilisateur qui veut accéder au partage. Selon le cas :

Si un demandeur est, par exemple, l'utilisateurToto et que cet utilisateur existe à la fois sur la machine client et sur le serveur, rien ne dit que les identifiants de cet utilisateur Toto soient les mêmes sur les deux machines. Il faudra y remédier au besoin, faute de quoi il ne sera pas reconnu correctement et pourrait avoir les droits d'un autre utilisateur.

Si le demandeur distant est un superutilisateur, vous savez qu'il a des droits illimités. De ce fait, il sera traité séparément, afin de définir s'il peut les utiliser sur le serveur.

Les options se placent immédiatement après le nom du client, sans espace et entre parentaises (voir l'exemple ci-dessus).
Voici les options relatives aux identifiants et aux droits qui en résultent :

Remarque : vous avez vu qu'avec l'option no_all_squash, il faut que les UID et GID de l'utilisateur soient identiques sur les deux machines. Il existait deux méthodes permettant leur conversion lorsque cela est nécessaire. Elles ont été abandonnées, sans doute par manque de sécurité. Maintenant, il faut bien veiller à avoir les mêmes identifiants ou bien utiliser une méthode centralisée d'authentification.

Haut

Dans quelles conditions

Exemples de configurations

Pour un serveur public, vous pourriez partager un répertoire /var/nfs/pub.
Vous allez convertir tous les clients (et surtout root) en utilisateur anonyme.
Vous ne leur donnez aucun droit d'écriture. Vous pourriez avoir la ligne :
/var/nfs/pub *(all_squash,sync,secure,subtree_check,ro) (root_squash est défini par défaut).

Si cette machine est utilisée en tant que serveur de fichiers (c-à-d si tous les utilisateurs d'un réseau y enregistrent leurs documents), elle devra avoir un répertoire /home et chaque utilisateur y aura son répertoire propre. En veillant à la concordance des UID et GID, il sera possible de conserver les droits relatifs aux répertoires et fichiers.
Chaque utilisateur ne pourra alors qu'accéder à son propre répertoire, en lecture et écriture. La ligne de configuration pourrait être :
/home 192.168.0.0/24(sync,secure,no_subtree_check,rw) (no_all_squash et root_squash sont définis par défaut).

Si, en plus, le root de toutes les machines du réseau est l'administrateur du réseau, vous pouvez éventuellement lui laisser les droits de super-utilisateur. La ligne devient alors :
/home 192.168.0.0/24(no_root_squash,sync,secure,no_subtree_check,rw) (no_all_squash est défini par défaut).

Si vous souhaitez utiliser cette machine pour faire les sauvegardes générales, faites par root, vous pourriez y avoir un répertoire /home/sauvegardes, il ne sera accessible que depuis votre réseau local, les utilisateurs deviennent anonyme. Seul root reste root. Il aura droit d'écriture. La ligne de configuration pourrait être :
/home/sauvegardes 192.168.0.0/24(all_squash,no_root_squash,sync,secure,no_subtree_check,rw)

Haut

La pratique

Voilà, les préliminaires étaient plutôt longs. Mais vous pouvez passer à la pratique.

Ayant constaté des différences assez grandes selon les versions de Mandriva, ce tutoriel a été éclaté en plusieurs pages.
En cliquant sur un des liens ci-dessous, vous allez ouvrir un nouvel onglet ou une nouvelle fenêtre de votre navigateur. Vous pourrez ainsi naviguer entre les deux pages, en fonction de vos besoins.

Configuration du serveur

Si vous avez Mandriva 2007.1 : Cliquez

Si vous avez Mandriva 2008.0, 2008.1 ou 2009.0 : Cliquez

Si vous avez Mandriva 2009.1, cela devient très simple : Cliquez

Configuration des clients

Si vous avez Mandriva 2007.1 : Cliquez

Si vous avez Mandriva 2008.0 à 2009.1 : Cliquez

Haut
 

Les pages relatives aux tutoriels :

Installation : avant, pendant, après Installation, pas à pas, de 2008.0 Installation, depuis internet Installation en réseau
Comment MDV sélectionne les paquetages Créer sa liste de paquetages
Configuration du système Configuration d'un utilisateur KDE Serveur de fichiers avec ProFTPD Partage de fichiers avec NFS
Réveiller un ordinateur à distance Commander un ordinateur à distance avec ssh
Le son et la gestion du son La video et la gestion des images Découvrir la puissance de Gstreamer
Faire des sauvegardes générales Nettoyer le répertoire /home Changer de client de messagerie Synchroniser fichiers et répertoires
Créer sa distribution personnelle Autopsie d'une distribution Mandriva

Les différentes rubriques :

Accueil Ordinateur Mandriva Tutoriels Initiation à la programmation Maison bioclimatique
On se lasse de tout, sauf de comprendre.
Attribué à Virgile.