L'article précédent était une introduction aux concepts gravitant autour des yellow pages (YPs). Dans celui-ci, nous verrons comment configurer son client, un exemple pratique du fonctionnement du client et une présentation des différents outils qui vont avec. Enfin, nous toucherons quelques mots de NIS+.
Le côté client des services liés aux yellow pages repose essentiellement sur le démon ypbind : il émet les requêtes vers le serveur des YPs. Nous détaillons d'abord son fonctionnement et expliquerons comment le configurer. Ensuite, nous verrons également comment fonctionne le protocole NIS. Enfin, la dernière partie de cet article présentera les différents outils présents du côté client des YPs (les yp-tools).
Configurer son client NIS
La seule chose à faire pour faire tourner un client NIS sur une machine est de lancer le démon ypbind.
ypbind
ypbind établit une liaison entre le client et le serveur NIS (to bind signifie, entre autres, lier ou attacher en anglais). Ce lien est visible dans le répertoire /var/yp/binding au travers du fichier conventionnellement appelé domainname.version. La seule version actuellement supportée est la version 2. Donc, si mon nom de domaine NIS est «messie», le fichier sera messie.2 Le programme ypbind appartient au super-utilisateur (i.e. root), il doit donc se trouver soit dans /sbin, soit dans /usr/sbin.
Quand il est lancé, ypbind va chercher ses instructions dans le fichier /etc/yp.conf. Les entrées de ce fichier sont :
Si ce fichier de configuration est incorrect ou n'existe pas, ypbind broadcast sur tout le réseau local à la recherche d'un serveur NIS pour le domaine local. Quelques opérations élémentaires permettent de vérifier que ypbind est correctement configuré.
1. créer son fichier /etc/yp.conf
2. vérifier que portmap fonctionne (ps aux | grep portmap). Si ce n'est pas le cas, le lancer. Ce programme associe les ports TCP/IP
(ou UDP/IP) de l'ordinateur aux programmes. A l'initialisation d'un serveur RPC, celui-ci signale à portmap les ports qu'il écoute
et les numéros de programmes qu'il est susceptible de lancer. Quand un client adresse une requête RPC vers un numéro de programme donné,
il contacte d'abord portmap pour connaître le port vers lequel les paquets RPC doivent être expédiés. Comme l'illustre le fonctionnement
décrit précédemment, il est donc bien nécessaire que portmap soit initialisé avant ypbind;
3. créer le répertoire /var/yp;
4. lancer ypbind
5. utiliser la commande rpcinfo pour s'assurer que ypbind fonctionne correctement :
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100007 2 tcp 637 ypbind 100007 2 udp 639 ypbind ou program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100007 2 udp 758 ypbind 100007 1 udp 758 ypbind 100007 2 tcp 761 ypbind 100007 1 tcp 761 ypbind
program 100007 version 2 ready and waiting ou program 100007 version 1 ready and waiting program 100007 version 2 ready and waiting
en fonction de la version de ypbind. Le message important est celui portant sur la version 2.
Maintenant que ypbind fonctionne correctement, votre machine est devenue un client NIS. Vous pouvez donc vous en servir pour adresser des requêtes à votre serveur. Par exemple, "ypcat passwd.byname" renvoie tous les mots de passe, triés par nom d'utilisateur présent dans la map correspondante.
Derniers détails
Quelques fichiers doivent encore subir de légères modifications pour que les YPs fonctionnent de manière efficace :
+::::::
Ceci autorise toutes les personnes présentes dans la map du serveur à se connecter sur le client. On peut affiner ces autorisations à l'aide des symboles + et - pour autoriser ou interdire l'accès au client. Par exemple pour interdire l'utilisateur guest, il suffit d'ajouter la ligne
-guest::::::
Les champs que l'on ne souhaite pas modifier doivent rester vides. On peut toutefois en surcharger :
+moi::::::/bin/ksh
L'utilisateur "moi" utilisera ksh au lieu de son shell habituel (défini dans le /etc/passwd du serveur NIS). Dernier point important, NIS supporte parfaitement l'utilisation des netgroups
+@sysadmin::::::
autorisera les connexions des membres du netgroup sysadmin.
+:
On peut également jouer avec les autorisations sur les groupes à l'aide de + et -.
nisplus chercher via NIS+ (i.e. NIS version 3, une version sécurisée de NIS) nis chercher via NIS (NIS version 2, alias les YPs) dns chercher via un DNS (Domain Name Server) files chercher dans les fichiers locaux db chercher dans la base /var/db
Après chaque opération de recherche, on peut utiliser une commande de la forme '['('!'? STATUS '=' ACTION)+']' avec :
STATUS => "success" ou "notfound" ou "unavail" ou "tryagain"
ACTION => "return" ou "continue"
En fonction de la libc utilisée, les recherches ne sont pas toutes les mêmes. Par exemple, les shadow passwords ne sont pas gérés avec la libc5. Les services supportés sur une machine utilisent une librairie /lib/libnss_SERVICE.so.X. Pour plus de renseignements sur ce service, voir la page man de nsswitch.conf. En ce qui concerne les shadow passwords via NIS, leur support n'est possible qu'avec la glibc 2.x. Il faut alors penser à le spécifier dans le fichier nsswitch.conf.
Le protocole NIS
Maintenant que notre client NIS est complètement opérationnel, nous allons voir comment il se débrouille pour récupérer les informations dont il a besoin.
Quand un client à besoin d'une information contenue dans une map des YPs, il commence par chercher un serveur YP. Pour le trouver, il ouvre une connexion TCP vers le ypbind local. Le client l'informe du domaine (on parle ici du domaine NIS) auquel il appartient et ypbind broadcast via la fonction RPC YPPROC_DOMAIN_NOACK. Les serveurs NIS qui servent ce domaine répondent avec un ACK, les autres font la sourde oreille.
ypbind renvoie au client le résultat de la recherche (échec ou réussite) et, s'il l'a, l'adresse du premier serveur YP qui a répondu. Le client peut maintenant adresser à ce serveur sa requête, composée du domaine, de la map, puis de la clé. Ce protocole est assez lent car il utilise des connexions TCP. De plus, il emploie également beaucoup de sockets. Pour éviter ceci, ypbind n'attend pas qu'un client le contacte pour trouver les serveurs. En fait, il conserve dans le fichier /var/yp/binding/. une liste de serveurs pour chaque domaine et vérifie régulièrement qu'ils fonctionnent correctement.
Les yp-tools
Cette section présente très rapidement quelques outils contenus dans le package yp-tools. Pour en savoir plus, chacune de ces instructions dispose d'une page man très détaillée ;-P
Quelques mots de NIS+
Tout au long de cet article, nous n'avons à aucun moment abordé une variante de NIS, à savoir NIS+. Dans un réseau, NIS pose énormément de problèmes en terme de sécurité. Par exemple, si le serveur NIS est mal protégé et qu'une personne mal intentionnée découvre :
1. le nom du domaine NIS
2. l'adresse IP d'un client NIS
Il ne lui reste alors qu'à se faire passer pour la machine avec l'IP du client et envoyer un ypcat passwd pour récupérer tranquillement le fichier des mots de passe :-(
NIS+ offre une couche de sécurité supplémentaire en intégrant un protocole d'authentification fondé sur un échange de clés et supporte le chiffrement des données. Les données sont conservées dans des tables, elles-mêmes étant dans différents répertoires. Chaque colonne d'une table dispose de qualificatif précisant, par exemple, si les données sont «case sensitive», en format binaire, etc.
La structure décrite précédemment permet simplement de gérer des droits d'accès sur les répertoires et les tables, mais également sur les colonnes des tables. Ceci implique que l'on puisse interdire l'accès à la table des mots de passe à tout utilisateur qui ne s'est pas authentifié auprès du serveur NIS+, mais autoriser tous les utilisateurs certifiés à accéder à toute la table des mots de passe, sauf au champ «passwd». Seul le propriétaire du champ «passwd» pourra le voir.
Il existe 4 niveaux de droits :
1. Nobody (personne) : l'utilisateur n'est pas authentifié;
2. Owner (propriétaire) : l'utilisateur est authentifié et il est le propriétaire;
3. Group (groupe) : l'utilisateur est authentifié et il est dans le groupe pour cet objet;
4. World (monde) : l'utilisateur est authentifié mais il n'est ni propriétaire, ni dans le groupe pour cet objet.
Dans cette configuration, root n'est plus qu'un utilisateur comme les autres ... Enfin, presque ;-) S'il n'a pas les permissions adéquates, il ne peut plus voir les mots de passe des autres utilisateurs. Il ne pourra donc plus s'authentifier comme un autre utilisateur ... mais, il pourra toujours faire tranquillement un su :)
Les données qui transiteront sur le réseau ne seront pas cryptées, à l'exception des mots de passe : aucun mot de passe ne transite en clair sur le réseau. NIS+ est un outil puissant ... mais compliqué à mettre en oeuvre. Comme Thorsten Kuduk (il travaille sur NIS, NIS+, NIS-HOWTO ... bref, quelqu'un qui sait de quoi il est question), écrit :
« Le choix entre NIS et NIS+ est facile à faire : utilisez NIS tant que vous n'avez pas de besoins de sécurité importants. NIS+ est bien plus problématique à administrer (particulièrement du côté serveur) ».
Conclusion
Nous savons maintenant comment insérer une nouvelle machine dans un réseau existant et disposant d'un serveur NIS. Nous verrons, au prochain épisode, comment configurer le serveur ainsi que son fonctionnement.