Les Netgroups et la sécurité La gestion de multiples domaines La gestion de multiples domaines

Relations entre serveurs maîtres

Ce partage de table à travers les domaines nécessite d'établir une relation maître/esclave entre deux serveurs maîtres. Deux méthodes :

Le serveur maître de la table à partager peut propager le fichier source dès modification sur le serveur maître secondaire («esclave» du premier pour la table) d'un domaine. La synchronisation entre les domaines est assurée.

AVANTAGE : Le serveur maître secondaire peut reconstruire les tables à partir de la copie du fichier source. La synchronisation se fait ainsi sur les sources et non sur les tables (ou maps DBM).

INCONVÉNIENT : Pour réaliser ce transfert, le super-utilisateur doit avoir des permissions d'exécution à distance sur le serveur maître secondaire.

DÉMONSTRATION : nous créons deux domaines : iris composé des iris1, 2 et 3, et indy composé de buffet, dali et picasso. Iris3 est maître du domaine iris. Buffet est maître d'indy. Iris3 partage sa table hosts qui est donc globale aux deux domaines.

Le fichier make.script appelé par ypmake sur iris3 doit être modifié comme suit :

host.time:   ....

....
$(TOUCH) $@
echo ”copying hosts file to NIS srver buffet”
rcp $(DIR)/hosts buffet:$(DIR)/hosts
echo ”updating NIS maps on buffet”
rsh buffet ”( cd /var/yp ; ./ypmake hosts)”
....

Avec par exemple DIR=/etc/NIS configuré dans /etc/config/ypmaster.options.

L'utilisation des r-commandes rcp et rsh nécessite de modifier inetd.conf pour lancer rshd -l et la création d'un fichier .rhost contenant buffet, le serveur secondaire.

rshd -l autorise l'exécution des r-commandes sans que le mot de passe du super-utilisateur soit demandé sur les sites contenus dans le fichier .rhost.

Ce qui va à l'encontre de toutes les règles de sécurité. Quelqu'un qui parviendrait à acquérir les droits de super-utilisateur pourrait se rlogger sur toutes les machines contenues dans le fichier .rhost sans mot de passe.

La deuxième méthode consiste à ne pas propager les sources mais à déplacer les maps DBM sur le maître secondaire, qui les propagera à son tour sur ses serveurs esclaves par le script suivant :

ypxfr -h iris3 -s iris hosts.name

ypxfr -h iris3 -s iris hosts.addr

yppush -d indy hosts.name

yppush -d indy hosts.addr

L'option -s de ypxfr permet d'identifier le domaine auquel appartient le serveur maître qui détient la table commune. Ypxfr importe donc hosts.name de iris3 et tente de la propager à ses esclaves par un yppush.

Cela ne fonctionne pas sur l'implantation présente. La table transférée sur le serveur secondaire garde le nom du maître (iris3) qui l'a créé dans son estampille. Nous pensons que la source du problème est le yppush qui essaie de propager une table qui n'appartient pas au domaine indy dans notre cas.

Une solution serait que tous les serveurs esclaves du maître secondaire demande la propagation par ypxfr, ce qui n'est pas envisageable. Tout l'interêt est de rendre l'administration facile et non de la compliquer.

Les Netgroups et la sécurité La gestion de multiples domaines La gestion de multiples domaines