Principes

NFS (Network File System) est comme son nom l'indique un système de fichier par réseau. Il vous permet d'avoir accès à un répertoire d'une machine distante (le serveur NFS) de façon tout à fait transparente, via un simple répertoire de votre machine (le client NFS).

Par exemple il est possible de faire en sorte que le répertoire /home d'une machine soit en fait une vue du répertoire /home d'un serveur (là où sont vraiment les données, sur le disque dur du serveur).

NFS est d'abord utilisé sur les postes clients fixes. Si vous désirez mettre en place un accès aux données serveur pour un ordinateur portable, rendez-vous sur SSHFS.

Quelques documents génériques pour tout comprendre :

• Linux NFS-HOWTO : toute la doc, officielle.

• Le chapitre NFS de la Formation Debian GNU/Linux de l'ECP.

• d'autres idées sur la page NFS de Léa Linux.

Reste à écrire :

• schéma technique général, démons et modules mis en jeu
• les lacunes de nfs : sécurité et performances

• pourquoi l'utiliser quand même ? parce que ça marche, c'est robuste et que c'est facile à mettre en œuvre => on dira que c'est « efficace »

Ci-dessous les recettes de cuisine à la mode AUF.

Mise en place : coté serveur

NB : NFS ne marche pour le moment pas sur un serveur virtuel (CT openvz) !

• Installation du logiciel serveur :

  # aptitude install nfs-kernel-server

• Configuration : on déclare ce qu'on veut exporter dans le fichier /etc/exports. Ce fichier sert de liste de contrôle d’accès pour les systèmes de fichiers à partager avec les clients NFS. Un exemple :

  # Exemple de /etc/exports. Faire un "man 5 exports" pour avoir le détail de la syntaxe
  /home   192.168.0.0/16(rw,async,no_root_squash,no_subtree_check) 
  /home2  192.168.0.0/16(rw,async,no_root_squash,no_subtree_check) 

Pour mieux comprendre les options que nous avons indiquées, lire la page man exports

Attention à l'option no_root_squash : elle n'est pas vraiment recommandée car elle pose des petits problèmes de sécurité, mais il faut l'activer pour que l'impression PDF fonctionne avec cups-pdf sur les postes clients. Il n'existe pas d'autre solution actuellement (14 juillet 2009).

Si vous gérez vos utilisateurs à travers un système de type libnss-mysql, il est très utile que les utilisateurs soient aussi visibles sur le serveur NFS. Dans le cas de libnss-mysql, installez et configurez le paquet libnss-mysql-bg et installez également le système de cache nscd.

A détailler :

• différences entre nfs-kernel-server, nfs-user-server et unfs3.

• quelques options de exports

Mise en place : coté client

Sur Ubuntu il faut installer le paquet nfs-common pour que la partie cliente NFS soit disponible.

Montage "à la main" (uniquement pour un test rapide)

• # mount serveur:/repertoire /point/de/montage

Le montage sera effectif tant que la partition n'aura pas été démontée (umount /point/de/montage) ou que la machine n'aura pas été redémarrée. Ca n'a pas vraiment d'utilité, sauf pour tester bien entendu, notamment tester les options de montage NFS dont vous pouvez voir les détails avec man nfs.

Auto-monteur (autofs) sur /net : méthode conseillée

On préfére utiliser un auto-monteur : il va monter les partitions à la demande, et les démontera quand elles ne seront plus utilisées.

1. On installe l'automonteur :

   $ sudo aptitude install autofs

2. On indique que /net est un point d'automontage géré par autofs, et qu'il est géré via le script /etc/auto.net qui est fourni par le paquet autofs :

   # Extrait du fichier /etc/auto.master
   # /net sera un répertoire géré par autofs
   # - chaque sous-répertoire de /net sera géré via le script /etc/auto.net
   # - démontages après quinze minutes de non-utilisation.
   /net    /etc/auto.net --timeout=900

3. Relancer le service autofs :

   $ sudo invoke-rc.d autofs restart

Le fonctionnement est un peu "magique" : lors d'un accès au répertoire /net/nfs.xx.auf.org, le script auto.net regarde les répertoires partagés par la machine nfs.xx.auf.org et les monte tous.

Ainsi, si le serveur nfs.xx.auf.org partage un répertoire /home, le montage sera effectué dans /net/nfs.xx.auf.org/home.

Une technique classique est de faire un lien symbolique de /home vers /net/nfs.xx.auf.org/home pour que tout soi transparent pour les utilisateurs.

Note : pour connaitre les répertoires partagés par le serveur nfs.xx.auf.org, le script auto.net lance la commande showmount -e nfs.xx.auf.org. Les options de montage sont indiquées "en dur" dans le script, regardez-les. Vous pouvez lancer un showmount pour vérifier que les montages sont bien visibles, exemple :

• thomas@pc:~$ showmount -e nfs.refer.sn
  Export list for nfs.refer.sn:
  /home         10.196.0.0/20,192.168.0.0/16
  /home2        10.196.0.0/20,192.168.0.0/16

Que faire lorsque "ça ne marche pas" ?

Vérifications à faire côté client

• automount est-il bien actif (et je ne vous parle pas si vous n'utilisez par automount dans votre CNF)

• le showmount -e nfs.xx.auf.org renvoie-t-il bien la liste de tous les répertoires exportés par le serveur ? Vérifier les exports, vus du côté client :

  # showmount -e un-serveur-nfs
  Export list for nfs:
  /home           10.196.0.0/20,192.168.0.0/16
  /home2          10.196.0.0/20,192.168.0.0/16

• Que donne l'accés direct au répertoire en automount en ligne de commande ? Par exemple :

  $ cd /net/nfs.xx.auf.org/home

• Vérifier, si le repertoire apparait, qu'il posséde bien les droits et propriétaires attendus :

  $ ls -lsd /net/nfs.xx.auf.org/home

  (-d pour voir le répertoire lui-même, et non son contenu)

• vérifier que les uid/gid côté client et serveur sont bien synchrones (id gringo doit donner le même résultat sur le client NFS et sur le serveur)

• Si on essaye de monter la partition "à la main", quels sont les messages d'erreur ?

  # mount -t nfs le-serveur-nfs:/home /mnt
  mount to NFS server 'le-serveur-nfs' failed: server is down.

• les logs ? /var/log/messages, /var/log/daemon.log... Un exemple classique de soucis :

  /var/log/messages:Nov 23 09:31:23 poste-client kernel: nfs: server 111.222.111.222 not responding, still trying
  /var/log/messages:Nov 23 09:39:09 poste-client kernel: nfs: server 111.222.111.222 OK

• le serveur est-il bien accessible via le portmapper ?

  # rpcinfo -p un-serveur-pas-nfs 
  rpcinfo: ne peut contacter l'aiguilleur de ports: RPC: erreur système sur l'hôte cible - Connexion refusée
  # rpcinfo -p un-vrai-serveur-nfs
     program no_version protocole  no_port
      100000    2   tcp    111  portmapper
      100000    2   udp    111  portmapper
      100003    2   udp   2049  nfs
  ...

Vérifications à faire côté serveur

(à finir demain, je fatigue un peu, là...)

• Le daemon nfsd est-il bien actif ?

• tcp/udp ?
• fichier exports ?
• filtrage de paquets ?
• logs ?
• heuuuu ?

Annexes

Annexe : traversée d'un pare-feu = ports de communication fixés

(tiré de http://wiki.debian.org/SecuringNFS)

Voilà, vous avez votre serveur NFS qui fonctionne. Cependant, vous avez des règles iptables sur le chemin, ou quelque part sur votre réseau, et NFS utilise des ports dynamiques pour dialoguer. Aïe ! Pour fixer les ports utilisés par NFS, il est possible de le configurer ainsi :

• # (... extrait de /etc/default/nfs-common ...)
   STATDOPTS="--port 32765 --outgoing-port 32766"

  # (... extrait de /etc/default/nfs-kernel-server ...)
   RPCMOUNTDOPTS="-p 32767"

  # (... extrait de /etc/default/quota ...)
   RPCRQUOTADOPTS="-p 32769"

De plus vous avez toujours portmap en communication sur le port 111 et le démon nfsd sur le port 2049 par défaut.

Il reste à créer ce fichier:

• # /etc/modprobe.d/options.local
   options lockd nlm_udpport=32768 nlm_tcpport=32768

Enfin vous n'avez plus qu'à écrire vos règles iptables en autorisant le passage sur les port 111, 2049 et 32765:32769 en tcp et udp.

Annexe : automonteur sur /nfs

Au lieu du montage via /net indiqué plus haut et qui peut paraître un peu «magique», il est possible de configurer autofs pour effectuer des montages de façon très directive.

1. On indique qu'on veut que /nfs soit un point d'automontage, et que sa configuration sera dans

   # Extrait du fichier /etc/auto.master
   # /nfs sera un répertoire géré par autofs (il faut faire un mkdir /nfs)
   # ce répertoire /nfs a sa configuration dans /etc/auto.nfs
   # démontages après une heure de non-utilisation.
   /nfs    /etc/auto.nfs --timeout=3600

2. Configuration des sous-répertoires de /nfs :

   # Fichier /etc/auto.nfs
   repertoire1   -fstype=nfs,intr,rsize=8192,wsize=8192,proto=tcp        serveur1:/repertoire1
   repertoire2   -fstype=nfs,intr,rsize=8192,wsize=8192,proto=udp        serveur2:/un/autre/repertoire2

3. Relancer le service autofs :

   $ sudo invoke-rc.d autofs restart

A partir de ce moment, /nfs/repertoire1 et /nfs/repertoire2 seront montés sur demande, et démontés au bout d'une heure de non-utilisation.

Annexe : montage permanent via fstab (non recommandé !)

Avec /etc/fstab le montrage sera permanent. De GROS inconvénients :

• le montage est fait systématiquement, même quand le répertoire n'est pas utilisé : gaspillage de ressources ! Surtout dans le cas d'un paramètrage "tcp", par défaut sous ubuntu.
• si le serveur NFS doit être redémarré au même moment que le client, le client sera bloqué jusqu'à la fin du démarrage du serveur. Le poste client aura aussi des difficulté a démarré en cas de problèmes sur le réseau. (le cas d'école étant une machine "A" qui monte une partition de la machine "B" dans son fstab, alors que "B" fait la même chose de son côté avec "A" : ça marche bien au cas par cas, et plus aucune des deux machines ne pourra démarrer aprés une coupure electrique générale)

Si on veut rendre un montage NFS permanent, on peut l'indiquer dans le fichier /etc/fstab :

• # (... extrait de /etc/fstab ...)
  # <file system> <mount point>   <type>  <options>                                <dump>  <pass>
  serveur:/home   /point/de/mnt   nfs     rw,intr,rsize=8192,wsize=8192,proto=tcp  0       0

Mais franchement, pourquoi se priver d'un auto-monteur ?