Relations entre serveurs maîtres LA SÉCURITÉ L'absence de contrôle entre client et serveur

La gestion de multiples domaines

Nous avons vu lors de la description du démon ypserv qu'un site serveur peut être serveur de plusieurs domaines. Il y a plusieurs relations possibles :

Un serveur NIS peut être serveur esclave de plusieurs serveurs maîtres s'il fournit des services à de multiples domaines.

Un serveur peut être serveur maître d'un domaine et esclave pour un autre.

EXEMPLE : nous avons testé le cas suivant :

iris3 est serveur maître du domaine reso et esclave de sunny.

ypinit -m                       (domaine par défaut : reso)

domainname sunny       (domaine par défaut : on reviendra ensuite à reso)

ypinit -s aria           (aria serveur maître de sunny)

on peut vérifier sur iris3 après reboot de la machine :

ypwhich

>iris3

ypwhich -d sunny

>localhost

NOTE : Pour que cela fonctionne correctement, les serveurs esclaves qui gèrent plusieurs domaines doivent être déclarés dans le fichiers ypservers de chaque domaine.

Sunny et reso sont et restent deux domaines indépendants : ils n'ont pas les mêmes administrateurs, ils ne partagent pas les mêmes informations. Utiliser un serveur qui soit maître et esclave n'a pas vraiment d'intérêt sinon augmenter le nombre de serveurs sur chaque domaine. Mais dans ce cas le risque de congestionner un serveur par du trafic supplémentaire n'est pas nul, surtout si le nombre de clients est important.

Par contre, lors de l'utilisation de multiples domaines avec des serveurs NIS indépendants, il peut être utile et parfois nécessaire de synchroniser une ou plusieurs tables de ces domaines.

Prenons le cas d'une société qui possède des départements indépendants les uns des autres et qui dispose d'un seul administrateur. Celui-ci choisit d'affecter un domaine par département avec des fichiers passwd et group qui sont propres à chaque domaine. Les utilisateurs sont indépendants et n'ont aucun lien avec les autres domaines. Il peut partager les tables hosts et aliases (pour le courrier électronique) de façon globale pour faciliter l'administration.

EXEMPLE : Un nouvel utilisateur apparaît dans un domaine, son alias mail ajouté au fichier global des alias est partagé par tous les domaines et tous les clients de chaque domaine y ont accès. A l'inverse, son identité, ajoutée à la table passwd spécifique d'un domaine n'apparaîtra pas automatiquement dans les autres.

On repréente cette situation par le schéma :

Cela donne aux administrateurs un contrôle plus fin sur l'accès des utilisateurs aux machines et facilite leur travail.

• Relations entre serveurs maîtres

Relations entre serveurs maîtres LA SÉCURITÉ L'absence de contrôle entre client et serveur