Yellow Pages 2 : Le côté client

ArticleCategory:

AuthorImage:

TranslationInfo:

Original in fr

AboutTheAuthor:

Abstract:

ArticleIllustration:

ArticleBody:

Introduction

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étaillerons 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

ypbind

ypbind établit une liaison entre le client et le serveur NIS (to bind signifie, entre autre, 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 :

• domain nisdomain server hostname : le client s'adresse à hostname pour le domaine nisdomain ;
• domain nisdomain broadcast : le client fait un broadcast sur le réseau local pour ce qui concerne le domaine nisdomain ;
• ypserver hostname : le client s'adresse directement à hostname pour le domaine local. Dans cette configuration, l'adresse IP du serveur doit figurer dans le /etc/hosts.

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 :
   • "rpc -p localhost" devrait produire :

     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

   soit
   • "rpcinfo -u localhost ypbind" qui doit afficher :
     

     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.

Derniers détails

• /etc/host.conf : ajouter "nis" pour la recherche des hosts ;
• /etc/passwd : il faut ajouter la ligne
  +::::::
  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 qu'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³
  +@sysadmins:::::::
  autorisera les connexions des membres du netgroup sysadmin.
• /etc/group (et/ou /etc/shadow pour certaines versions de la libc) : comme pour /etc/passwd, il faut ajouter
  +:
  On peut également jouer avec les autorisations sur les groupes à l'aide de + et -.
• /etc/nsswitch.conf : le Network Services Switch permet de préciser l'ordre dans lequel les informations doivent être recherchées, de la même manière qu'avec /etc/host.conf. Les choix portent entre :

  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 option 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

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 serveur 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

• domainname : renvoie (ou fixe selon l'option) le nom du domaine NIS ;
• ypcat : affiche les valeurs de toutes les clés contenues dans une map NIS ;
• ypmatch : affiche les valeurs d'une ou plusieurs clés contenues dans une map NIS ;
• ypset : permet de préciser à quel serveur NIS ypbind doit se connecter ;
• ypwhich : renvoie le nom du serveur NIS. Avec l'argument -m suivi d'un nom de map, renvoie le nom la map master.
• yppoll : prend une map en argument et renvoie le nom du domaine et le serveur master.

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ème 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

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 qu'on peut 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 passes, sauf au champs "passwd". Seul le propriétaire du champs "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 des besoins de sécurité important. 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.

Footnotes

... var/yp/binding¹

Les localisations des fichiers seront rarement précisées car elles varient d'une distribution à l'autre. Par exemple, pour avoir un démon ypbind lancé au démarrage : /etc/init.d/nis, /sbin/init.d/ypclient, /etc/rc.d/init.d/ypbind, /etc/rc.local

... broadcast²

ceci signifie que le message est émis sur tout le sous-réseau sans destinaire précis avec une adresse du type X.Y.0.0

... netgroup³

Le fichier /etc/netgroup défini des groupes composés de triplets (host, user, domain) servant pour vérifier des permissions quand on utilise des commandes "à distance" (remote logins, shells ou mount par exemple). Voir la page man pour plus de détails.