NFS (Network File System) est un protocole de niveau 7 (Application) sur le modèle OSI qui fut développé par SUN en 1984 à l’époque ou il n’y avait pas de solution pour partager des fichiers comme nous le faisons simplement aujourd’hui via Samba, l’uPNP, ou autres protocoles.

1 – Qu’est ce qu’ NFS?

 

Il offre la possibilité de partager un disque dur, un espace de stockage d’un serveur avec de nombreux postes clients. Ces clients voient le partage comme un disque local, l’intégrant parfaitement au système. Nous sommes donc dans une architecture client / serveur, environnement courant de nos jours. Typiquement ce système était souvent utilisé dans le cas de station sans disque ou tout le système ainsi que les données étaient localisés sur un serveur distant et montés au démarrage du système via le protocole NFS.

a – Quelques bénéfices du NFS

 

• Les stations de travail utilisent moins d’espace disque, car les données peuvent être stockées sur une seule machine tout en restant accessible aux autres sur le réseau.

• Il n’est pas nécessaire pour les utilisateurs d’avoir un répertoire personnel sur chaque machine du réseau. Le répertoire personnel pourra être mis en place sur le serveur NFS et mis à disposition l’ensemble du réseau.

• Les périphériques de stockage tels que les disquettes (euhhh y’en a encore ??), les lecteurs de CD-ROM, DVD-ROM, BLUERAY, les lecteurs Zip ® , les DAT peuvent être utilisés par d’autres machines sur le réseau.

NFS en est à sa version 4, qui intègre enfin des notions de sécurité, contrairement à ses versions précédentes. Le protocole a totalement été réécrit pour cette version. Voici from wikipedia ces principales caratéristiques :

Une gestion totale de la sécurité :

• négociation du niveau de sécurité entre le client et le serveur
• sécurisation simple, support de kerberos5, certificats SPKM et LIPKEY
• Chiffrement des communications possible (kerberos 5p par exemple)

Support accru de la montée en charge :

• Réduction du trafic par groupement de requêtes compound
• Délégation (le client gère le fichier en local)

Systèmes de maintenances simplifiés :

• Migration : le serveur NFS est migré de la machine A vers la machine B de manière transparente pour le client
• Réplication : le serveur A est répliqué sur la machine B
• Reprise sur incidents :La gestion de la reprise sur incident est intégrée du côté client et du côté serveur.
• Compatibilité : NFSv4 peut être utilisée sous [Unix->http://fr.wikipedia.org/wiki/Unix] et maintenant également sous MS-Windows
• Support de plusieurs protocoles de transports (TCP, RDMA) depuis la version 3. Auparavant uniquement UDP.

b – Et comment ça marche tout ça ?

 

• Les clients NFS envoient leurs requêtes aux serveurs NFS grâce aux Appels de Procédures Distantes (Remote Procedure Calls), les RPCs.

• Le client RPC découvre les entrées du service distant automatiquement, gère l’authentification requête par requête, ajuste les paramètres des requêtes afin de gérer l’ordre des octets sur le client et le serveur (endianess), et se charge de la retransmission des requêtes qui pourraient s’être perdues dans le réseau ou sur le serveur.

• Les requêtes et les réponses NFS circulent sur un protocole de transport réseau.

2 – Installation de NFS sur Debian

 

Le client NFS de Linux gère trois versions du protocole : NFS version 2 [RFC1094], NFS version 3 [RFC1813], et NFS version 4 [RFC3530].

L’installation se fait sur une Debian du coté serveur comme du coté client.

Le client pour fonctionner à besoin des parquets nfs-common et portmap :

# apt-get install nfs-common portmap

 

Le serveur quant à lui à besoin des paquets nfs-common et portmap comme le client et du module NFS qui va bien fournit par le paquet nfs-kernel-server :

 # apt-get install nfs-common portmap nfs-kernel-server

 

3 – Configuration du serveur NFS

 

Les répertoires exporté par NFS sont configuré dans le fichier /etc/export.

Chaque ligne commence par son chemin absolue, suivie d’une liste de client autorisé à s’y connecter :

Extrait du /etc/exports :

 /home 192.168.1.1(rw,no_root_squash) www.freenux.fr(ro)

 

Un client peut être spécifié soir par son DNS, soit par son IP.

Le caractère Wildcard (*) est autorisé dans les noms, ainsi que les sous-réseau ( par ex 192.168.1.0/24)

Les options concernant le client ou le groupe de client sont spécifié après l’adresse IP entre parenthèse.

Il ne doit pas y avoir d’espace entre l’adresse IP et la 1ère parenthèse. En effet, l’espace est interprété comme un séparateur.

À chaque modification faite du fichier /etc/exports, lancez la commande suivante afin de prendre en compte les modifications :

 # exportfs -a

 

Les options pouvant être spécifié entre parenthèse sont les suivantes (from the man page :p) :

• secure : Cette option impose l’utilisation d’un port réservé (« IPPORT_RESERVED », inférieur à 1024) comme origine de la requête. Cette option est activée par défaut. Pour la désactiver, utilisez insecure.
• rw : Permettre les requêtes en lecture et en écriture sur le volume NFS. Le comportement par défaut est d’interdire toute requête qui modifierait le système de fichiers. On peut spécifier explicitement ce comportement par défaut en utilisant l’option ro.
• async : Permettre au serveur NFS de transgresser le protocole NFS en répondant aux requêtes avant que tous les changements impliqués par la requête en cours n’aient été effectués sur le support réel (par exemple, le disque dur).L’utilisation de cette option améliore généralement les performances, mais au risque de perdre ou de corrompre des données en cas de redémarrage brutal d’un serveur, suite à un plantage par exemple.
• sync : Ne répondre aux requêtes qu’après l’exécution de tous les changements sur le support réel (voir async plus haut).Dans toutes les versions de nfs-utils jusqu’à la 1.0.0 (incluse), c’était l’option par défaut. Dans toutes les versions suivantes, le comportement par défaut est sync, et async doit être explicitement indiquée si vous en avez besoin.Afin d’aider les administrateurs systèmes à prêter attention à cette modification, exportfs affichera un message d’avertissement si ni sync ni async ne sont précisées.
• no_wdelay : Cette option est sans effet si async est déjà active. Le serveur NFS va normalement retarder une requête d’écriture sur disque s’il suspecte qu’une autre requête en écriture liée à celle-ci soit en cours ou puisse survenir rapidement. Cela permet l’exécution de plusieurs requêtes d’écriture en une seule passe sur le disque, ce qui peut améliorer les performances. En revanche, si un serveur NFS reçoit principalement des petites requêtes indépendantes, ce comportement peut réellement diminuer les performances.no_wdelay permet de désactiver cette option. On peut explicitement spécifier ce comportement par défaut en utilisant l’option wdelay.
• nohide : Cette option est basée sur l’option de même nom fournie dans le NFS d’IRIX. Normalement, si un serveur partage deux systèmes de fichiers dont un est monté sur l’autre, le client devra explicitement monter les deux systèmes de fichiers pour obtenir l’accès complet.S’il ne monte que le parent, il verra un répertoire vide à l’endroit où l’autre système de fichiers est monté. Ce système de fichiers est « caché ».Définir l’option nohide sur un système de fichiers empêchera de le cacher, et tout client convenablement autorisé pourra alors se déplacer du système de fichiers parent à celui-ci sans s’en apercevoir.Cependant, quelques clients NFS ne sont pas adaptés à cette situation. Il est alors possible, par exemple, que deux fichiers de ce système de fichiers apparemment unique aient le même numéro d’inode.L’option nohide ne concerne actuellement que les partages vers les hôtes seuls. Elle ne s’applique pas aux partages vers les groupes de machines, sous-réseaux et ceux utilisant les caractères jokers.

  Cette option peut être très pratique dans certains cas, mais elle doit être utilisée avec parcimonie, et seulement après vérification du bon comportement du système client à gérer cette situation.

  Cette option peut être désactivée explicitement avec hide.

• Crossmnt : Cette option est semblable à nohide mais elle permet aux clients de se déplacer du système de fichiers marqué crossmnt aux systèmes de fichiers partagés montés dessus. Ainsi, si un système de fichiers fils « B » est monté sur un système de fichiers père « A », définir l’option crossmnt sur « A » aura le même effet que d’indiquer « nohide » sur « B »
• no_subtree_check : Cette option neutralise la vérification de sous-répertoires, ce qui a des subtiles implications au niveau de la sécurité, mais peut améliorer la fiabilité dans certains cas.Si un sous-répertoire dans un système de fichiers est partagé, mais que le système de fichiers ne l’est pas, alors chaque fois qu’une requête NFS arrive, le serveur doit non seulement vérifier que le fichier accédé est dans le système de fichiers approprié (ce qui est facile), mais aussi qu’il est dans l’arborescence partagée (ce qui est plus compliqué). Cette vérification s’appelle subtree_check.
  Pour ce faire, le serveur doit ajouter quelques informations sur l’emplacement du fichier dans le « filehandle » (descripteur de fichier) qui est donné au client. Cela peut poser problème lors d’accès à des fichiers renommés alors qu’un client est en train de les utiliser (bien que dans la plupart des cas simples, cela continuera à fonctionner).La vérification de sous-répertoires est également utilisée pour s’assurer que des fichiers situés dans des répertoires auxquels seul l’administrateur a accès ne sont consultables que si le système de fichiers est exporté avec l’option no_root_squash (voir ci-dessous), et ce, même si les fichiers eux-mêmes offrent un accès plus généreux.D’une façon générale, un système de fichiers des répertoires personnels («home directories »), qui est normalement partagé à sa racine et qui va subir de multiples opérations de renommage de fichiers, devrait être partagé sans contrôle de sous-répertoires. Un système de fichiers principalement en lecture seule, et qui donc ne verra que peu de modifications de noms de fichiers (/usr ou /var par exemple) et pour lequel des sous-répertoires pourront être partagés, le sera probablement avec la vérification des sous-répertoires.

  On peut explicitement spécifier ce comportement par défaut de vérification des sous-répertoires en indiquant l’option subtree_check.

  À partir de la version 1.1 de nfs-utils, le réglage par défaut sera no_subtree_check car la vérification des sous-répertoires (subtree_checking) pose souvent plus de problèmes qu’elle n’en résout. Si vous voulez activer la vérification des sous-répertoires comme auparavant , vous devrez explicitement indiquer ce choix dans le fichier exports. Si vous n’indiquez ni l’une ni l’autre option, exportfs vous préviendra que cette modification est en suspens.

• insecure_locks
• no_auth_nlm : Cette option (les deux noms sont synonymes) indique au serveur NFS de ne pas exiger l’authentification des requêtes de verrouillage (c.-à-d. les requêtes qui utilisent le protocole NLM).Normalement le serveur de NFS doit exiger d’une requête de verrouillage qu’elle fournisse une accréditation pour un utilisateur qui a accès en lecture au fichier. Avec cette option, aucun contrôle d’accès ne sera effectué.Les premières implémentations de clients NFS n’envoyaient pas d’accréditations lors de requêtes de verrouillage, et nombre de clients NFS encore utilisés sont basés sur ces anciennes implémentations.Utilisez cette option si vous constatez que vous ne pouvez verrouiller que les fichiers en lecture pour tous (« world readable »).On peut explicitement spécifier ce comportement par défaut de demande d’accréditation pour les requêtes NLM en indiquant les options synonymes auth_nlm ou secure_locks.
• no_acl : Sur certains noyaux spécialement modifiés, et lors de partages de systèmes de fichiers implémentant les ACL, cette option indique à nfsd ne pas dévoiler les ACL aux clients, ainsi ils verront seulement un sous-ensemble de permissions réelles sur le système de fichiers donné.Cette option est efficace pour des partages utilisés par les clients NFSv2 et les anciens clients NFSv3 qui effectuent des vérifications d’accès localement. Les clients NFSv3 actuels utilisent l’appel de procédure distante ACCESS («ACCESS RPC ») afin d’effectuer toutes les vérifications d’accès sur le serveur.Notez que l’option no_acl n’a d’effet que sur des noyaux spécifiquement modifiés pour le gérer, et seulement lors du partage de systèmes de fichiers implémentant les ACL.Par défaut, le partage implémente les ACL (c.-à-d. par défaut, no_acl est désactivée).
• mountpoint=chemin : cf mp
• mp : Cette option permet de ne partager un répertoire que si son montage a réussi.Si aucun chemin n’est précisé (par exemple mountpoint ou mp) alors le partage doit également être un point de montage. Si ce n’est pas le cas, alors le partage n’est pas fait.Ceci vous permet d’être sûr que le répertoire d’un point de montage ne sera jamais partagé par accident si, par exemple, le montage du système de fichiers échouait suite à une erreur de disque dur.Si un chemin est précisé (c.-à-d. mountpoint=/chemin ou mp=/chemin), le chemin indiqué doit être un point de montage pour le partage qui est fait.
• fsid=num|root|uuid : NFS a besoin de reconnaître chaque système de fichiers qu’il offre en partage.Habituellement, il utilisera un UUID pour ce système de fichiers (si le système de fichiers dispose d’un tel UUID) ou de l’identifiant du périphérique qui héberge ce système de fichiers (si le système de fichiers est stocké sur un périphérique).Puisque tous les systèmes de fichiers ne sont pas toujours stockés sur des périphériques, et qu’ils n’ont pas toujours un UUID, il sera parfois nécessaire de spécifier comment NFS identifiera un système de fichiers. C’est le rôle de l’option fsid=.Dans NFSv4, un système de fichiers particulier est la racine de tous les systèmes de fichiers partagés. Il est défini par fsid=root ou fsid=0, qui veulent tous deux dire exactement la même chose.Les autres systèmes de fichiers peuvent être identifiés avec un entier court, ou un UUID qui doit comporter 32 caractères hexadécimaux et une ponctuation arbitraire.

  Les versions du noyau Linux 2.6.20 et précédentes ne comprennent pas les réglages UUID, l’utilisation d’un entier court est donc nécessaire pour définir l’option fsid.

  La définition conjointe d’un petit nombre et d’un UUID est possible pour une même configuration, ce qui rend possible l’utilisation avec d’anciens ou de nouveaux noyaux.

Afin de voir depuis le serveur les répertoires exportés :

 # showmount -e 
Export list for sanux01: 
/home/ftp webinux /home/Videos mediatux,webinux /home/Musiques mediatux,webinux

 

4 – Configuration du client NFS

 

Il est possible de monter les volumes nfs directement en ligne de commande :

 # mount 192.168.1.1:/home /mnt/

Cette ligne de commande montera le système de fichier /home du serveur NFS dans le répertoire /mnt du client.

Il est plus courant de monter un volume NFS au démarrage d’un client.

Ceci se fait via le fichier /etc/fstab dont voici un exemple :

192.168.1.1:/home /home nfs rw,rsize=4096,wsize=4096,hard,intr,async,nodev,nosuid 0 0

Voici la description des options ci-dessus :

• soft / hard : Définit le comportement de récupération du client NFS lorsqu’une requête NFS ne répond pas (time out).Si aucune option n’est indiquée (ou si c’est l’option hard qui a été choisie), les requêtes NFS sont retentées indéfiniment.Si par contre l’option soft a été choisie, le client NFS sera en échec après l’envoi de retransmissions, entraînant alors le retour d’une erreur à l’application appelante.Avec Soft, il peut y avoir une corruption des données.
• intr / nointr : Indiquer si les signaux peuvent interrompre les opérations sur les fichiers pour ce point de montage. Si aucune option n’est indiquée (ou si intr est choisi), les appels systèmes renvoient EINTR si une opération NFS en cours est interrompue par un signal. Si nointr est indiqué, les signaux n’interrompent pas les opérations NFS.
• async/sync : Cette option ne permet pas au serveur de répondre à des requêtes avant que les modifications effectuées par la requête ne soient enregistrées sur le disque. Cette option correspond à sync. Si elle n’est pas sélectionnée, l’option async est utilisée.
• rsize / wsize : Nombre maximum d’octets pour chaque requête réseau en LECTURE / ECRITURE que peut recevoir le client NFS lorsqu’il lit les données d’un fichier sur le serveur NFS.La charge utile gérée par le client NFS Linux est de 4096 minimum à 1 048 576 octets (un méga-octet) maximum.

5 – Conclusion

 

Voici un petit survole du protocole NFS et de sa mise en place. Dès que j’ai un peu de temps, j’ajouterai un chapitre sur son optimisation.

---

Article lu 1420 fois