Réplication LDAP via `slurpd`

Pour monter un serveur LDAP répliqué, commencez d'abord par monter un second serveur LDAP similaire au premier.

La configuration spécifique à la réplication est relativement simple : il faut spécifier au maître de faire rejouer les transactions sur le ou les esclaves, et il faut que le serveur esclave redirige les clients voulant faire des modifications vers le serveur maître, lui seul ayant la possibilité de recevoir des écritures.

Dans ce cas, un client sera bien déconnecté du serveur sur lequel il était pour aller interroger et renseigner le serveur maître. Ce n'est en fait pas le client qui le fait, mais la bibliothèque LDAP qui s'en charge pour lui.

Je partirai du principe que le serveur maître est ldap1.example.com, le serveur esclave ldap2.example.com. N'oubliez pas de générer un certificat avec le bon nom de serveur (Common Name dans la description du certificat), dérivant de la même autorité de certification (pour simplifier les choses).

La réplication n'est pas très difficile, voire plutôt très simple à mettre en œuvre, pourvu que l'on ait la bonne information au départ. Alors je l'écris en gras : une configuration de réplication s'applique à une base de données LDAP et non à un annuaire. Ça va mieux en le disant, d'autant que je n'ai trouvé cette information qu'après une lecture assidue des lidies (listes de distribution) sur gmane.org (pub !). En effet, un annuaire OpenLDAP peut gérer plusieurs bases, avec plusieurs suffixes différents. Or il est tout à fait possible de vouloir répliquer une base et pas une autre. Ce point de détail bloquant m'a valu une certaine perte de temps avant de comprendre que je ne pouvais pas mettre la configuration de réplication où je voulais dans /etc/openldap/slapd.conf.

C'est pourtant explicitement dit dans la page de manuel de slapd.conf(5) : Specify a replication site for this database, mais que voulez-vous... Une directive de réplication se met donc dans la section de description database afférente.

Principe

Le serveur qui doit répliquer sa base de données sur un autre serveur met à disposition les modifications de ces données dans un fichier, sous une forme proche de LDIF. C'est le journal des modifications.

Ce fichier est lu ensuite par un processus frère, slurpd, qui est démarré en même temps que slapd quand on veut faire de la réplication. Son boulot est de vérifier le journal que lui passe slapd, et de faire passer les modifications sur les tous les serveurs configurés. Les modifications sont communiquées par slurpd aux autres slapd par le protocole que vous utilisez, LDAP. Il va sans dire qu'il faudra donc spécifier l'utilisateur qu'utilisera slurpd pour se connecter sur les esclaves. Cet utilisateur, que nous nommerons le réplicateur et qu'il nous faudra définir d'abord dans l'annuaire maître, sera le seul avoir le droit en écriture sur les serveurs esclaves.

Pour éviter les modifications par tout autre que le réplicateur sur les serveurs esclaves, nous allons utiliser une particularité de LDAPv3 : l'utilisation des renvois (Referrals). Ces renvois, notifiés de façon transparente au client, feront que ce client LDAP se connectera de manière tout aussi transparente au serveur spécifié dans le renvoi afin de mener à bien les modifications demandées. Tous les clients actuels (basés sur les bibliothèques clientes OpenLDAP) supportent ainsi LDAPv3, et donc les renvois.

Mise en œuvre

On modifie la configuration des serveurs maître et esclave de la façon suivante :

Maître

On ajoute à la suite de la définition de la base de données (database) les lignes :

  replica host=ldap2.example.com:389
        tls=yes
        bindmethod=simple
        binddn="cn=Replicator,dc=example,dc=com"
        credentials=ksdhjdlk

On a donc défini un serveur ldap2, accessible via TLS, s'authentifiant via un mot de passe (et non via SASL) avec le compte cn=Replicator,dc=example,dc=com et le mot de passe : ksdhjdlk.

N'oubliez pas d'insérer la définition LDIF du compte réplicateur dans l'annuaire :

  dn: cn=Replicator, dc=example,dc=com
  userPassword: {MD5}wTLNbidzOxJH8bbfhDL83A==
  objectClass: person
  objectClass: top
  sn: Replicator
  cn: Replicator

On notera que le réplicateur est défini à la racine du DIT (« Directory Information Tree », arbre contenant les données de l'annuaire). Cela évitera par la suite de le confondre avec un compte utilisateur.

Ce compte sera donc défini tant dans l'annuaire maître que dans l'annuaire esclave, car les deux sont identiques. On peut cependant imaginer avoir une base de données spécifique au serveur esclave, avec un autre suffixe. Mais pour un simple compte de réplication, cela en vaut-il la peine ?

Esclave (serveur ldap2)

De même que pour la base de données à répliquer de l'annuaire maître, on ajoute les lignes suivantes à la suite de la définition de la base de données répliquée sur le serveur esclave :

  updateref       ldap://ldap1.example.com:389/
  updatedn        "cn=Replicator,dc=example,dc=com"

La première ligne permet le renvoi vers l'annuaire maître pour les écritures, et spécifie le DN du réplicateur. Ajoutez et/ou modifiez les ACL par ce qui suit, pour autoriser le réplicateur à écrire dans l'annuaire répliqué :

  access to attr=userPassword
    by self write
    by anonymous auth
    by dn="cn=Replicator,dc=example,dc=com" write
    by * none

  access to *
    by dn="uid=Replicator,dc=example,dc=com" write
    by * read

Encore une fois, les lignes updateref et updatedn sont spécifiques à une database (me répété-je ?).

Synchronisation des annuaires

Pour la synchronisation, il vaut mieux placer l'annuaire en lecture seule le temps de récupérer son contenu, même si dans les versions récentes, avec Berkeley DB, il est possible de lancer la commande slapcat en étant assuré d'avoir un vidage cohérent du contenu de l'annuaire.

De plus, le fait de placer l'annuaire maître en lecture seule le temps de la réplication permet de s'assurer de l'absence de modification sur le maître pendant que le contenu est transféré du maître à l'esclave. Le retour en mode normal, autorisant des modifications sur l'annuaire maître, ne doit se faire qu'après le redémarrage de l'esclave, qui contiendra à ce moment-là exactement les données du maître.

Pour ce faire, nous allons rajouter une clause include au fichier de configuration de l'annuaire maître pour la base de données à répliquer. Cette clause pointera sur un fichier, situé à côté de slapd.conf, dans lequel nous pourrons spécifier readonly on ou readonly off. Cela nous permettra de passer la base dans un mode ou l'autre beaucoup plus facilement (et rapidement) qu'avec un appel à perl (du style perl -pi -e 's/readonly on/readonly off/g' /etc/openldap/slapd.conf), qui devra même être plus compliqué que ça dans le cas d'un annuaire avec plusieurs bases.

La ligne à ajouter dans slapd.conf, après la définition de la base dc=example,dc=com :

  include /etc/openldap/readonly-example.com.conf

Le script pour lancer la réplication sera donc :

  #!/bin/bash
  # Réplication d'annuaire OpenLDAP par dump ou par copie des bases
  #
  BACKUPDIR=/var/lib/ldap/backup
  BASE=example.com
  BASESUFFIX="dc=example,dc=com"
  REPL=base
  #REPL=dump
  #
  mkdir -p $BACKUPDIR
  chown root:root $BACKUPDIR
  chmod 700 $BACKUPDIR
  #
  echo "readonly on" > /etc/openldap/readonly-${BASE}.conf
  service ldap restart
  #
  slapcat -b "$BASESUFFIX" > $BACKUPDIR/slapcat.dump
  rc=$?
  if [ $rc -ne 0 ] ; then
    echo "Le dump de la base $BASESUFFIX a échoué"
    echo "Réplication impossible"
    exit 1
  fi
  #
  # Arret LDAP distant
  ssh ldap2.example.com "/etc/init.d/ldap stop"
  if [ "$REPL" == "base" ] ; then 
    scp $BACKUPDIR/slapcat.dump ldap2.example.com:$BACKUPDIR/slapcat.dump
    scp /var/lib/ldap/*.dbb ldap2.example.com:/var/lib/ldap
    ssh ldap2.example.com "chown ldap:ldap /var/lib/ldap/*.dbb"
  else
    cmd="/etc/init.d/ldap stop"
    cmd="$cmd ; rm -f /var/lib/ldap/*"
    cmd="$cmd ; su - ldap -c slapadd -c -l $BACKUPDIR/slapcat.dump"
    ssh ldap2.example.com "$cmd"
  fi
  ssh ldap2.example.com "/etc/init.d/ldap start"
  echo "readonly off" > /etc/openldap/readonly-${BASE}.conf
  service ldap restart

Ce script suppose que vous ayez soit une clé pour le compte root de ldap1 autorisée sur ldap2, soit que vous ayez « l'agent forwarding » pour votre clé personnelle activé (et votre clé autorisée sur le compte root de vos deux serveurs), soit que vous soyez prêt à taper un certain nombre de fois le mot de passe root de ldap2.

Ce script ne teste pas tous les cas de figures où peuvent survenir des problèmes, en particulier en cas d'erreur au cours du transfert des données. À ce titre, ne le lancez que manuellement et surveillez son déroulement. Sinon, modifiez-le afin de vérifier tous les codes retour de toutes les commandes et n'avancez dans le déroulement du script que si tout se passe bien. N'oubliez pas d'envoyer des avertissements pour vérifier à votre arrivée le matin le bon déroulement des transferts de nuit en automatique.

Fonctionnalités avancées de OpenLDAP

Chapeau de l'article

Écrire son propre schéma

Préalable à l'écriture du schéma

Écriture du schéma

Problème possible

Configuration de la partie SSL/TLS

Création de l'autorité de certification

Création d'un certificat

Signature du certificat par la CA pour certification

Configuration dans OpenLDAP

Vérification du bon fonctionnement

Réplication LDAP via `slurpd`

Principe

Mise en œuvre

Maître

Esclave (serveur ldap2)

Synchronisation des annuaires

Liens

Les sites web

La prochaine fois...

Les listes de diffusions

Jérôme Fenal

Fonctionnalités avancées de OpenLDAP

Chapeau de l'article

Écrire son propre schéma

Préalable à l'écriture du schéma

Écriture du schéma

Problème possible

Configuration de la partie SSL/TLS

Création de l'autorité de certification

Création d'un certificat

Signature du certificat par la CA pour certification

Configuration dans OpenLDAP

Vérification du bon fonctionnement

Réplication LDAP via slurpd

Principe

Mise en œuvre

Maître

Esclave (serveur ldap2)

Synchronisation des annuaires

Liens

Les sites web

La prochaine fois...

Les listes de diffusions

Jérôme Fenal

Réplication LDAP via `slurpd`