Yellow Pages 3 : le côté serveur

Résumé:

Cet article détaille pas à pas l'installation d'un serveur NIS. Nous verrons les programmes impliqués, les fichiers de configuration et la construction de la base de données.

Introduction

Dans l'article précédent, nous avons vu comment configurer un client NIS et avons évoqué les problèmes de sécurité de ce service (enfin ... si on peut parler de problème dans la mesure où les concepteurs de NIS n'avaient pas cette préoccupation).

Ici, nous verrons comment configurer son serveur et nous donnerons quelques conseils pour l'utilisation de NIS.

Avis au lecteur

Avant de commencer, une précision. Jusqu'à présent, nous n'avons parlé que de "NIS". Cependant, il en existe deux variantes : celle que nous appellerons "NIS traditionnel" et NYS. Dans la pratique, il y a peu de différence entre les deux (en particulier pour la configuration, que ce soit pour un client ou un serveur). Le "NIS traditionnel" a plus de vécu, mais ne supporte pas toutes les nouveautés, comme les shadow passwords gérés de manière transparente par NYS.

Enfin, nous traitons ici le cas d'une version récente de ypserv (i.e. version supérieure à la 1.3.2 pour avoir la gestion des shadow passwords entre autre) fournit avec la RedHat 6.1 : il s'agit donc d'un serveur NYS et non d'un "NIS traditionnel" ... mais nous continuerons à parler indistinctement, et abusivement, de NIS.

Le serveur NIS

Il existe 2 serveurs NIS : ypserv et yps. D'après l'auteur du NIS-HOWTO, leur configuration diffère légèrement. De plus, yps n'est plus maintenu par son auteur et comporte de grosses failles de sécurité. Nous ne traiterons donc que la cas de ypserv.

Nous présenterons d'abord la démarche à entreprendre pour installer un serveur. Nous détaillerons au fur et à mesure le rôle des différents fichiers de configuration intervenant dans l'installation du serveur.

Dans la suite de l'article, nous travaillerons sur la machine "charly". Le domaine NIS portera comme nom "bosley". Les serveurs esclaves seront "sabrina", "jill" et "kelly".

Installation

Tout d'abord, il faut s'assurer que le démon portmap fonctionne. Si ce n'est pas le cas, vous devez le démarrer.

On fixe ensuite le nom de domaine NIS. Il ne s'agit toujours pas du nom de domaine au sens DNS, mais bien au sens des YPs. Ce nom doit être différent de celui de la machine pour des raisons de sécurité.

La commande domainname permet de ... fixer le nom de domaine :-) Dans notre cas, nous exécuterons donc :

root@charly >> /bin/domainname bosley

Cette commande fixe le nom de domaine NIS en mémoire. Toutefois, quitte à configurer un serveur, on aimerait bien que ce soit fait automatiquement au démarrage de la machine. Pour cela, il faut ajouter une ligne au fichier de configuration réseau /etc/sysconfig/network :

NISDOMAIN=bosley

Ainsi, lors de l'initialisation du réseau au prochain reboot, le nom de domaine NIS sera automatiquement fixé.

L'étape suivante consiste à démarrer le démon ypserv. Il faut préalablement le configurer par le biais du fichier /etc/ypserv.conf. C'est un fichier ASCII qui contient 3 types de ligne :

des commentaires : les lignes qui commencent par le caractère #
des options pour le démon. La ligne s'écrit alors :

option: [yes|no]

dns

hosts.*

sunos_kludge

xfr_check_port

des règles d'accès au serveur NIS. Leur format est

host:map:security:mangle[:field]

La page man de ypserv.conf détaille très clairement toutes les options et les possibilités des règles.

On peut maintenant démarrer le serveur :

root@charly >> /etc/rc.d/init.d/ypserv start

Si on veut que le serveur soit lancé automatiquement, on l'ajoute dans les fichiers d'initialisation. Pour la RedHat, ça donne :

root@charly >> /sbin/chkconfig --levels 345 ypserv on

On peut vérifier que tout cela tourne correctement :

root@charly >> /usr/sbin/rpcinfo -u localhost ypserv
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting

Avant de se lancer dans la construction de la base, revenons sur ce que nous avons évoqué dans le premier article. Nous avons vu qu'il existait 2 types de serveurs : le maître et ses esclaves. Le maître contient la base NIS de référence, les esclaves n'en possèdent qu'une copie. Ils servent à décharger le maître d'un trop plein de requêtes. La base ne sera construite que sur le serveur maître. Ensuite seulement, elle sera recopiée sur les serveurs esclaves.

Tout est donc en place maintenant ... sauf la base de données. Il ne reste donc plus qu'à la construire. Et qui dit construire dit Makefile ;-] Rassurez-vous, celui-ci est déjà écrit et il suffit d'y ajuster quelques variables. Il se trouve dans le répertoire /var/yp. Il est abondamment et clairement commenté. La ligne la plus importante est celle définissant les maps prises en charge par NIS. Sur charly, on a :

all: passwd group hosts rpc services netid protocols mail shadow \
# netgrp publickey
# networks ethers bootparams printcap \
# amd.home auto.master auto.home passwd.adjunct

Par rapport à ce qui est donné par défaut, on a voulu ajouter la gestion des shadow passwords. Il faut donc aussi changer la valeur de la variable MERGE_PASSWD de "true" en "false". En effet, elle stipule, pour la construction de la base NIS, de mélanger les fichiers /etc/passwd et /etc/shadow.

Dernier détail essentiel avant la création de la base NIS, la gestion de ses droits d'accès. Il existe 2 méthodes pour gérer les accès au serveur : soit il se débrouille tout seul, soit il passe par tcp_wrapper. Ce dernier cas ne sera pas détaillé ici.

Si vous avez seulement une version binaire de ypserv, l'option -v permet de savoir avec quelle configuration votre binaire a été compilé :

root@charly >> /usr/sbin/ypserv -v
ypserv - NYS YP Server version 1.3.9 (with securenets)

Le fichier /var/yp/securenets contient des paires netmask/network afin de contrôler l'accès au serveur. Il faut impérativement modifier ce fichier : par défaut, il contient la ligne

0.0.0.0 0.0.0.0

qui permet à tout le monde d'accéder à votre serveur NIS. Il est à noter que seules les adresses IP sont reconnues dans ce fichier (pas les noms de machines).

Nous pouvons maintenant construire la base de données NIS. Nous utiliserons la commande ypinit qui construit le sous-répertoire dans /var/yp portant le nom de domaine (bosley dans notre cas). La base de donnée est fabriquée à partir des informations contenues dans la mémoire de l'ordinateur (pour le nom de domaine par exemple) et à partir de fichiers textes contenus dans /etc. (par défaut, mais on peut spécifier un autre répertoire dans le Makefile). Ce sont ces fichiers qui contiennent les données fournies à la base (/etc/passwd, /etc/group, /etc/hosts, /etc/networks, /etc/services, /etc/protocols, /etc/netgroup, /etc/rpc).

L'option -m permet d'initialiser le serveur à partir de ces données brutes (-m pour master), l'option -s recopie la base de données du serveur maître sur un esclave (-s pour slave - esclave en Anglais).

Sur charly, nous initialisons donc notre base ainsi :

root@charly >> /usr/lib/yp/ypinit -m
At this point, we have to construct a list of the hosts which will run NIS
servers. localhost is in the list of NIS server hosts. Please continue to add
the names for the other hosts, one per line. When you are done with the
list, type a <control D>.
        next host to add: localhost
        next host to add: sabrina
        next host to add: jill
        next host to add: kelly
        next host to add:
The current list of NIS servers looks like this:
localhost
sabrina
jill
kelly
Is this correct? [y/n: y] y
We need some minutes to build the databases...
Building /var/yp/bosley/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/bosley'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
Updating shadow.byname...
# shadow publickey # networks ethers bootparams printcap \
# amd.home auto.master auto.home passwd.adjunct
gmake[1]: Leaving directory `/var/yp/bosley'

Et voila une bonne chose de faite, la base de données est en place :) Pour le cas des serveurs esclaves, il faut maintenant exécuter sur chacun d'eux la commande :

root@kelly >> /usr/lib/yp/ypinit -s charly

Pour s'assurer que tout tourne correctement, il suffit de faire se transformer un serveur, qu'il soit maître ou esclave, en un client et d'exécuter une requête. Par exemple, sur charly :

root@kelly >> ypcat passwd mulder:x:500:100::/home/mulder:/bin/csh scully:x:501:100::/home/scully:/bin/bash

On remarque au passage que les shadow passwords fonctionnent correctement :)

Installation d'un serveur NIS

Initialiser portmap ;
Fixer le nom de domaine NIS ;
Préparer le fichier de configuration du serveur NIS : /etc/ypserv.conf ;
Démarrer le démon ypserv ;
Dans /var/yp/Makefile, sélectionner les maps qui seront gérées par ypserv puis ajuster les options de compilation ;
Définir les droits d'accès au serveur NIS dans le fichier /var/yp/securenets ;
Création de la base NIS maître à l'aide de la commande ypinit -m ;
Création des bases esclaves avec ypinit -s <serveur maître> ;

Mise à jour de la base NIS

Dès qu'on veut modifier une map, par exemple en ajoutant un nouveau serveur esclave ou en ajoutant un nouvel utilisateur, il faut remettre à jour la base NIS. Détaillons les cas précités.

Pour ajouter un serveur esclave, il suffit d'exécuter /usr/lib/yp/ypinit -s charly sur le nouveau serveur esclave et d'ajouter son nom dans le fichier /var/yp/ypservers du serveur maître.

Si on crée un nouvel utilisateur, plusieurs maps peuvent avoir changé (passwd, shadow, alias, etc ...).

Dès qu'on modifie une map, il ne faut pas oublier de faire alors un make dans le répertoire /var/yp/ sur le serveur maître : celui-ci met à jour sa base de données en intégrant les nouvelles informations et les distribue à ses esclaves (via la commande yppush).

Le programme rpc.ypxfrd permet d'accélérer les transactions entre un serveur maître et ses esclaves. Il permet à un esclave de recopier la base du serveur maître, plutôt que de reconstruire la sienne intégralement.rpc.ypxfrd doit démarrer en même temps que ypserv et uniquement sur le serveur maître. Ce programme sert essentiellement pour les très grosses maps.

Derniers conseils d'utilisation

Tout le monde reconnaît que NIS n'est pas sécurisé. Toutefois, les services qu'il rend sont tellement appréciables qu'il serait regrettable de s'en priver. Il faut donc prendre quelques précautions, externes à NIS, lorsqu'on veut l'utiliser.

Tout comme certains mots de passe qu'on peut facilement deviner, beaucoup de systèmes emploient un nom de domaine NIS prévisible. Des candidats évidents, une fois découvert le nom du serveur NIS, sont par exemple le nom (complet ou partiel) de ce serveur ou encore le nom de l'organisation à laquelle appartient le serveur. ypwhich permet justement de tester des noms de domaine !

Le nom de domaine NIS apparaît à plusieurs endroits, et notamment dans le répertoire /var/yp, où un sous-répertoire est crée à l'installation de NIS (sur le(s) serveur(s), mais aussi sur les clients) : il porte le nom du domaine NIS. Il faut donc bien contrôler les droits d'accès à ce répertoire. En particulier, il ne faut jamais l'exporter, même en read only, via NFS. En effet, n'importe qui peut alors monter le répertoire sur sa propre machine pour découvrir le nom de domaine.

Par ailleurs, l'utilisation de tcp_wrapper n'est pas un mal. En effet, vous pouvez ainsi contrôler le service portmap pour éviter que tout le monde puisse lancer des requêtes RPCs vers votre machine.

Une bonne chose à faire également est de ne pas configurer le routage par défaut sur votre serveur NIS, mais de n'utiliser que du routage statique vers tous les clients et serveurs esclaves. Le serveur ne connaissant alors que quelques routes vers des machines bien détérminées, il ne peut donc pas répondre à des requêtes provenant d'une machine inconnue.

Au niveau du routeur, un firewall permet également de contrôler efficacement les accès aux serveurs NIS.

Ces conseils relèvent essentiellement du bon sens. Ils n'augmentent pas la sécurité de NIS, mais le cadre qui est autour. Malgré ce problème, NIS reste un outil efficace et surtout pratique.

Documentation

NIS-HOWTO : comme tous les HOWTOs, très complet et indispensable pour apprendre plein de choses

http://www.suse.de/~kukuk/

Network Administrators' Guide

http://www.linuxdoc.org/LDP/nag

Discussion sur cet article

Chaque article possède sa page de discussion. Vous pouvez y soumettre un commentaire ou lire ceux d´autres lecteurs:

page de discussion

Site Web maintenu par l´équipe d´édition LinuxFocus
© Frédéric Raynal, FDL
LinuxFocus.org
Cliquez ici pour signaler une erreur ou envoyer un commentaire à Linuxfocus

Translation information:

fr --> -- : Frédéric Raynal <pappy(at)users.sourceforge.net>

2001-10-22, generated by lfparser version 2.18

mirror server hosted at Truenetwork, Russian Federation.