ypbind Le fonctionnement : client - maître - esclave Le fonctionnement : client - maître - esclave

ypserv

C'est le démon qui fournit tous les services NIS.

Le protocole NIS comprend trois types de procédures RPC. Les procédures de recherche à l'usage des clients, des procédures servant à la maintenance des tables et des procédures NIS internes.

Les procédures de recherche prennent comme argument une clé et retourne un enregistrement du fichier DBM par appel. (yp_match(), yp_first(), yp_next(), yp_all())

Les procédures de maintenance de table sont utilisées lors de négociations de transfert de table entre serveurs maître et esclaves (getmaster() indique le serveur maître de la table, getorder() retourne l'estampille de génération de la table).

Les procédures internes servent à effectuer les transferts de tables et répondre aux requêtes à un service pour un domaine.

Le démon ypserv ne connaît pas intrinsèquement le domaine qu'il doit servir. Il ne connaît pas le nombre de maps ni de quelles maps il dispose. Il ne sait que répondre à une requête si le répertoire /var/yp/domainname existe. Ce qui veut dire qu'un serveur peut «gérer» plusieurs domaines. Il suffit que les tables se trouvent dans le bon répertoire.

Il n'existe pas de procédure RPC pour interroger le serveur sur l'existence d'une table. Si la table est présente il répondra, sinon l'erreur «no such map» est retournée lorsque la requête échoue. NIS ne prévoit aucun mécanisme pour ce type de problème.

L'administrateur doit donc veiller à ce que le serveur ait toutes les tables à jour. Notamment en utilisant cron et ypmake pour que serveurs maître et esclaves soient toujours synchronisés.