Yellow Pages

ArticleCategory:

System Administration

AuthorImage:

TranslationInfo:

AboutTheAuthor:

Frederic Raynal prépare une thèse en informatique à l'INRIA. Il aime lire (aussi bien Tolkien que Balzac) et écouter de la musique (de Mozart à Philip Glass et de Led Zeppelin à Massive Attack en passant par Björk et Boris Vian, mais en évitant soigneusement le rap, la techno et quelques autres bruits ;-)

Abstract:

Le Network Information Service (NIS) gère une base de données sur un serveur. Chaque machine du réseau sur laquelle un client NIS s'exécute peut alors interroger le serveur pour obtenir des informations (nom de login, mot de passe, renseignements sur les groupes d'utilisateurs, ...). Ceci permet une gestion centralisée et transparente d'un grand nombre de machines (surtout quand c'est, en plus, utilisé avec un système de fichiers distribué comme NFS) car les modifications des informations sont ensuite répercutées via le serveur à tous ses clients.

ArticleIllustration:

ArticleBody:

Introduction

Le Network Information Service (NIS) fut initialement crée par Sun et connu sous le nom de Sun Yellow Pages (plus communément et simplement les Yellow Pages ou YP). Toutefois, ce terme est une marque déposée par British Telecom et ne peut, de ce fait, être utiliser sans les droits adéquates. Ces Yellow Pages font référence aux mêmes que celles qui nous connaissons ici en France.

Les serveurs NIS maintiennent des copies de fichiers de configuration communs à plusieurs machines d'un réseau dans une base de données. Les clients NIS adressent alors des requêtes aux serveurs plutôt que d'utiliser leurs propres fichiers de configuration.

Mettons nous dans la situation d'un utilisateur qui souhaite changer son mot de passe sur un réseau. Supposons tout d'abord que, sur ce réseau les YPs ne soient pas installées. L'utilisateur devra aller sur tous les postes du réseau pour changer son mot de passe. En revanche, grâce aux YPs, il pourra se contenter de changer son mot de passe d'une machine quelconque sur laquelle un client NIS est lancé, le nouveau mot de passe sera ensuite transféré au serveur qui l'inscrira dans sa base de données. Ensuite, quand cet utilisateur voudra se connecter à partir d'une machine du réseau (sur laquelle il existe un client NIS bien entendu ;-), le mot de passe sera comparé à celui contenu dans la base de données du serveur.

Notons qu'il existe différentes variantes des YPs mais cet article étant une introduction, nous verrons seulement les grands principes de fonctionnement sans rentrer dans les détails que nous traiterons ultérieurement.

La glibc 2.x (libc6) supporte l'utilisation de NSS (Name Switch Service) qui détermine l'ordre dans lequel les informations doivent être recherchées (voir le fichier /etc/nsswitch.conf). Elle gère les maps aliases, ethers, group, hosts, netgroups, networks, protocols, publickey, passwd, rpc, services et shadow.

Fonctionnement

Structure

Un réseau va contenir une machine qui fera office de serveur NIS pour un domaine. Ce domaine correspond, en gros, au nom de la base de données que va gérer le serveur. Il sert de clef aux clients NIS pour qu'ils puissent trouver, sur le serveur NIS, les informations désirées. Ce nom de domaine n'a strictement rien à voir avec le nom de domaine DNS. Plusieurs serveurs NIS peuvent être installés sur un même réseau. Ils pourront chacun gérer un domaine (au sens de NIS) différent, ou bien le même domaine (auquel cas on parlera d'un serveur maître et de serveurs esclaves).

Les serveurs esclaves ne contiennent qu'une copie de la base de données du serveur maître. Ces serveurs servent à suppléer, auprès des clients, le serveur maître lorsque celui-ci est trop long à répondre ou qu'il tombe en panne.

Les serveurs esclaves sont avertis de tout changement dans la base de données par le programme yppush et ils corrigeront alors leur base de données pour qu'elle coïncide exactement avec celle du serveur maître.

Les clients, de leur côté, ne nécessitent aucun "entretien" car ils sont en contact permanent avec le serveur NIS pour trouver les informations dans sa base de données.

Les maps

Les bases de données YP sont au format GDBM, issu du format ASCII. Elles sont générées lors de l'installation du serveur par le programme makedbm.

Ces maps (cartes en Anglais - les bases de données) établissent des correspondances entre une clé et sa valeur. Toutes les maps des YPs sont construites sur ce modèle. Du point de vue du serveur, le contenu est sans aucune signification (enfin, à quelques exceptions portant sur le serveur principal ou des dates). Ceci signifie que, pour le serveur, une map de mots de passe ou de groupes ou ... ne correspond en fait qu'à une série de paires (clé, valeur). Seul le client YP sait comment parcourir ces maps en quête de l'information souhaitée.

Cette représentation des données pose un problème. Comme le serveur ne sait pas "lire" la valeur d'une clé pour y chercher une seconde clé, on est alors obligé de dupliquer les données. Par exemple, dans le cas des mots de passe, on peut vouloir les chercher soit par nom de login, soit par "numéro d'utilisateur" (user ID ou UID, identifiant propre à chaque utilisateur du réseau). Ceci se traduit par une redondance d'information, visible par la présence des fichiers passwd.byname et passwd.byuid . On crée donc une nouvelle map pour chaque clé. Ceci signifie que les données doivent être transmises deux fois lors d'un changement.

Trois informations sont nécessaires pour qu'un client trouve ce qu'il cherche dans la base de données :

le nom de domaine : c'est le nom de la base de données sur le serveur des YPs
le nom de la map
la clé souhaitée

Ainsi, pour qu'un client trouve le mot de passe de l'utilisateur Toto dans le domaine titi, il ira lire le fichier /var/yp/titi/passwd.byname sur le serveur YP à la recherche de l'utilisateur Toto .

Ceci offre une très grande souplesse d'utilisation puisque l'installation d'un nouveau domaine se résume à créer le répertoire /var/yp/nouveau_domaine, y copier le Makefile et l'exécuter avec les options souhaitées.

Les Remote Procedure Calls (RPC)

Le fonctionnement des YPs repose essentiellement sur les Remote Procedure Calls (RPCs) qui permettent les requêtes entre le serveur et les clients.

Le RPC portmapper (portmap) est un programme qui convertit les numéros de programmes RPC en numéros de ports. Quand un serveur RPC est lancé, il va préciser à portmap quel port il utilisera et les numéros de programmes RPC qu'il gère. Quand un client souhaite envoyer une requête RPC vers un numéro de programme donné, il contacte d'abord le serveur portmap pour obtenir le numéro de port sur lequel tourne le programme souhaité. Ensuite, il adresse les paquets RPC au port correspondant. Le modèle client/serveur des YPs n'est qu'un cas particulier de client/serveur RPC.

Le fichier yp_prot.h contient les structures et prototypes des 11 fonctions définissant le protocole RPC entre les clients et le serveur des YPs.

YPPROC_DOMAIN et YPPROC_DOMAIN_NOACK permettent aux clients de trouver un serveur pour un domaine donné.
Les fonctions YPPROC_MATCH, YPPROC_FIRST, YPPROC_NEXT et YPPROC_ALL permettent d'obtenir les données des maps.
YPPROC_XFR est appelé par yppush pour signaler aux serveurs esclaves que la map sur le maître a changé et qu'ils doivent mettre à jour la leur.
YPPROC_CLEAR nettoie le cache et les "file handles". Cette fonction est appelée après la mise à jour d'une map, par exemple par la commande makedbm -c.
YPPROC_MASTER, YPPROC_ORDER et YPPROC_MAPLIST permettent d'obtenir des informations spéciales sur les maps. Par exemple, pour changer de mot de passe, le programme yppasswd fait un appel à YPPROC_MASTER pour déterminer le serveur avant de changer le mot de passe.

Conclusion

Maintenant que le principe général est connu, le prochain article dévoilera l'aspect client des yellow pages : comment il fonctionne, comment le configurer, les outils dont il se sert, etc... Nous verrons également les outils nécessaires pour s'assurer de la bonne configfuration de notre client, tant pour les RPCs que pour les YPs.