Répliquer les données d'un serveur OpenLDAP à un autre

Problème

Vous avez installé un annuaire LDAP sur un serveur. Vous voulez disposer d'un second serveur LDAP pour distribuer la charge ou pour éviter d'avoir un talon d'achille. Vous ne voulez pas avoir à synchroniser manuellement les données entre les deux serveurs LDAP. Est-il possible de n'effectuer les modifications que sur un seul serveur OpenLDAP et que le second soit automatiquement mis à jour ?

Solution

Il faut que le serveur maître dispose d'un compte de réplication. Il est possible que ce compte soit déclaré directement dans le fichier /etc/ldap/slapd.conf, à l'aide des directives rootdsa et rootpw, toutefois ce n'est pas recommandé car cela signifie un mot de passe en clair dans un fichier qu'il faut donc protéger. Il est préférable que le compte soit créé à l'intérieur de l'annuaire et qu'il dispose uniquement de déclarations d'ACL dans le fichier de configuration pour lui donner des droits d'administration.

Nous allons donc créer un compte de replication : ou=admin, ou=societe, ou=fr . J'ai choisi de placer le compte directement à la racine de l'arborescence LDAP (DIT), mais vous pouvez le placer où vous voulez. Je déconseille simplement de mélanger les comptes applicatifs, comme celui-ci contenat les comptes nominatifs des utilisateurs. Commencez par chiffrer un mot de passe à l'aide de la commande slappasswd :

~ # slappasswd -h '{crypt}'
New password:
Re-enter new password:
{CRYPT}EEWsAsl4nu0UY
		

Ensuite, recopiez ce mot de passe chiffré, dans un fichier LDIF, pour créer le compte d'administration :

dn: cn=admin,dc=societe,dc=fr
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: Administrateur LDAP
userPassword: {CRYPT}EEWsAsl4nu0UY
		

Vous allez maintenant charger le contenu du fichier LDIF dans votre annuaire. Comme nous allons aussi devoir lui donner des droits d'accès et que cette opération nécessite un redémarrage du démon, nous allons arrêter le démon tout de suite et effectuer le chargement du fichier LDIF en mode hors-ligne. Commencez donc par arrêter le service de l'annuaire LDAP :

~ # /etc/init.d/slapd stop
Stopping OpenLDAP: slapd.
		

Créez ensuite le compte en chargeant le contenu du fichier LDIF que vous venez de créer dans votre annuaire à l'aide de la commande de chargement hors-ligne slapadd :

~ # slapadd fichier.ldif
		

Maintenant que vous disposez d'un compte dans l'annuaire, vous allez lui donner des droits d'administration en ajoutant des règles ACL (Access Control List) dans le fichier de configuration d'OpenLDAP /etc/ldap/slapd.conf. Attention, les règles sont ordonnées, leur évaluation s'arrête à la première qui est applicable. Ajoutez-donc ces règles dans votre fichier de configuration, avant les autres règles :

access to *
	by dn="cn=admin,dc=societe,dc=fr" write
		

Nous allons maintenant ajouter au fichier de configuration les directives qui vont indiquer à slapd de journaliser les modifications appliquée à l'annuaire dans des fichiers LDIF et au démon slurpd de se connecter sur le serveur esclave pour y appliquer ces fichiers LDIF. Éditez le fichier de configuration et ajoutez-y les lignes suivantes :

replica uri=ldap://serveur.esclave.societe.fr:389
	binddn="cn=admin,dc=societe,dc=fr"
	bindmethod=simple
	credentials=xxxxxxxx
replogfile /var/lib/ldap/replication.log
		

Attention, le mot de passe est indiqué en clair. Le fichier de configuration doit désormais appartenir à l'utilisateur qui exécute les démons slapd et slurpd et seul cet utilisateur doit disposer des droits de lecture sur le fichier :

~ # chmod 600 /etc/ldap/slapd.conf
~ # chown openldap.openldap /etc/ldap/slapd.conf
		

Avant de redémarrer le service LDAP et le nouveau démon de réplication, nous allons profiter de leur arrêt et du fait que la base de données sous-jacente soit figée pour en faire une sauvegarde, que nous utiliserons pour initialiser le serveur esclave :

~ # cd /
/ # tar cjplf /root/ldap.tar.bz2 /etc/default/slapd 
          /etc/ldap/{slapd.conf,ldap.conf} 
         /etc/ldap/schema /var/lib/ldap/
tar: Retrait de « / » de tête des noms des membres
		

Dans la sauvegarde, incluez les fichiers de configuration que vous avez modifiés sur le serveur maître pour que l'esclave dispose de la même configuration, ainsi que des fichiers de description des schémas. Si, comme moi, vous en avez ajouté, ils seront aussi nécessaires sur le serveur esclave pour que ce dernier puisse enregistrer les informations venant du serveur maître.

Vous avez désormais fini l'ensemble des manipulations nécessitant un arrêt des démons sur le serveur maître. Vous pouvez donc le redémarrer pour qu'OpenLDAP prenne en compte le nouveau compte d'administration, ses droits d'accès et les directives de journalisation et de réplication :

~ # /etc/init.d/slapd start
Starting OpenLDAP: slapd.
		

Vous pouvez tester que le compte d'administration vous permette bien de vous connecter à l'annuaire et d'y effectuer des recherches et des modifications à l'aide d'un client tel que gq, par exemple.

Vous devez transférer la sauvegarde de la base de données et des fichiers de configuration sur le serveur esclave. Vous devez installer OpenLDAP sur le serveur esclave de la manière habituelle. La configuration importe peu car vous allez complètement la réinitialiser à l'aide des fichiers sauvegardés sur le serveur maître. En revanche, si votre procédure d'installation a démarré le service, vous devez arrêter le démon OpenLDAP :

~ # /etc/init.d/slapd stop
Stopping OpenLDAP: slapd.
		

Vous allez maintenant supprimer la base de donnée initialisée par la procédure d'installation sur le serveur esclace et restaurer tous les fichiers sauvegardés sur le serveur maître :

~ # rm -Rf /var/lib/ldap
~ # cd /
/ # tar xvjplf root/ldap.tar.bz2
etc/default/slapd
etc/ldap/slapd.conf
etc/ldap/ldap.conf
etc/ldap/schema/
etc/ldap/schema/core.ldif
etc/ldap/schema/openldap.ldif
etc/ldap/schema/corba.schema
etc/ldap/schema/core.schema
etc/ldap/schema/cosine.schema
etc/ldap/schema/dyngroup.schema
etc/ldap/schema/inetorgperson.schema
etc/ldap/schema/java.schema
etc/ldap/schema/misc.schema
etc/ldap/schema/nis.schema
etc/ldap/schema/openldap.schema
etc/ldap/schema/ppolicy.schema
etc/ldap/schema/authldap.schema
etc/ldap/schema/dnszone.schema
etc/ldap/schema/amavis.schema
etc/ldap/schema/README
var/lib/ldap/
var/lib/ldap/DB_CONFIG
var/lib/ldap/alock
var/lib/ldap/__db.001
var/lib/ldap/__db.002
var/lib/ldap/__db.003
var/lib/ldap/__db.004
var/lib/ldap/__db.005
var/lib/ldap/log.0000000001
var/lib/ldap/mail.bdb
var/lib/ldap/id2entry.bdb
var/lib/ldap/dn2id.bdb
var/lib/ldap/objectClass.bdb
var/lib/ldap/uid.bdb
var/lib/ldap/zoneName.bdb
var/lib/ldap/relativeDomainName.bdb
var/lib/ldap/cn.bdb
var/lib/ldap/uniqueMember.bdb
var/lib/ldap/ou.bdb
var/lib/ldap/virtualdomain.bdb
		

Ne redémarrez pas immédiatement le démon. En effet, vous venez de restaurer toute la configuration du serveur maître. Si vous démarriez le démon maintenant, vous auriez un second serveur LDAP maître. Il faut encore indiquer au démon esclave qu'il doit accepter les connexions et les mises à jour du démon slurpd s'exécutant sur le serveur maître. Etant donné que la configuration du serveur esclave est quasiment identique à celle du serveur maître, vous allez modifier le fichier de configuration du serveur pour le transformer en serveur esclave. Comme il pourrait être ammené à devenir serveur maître en cas de désastre, vous n'allez pas en supprimer les lignes spécifiques au serveur maître, mais uniquement les mettre en commentaire :

replica uri=ldap://serveur.esclave.societe.fr:389
	binddn="cn=admin,dc=societe,dc=fr"
	bindmethod=simple
	credentials=xxxxxxxx
replogfile /var/lib/ldap/replication.log
		

Ensuite, vous allez ajouter les lignes spécifiques au serveur esclave pour qu'il accepte les mises à jour venant du serveur maître :

updatedn "cn=admin,dc=societe,dc=fr"
updateref "ldap://serveur.maitre.societe.fr:389"
		

Comme les serveurs devront dialoguer entre eux, si vous utilisez un pare-feu filtrant (tel que NetFilter) entre les deux, vous devez penser à ouvrir les ports du pare-feu pour laisser passer le trafic entre ces deux serveurs. Le port à laisser passer est TCP/389 et la méthode d'ouverture dépend de l'outil que vous utilisez pour configurer votre pare-feu.

Maintenant, vous pouvez redémarrer le démon esclave pour qu'il accepte les connexions du démon slurpd et les mises à jour de l'annuaire.

Discussion

Le protocole de réplication utilisé n'est pas le même en fonction des outils employés. Il n'est donc pas possible de synchroniser des serveurs différents entre eux. La réplication est unidirectionnelle, il faut donc bien identifier le serveur maître sur lequel sont effectuées toutes les opérations en écriture et le serveur esclave sur lequel il n'est possible que de faire des requêtes en consultation. Il est possible de modifier le fichier de configuration du serveur esclave pour que l'annuaire n'y soit accessible qu'en consultation, en ajustant les ACL.

Le compte de réplication n'est pas indispensable, en théorie, sur le serveur maître. Mais, comme l'annuaire du maître est répliqué sur l'esclave et que ce compte est indispensable sur le serveur esclave, soit il faut créer le compte dans l'annuaire maître, soit il faut que le compte soit déclaré directement dans le fichier de configuration (ce que je déconseillais au début de cet article).

 de François Cerbelle

francois+db@cerbelle.net