Mai 2013 Archives
mardi 21 mai 2013, 22:17:06 (UTC+0200)
NIS, NFSv4, autofs5 & dual stack IPv4 + IPv6
Pour employer une formule marketing à 2€cts, la collection des acronymes donnés dans le titre constitue un «savoureux mélange» entre anachronisme et modernité. Ceci-dit, je me doute bien qu'à la lecture du même titre, d'aucuns auront déjà trouvé que la mixture est on ne peut plus indigeste ! Enfin, n'ayant plus du peur du ridicule, voici une petite introduction sur ce faux-nouveau support : Association NIS, NFSv4 et autofs.
Après avoir adapté les supports de la rubrique développement à IPv6, je me suis posé la question de faire le même travail sur les autres supports de travaux pratiques. Écrire une version IPv6 séparée pour chaque séance de travaux pratiques obligerait à maintenir deux versions pour un même document. Au delà de la quantité de travail, il y a fort à parier qu'une version IPv6 isolée ne serait jamais utilisée vu ce que l'on sait de l'engouement général pour adopter rapidement ce protocole. Il restait donc l'option du document unique double pile ou dual stack dans le jargon. À titre d'entraînement, j'ai repris un vieux support abandonné qui associe trois services.
- Network Information Service (NIS) permet le partage des paramètres de compte utilisateur. C'est un service démodé qui ne fonctionne qu'avec la pile IPv4 ; ce qui le rend intéressant dans le contexte présent.
- Network File System (NFS) est le système de fichiers réseau de prédilection dans le monde Unix. Sa version 4 fonctionne très bien avec la pile IPv6.
- Automounter (autofs) permet l'accès transparent au système de fichiers réseau. On l'utilise lors de la connexion d'un utilisateur pour accéder simplement à son répertoire. Normalement, ce service fonctionne avec IPv6. J'ai découvert avec surprise que son utilisation d'IPv6 est assez singulière puisqu'il semble s'appuyer exclusivement sur les enregistrements DNS.
Même si le but recherché était de «croiser» les usages des deux piles de protocole de couche réseau, le résultat a dépassé mes attentes puisqu'en trois services on dispose de trois modes opératoires distincts.
Pour être complet, il faut ajouter les appels de procédures distants (RPC) sur lesquels sont basés NIS et NFS. C'est justement ce mécanisme qui autorise le mixage entre les deux piles IPv4 et IPv6.
# rpcinfo -s ip6-srvr.fake.domain program version(s) netid(s) service owner 100000 2,3,4 local,udp,tcp,udp6,tcp6 portmapper superuser 100004 1,2 tcp,udp ypserv superuser 100009 1 udp yppasswdd superuser 100003 4,3,2 udp6,tcp6,udp,tcp nfs superuser 100227 3,2 udp6,tcp6,udp,tcp - superuser 100021 4,3,1 tcp6,udp6,tcp,udp nlockmgr superuser 600100069 1 tcp,udp fypxfrd superuser 100007 1,2 tcp,udp ypbind superuser 100005 3,2,1 tcp6,udp6,tcp,udp mountd superuser
autofs troubleshooting
Comme je l'ai dit plus haut la version du paquet autofs fourni dans la branche testing semble se baser uniquement sur les enregistrements DNS. Voyons comment je suis parvenu à cette conclusion.
- On commence par un montage statique de l'arborescence depuis le
poste client.
# mount -t nfs4 [2001:db8:feb2:10::12]:/home /ahome root@clnt:/home/etu# ls -lAh /ahome/etu-nis/ total 16K -rw------- 1 etu-nis etu-nis 385 mai 21 2013 .bash_history <snip/> # mount | grep nfs4 [2001:db8:feb2:10::12]://home on /ahome type nfs4 \ (rw,relatime,vers=4,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp6, \ timeo=600,retrans=2,sec=sys,clientaddr=2001:db8:feb2:10::11,minorversion=0, \ local_lock=none,addr=2001:db8:feb2:10::12)
Le montage statique utilisant les adresses IPv6 fonctionne. Rien d'original. - On passe à l'utilisation du démon automount avec des
fichiers de configuration complétés directement sur le poste
client, toujours avec une adresse IPv6 numérique.
# cat /etc/auto.master /ahome /etc/auto.home # cat /etc/auto.home * -port=2049,-fstype=nfs4 [2001:db8:feb2:10::12]:/home/& # service autofs start [ ok ] Starting automount.... # automount -m autofs dump map information =========================== global options: none configured Mount point: /ahome source(s): instance type(s): file map: /etc/auto.home * | -port=2049,-fstype=nfs4 [2001:db8:feb2:10::12]:/home/&
La configuration a bien été prise en compte par le démon ...# ls -lAh /ahome/etu-nis ls: impossible d'accéder à /ahome/etu-nis: Aucun fichier ou dossier de ce type # tail -3 /var/log/syslog clnt automount[3652]: attempting to mount entry /ahome/etu-nis clnt automount[3652]: mount(nfs): no hosts available clnt automount[3652]: failed to mount /ahome/etu-nis
Catastrophe ! Le montage automatique échoue. - On reprend la même expérience avec un nom d'hôte DNS dont les
enregistrements AAAA et PTR sont valides.
# service autofs start [ ok ] Starting automount.... # automount -m autofs dump map information =========================== global options: none configured Mount point: /ahome source(s): instance type(s): file map: /etc/auto.home * | -port=2049,-fstype=nfs4 vm2.fake.domain:/home/& # dig +short aaaa vm2.fake.domain 2001:db8:feb2:10::12 root@clnt:/home/etu# dig +short -x 2001:db8:feb2:10::12 vm2.fake.domain.
L'adresse IPv6 utilisée est bien identique à celle du test précédent.# ls -lAh /ahome/etu-nis total 16K -rw------- 1 etu-nis etu-nis 385 mai 21 23:44 .bash_history <snip/> # tail -3 /var/log/syslog clnt automount[3759]: mounted indirect on /ahome with timeout 300, freq 75 seconds clnt automount[3759]: attempting to mount entry /ahome/etu-nis clnt automount[3759]: mounted /ahome/etu-nis
Bingo ! Cette fois-ci le montage se fait correctement. Enfin, si les paramètres de configuration sont publiés via NIS, ça fonctionne aussi.
Voilà. On peut considérer que le choix consistant à associer les trois services est pertinent puisqu'il illustre des usages distincts de la pile IPv6. À mon niveau de connaissances, je ne sais pas si le fait d'imposer l'utilisation des enregsitrements DNS par le démon automount est volontaire.
Dans tous les cours sur IPv6, il est courant de dire que comme le format numérique des adresses IPv6 est très difficile à retenir, l'usage des enregistrements DNS est impératif. Pour généraliser l'utilisation de la double pile réseau, il semble qu'il faille revoir la séquence des travaux pratiques. Je vais devoir aborder le service DNS au tout début de façon à en bénéficier pour le cycle sur le stockage et les systèmes de fichiers réseau. En conclusion, le support de travaux pratiques DNS est le prochain sur la liste !
Posté par Philippe Latu | permalien | dans : nfs, travaux_pratiques, système | Read it in english with Google