GuiGui's Show

Soit une architecture LDAP reposant sur la version 2.4.44 de slapd (l'implémentation d'un serveur LDAP du projet de référence OpenLDAP). Nous avons un serveur pour l'écriture, et un autre pour la lecture.

Nous activons la réplication entre les deux. Source : le serveur d'écriture. Destination : le serveur de lecture. Point terminologie : désormais un master se nomme un producer et un slave se nomme un consumer. On passe donc d'une terminologie esclavagiste à une terminologie consumériste.

Pour superviser cette réplication, nous souhaitons utiliser le script check_syncrepl_extended qui compare les attributs « contextCSN » (une sorte de numéro de version d'une base de données LDAP) et les « entryCSN » (une sorte de numéro de version d'un objet au sein d'une BDD LDAP).

Nous importons une copie de la base de données depuis un serveur Debian 3.1 + OpenLDAP 2.2. Cette copie a été réalisée avec la commande slapcat -l copie_base_ldap.ldif. L'importation est réalisée en exécutant la commande slapadd -l copie_base_ldap.ldif sur notre producer.

On vérifie ensuite que la réplication a bien copié nos objets LDAP sur le consumer à l'aide du script présenté ci-dessus. Il nous informe que tous nos objets sont en erreur…

Si l'on active le mode debug avec le paramètre -d, on constate qu'un message d'erreur est affiché pour chacun de nos objets LDAP :

2019-01-07 17:01:55,947 - DEBUG : Found on ldap://producer.exemple:389 : uid=lala,ou=people,dc=monorganisation,dc=fr / 20181009070723Z#000029#00#000000
2019-01-07 17:02:00,547 - DEBUG : Found on ldap://consumer.exemple:389 : uid=lala,ou=people,dc=monorganisation,dc=fr / 20181009070723.000000Z#000029#000#000000
2019-01-07 17:02:05,441 - DEBUG : Check obj uid=lala,ou=people,dc=monorganisation,dc=fr
2019-01-07 17:02:05,441 - DEBUG : Obj uid=lala,ou=people,dc=monorganisation,dc=fr not synchronized : 20181009070723Z#000029#00#000000 <-> 20181009070723.000000Z#000029#000#000000

On constate que l'estampille temporelle stockée dans l'attribut « entryCSN » de chaque objet est codée différemment : sur le producer, on a une date+heure en seconde alors que l'on a une date+heure en microseconde sur le consumer. De même, le troisième champ de l'attribut a un nombre de zéro différent. On constate que le slapadd a repris tel quel le format présent dans la copie alors que la réplication a changé ce format.

Solution : j'ai désactivé la réplication du côté du consumer, j'ai supprimé la base de donnée (rm /var/lib/ldap/*), j'ai effectué un slapadd sur les deux serveurs puis j'ai réactivé la réplication.

J'ai testé la réplication : la modification, avec un ldapvi ou un ldapmodify, de tout objet sur le producer entraîne un changement de son entryCSN. Le tout est répliqué sur le consumer. Les deux entryCSN concordent donc nous pouvons utiliser un script de supervision qui s'appuie dessus.

Je retiens donc une différence de comportement entre un slapadd et une réplication.