Problème de synchronisation LDAP

Pour éviter à d’autres de chercher, voici comment résoudre un problème de synchronisation SLAPD entre un LDAP master et ses slaves. Dans mon cas mon master était un Debian Lenny et j’avais 2 slaves en Lenny et tous mes autres slave en Wheezy. Des ajouts de machines ou d’utilisateurs étaient répliqués sur les Lenny mais pas sur les Wheezy.

Utilisez le bon loglevel

Dans mon cas, c’est ldapsync qui ne fonctionnait pas correctement, il faut donc mettre :

loglevel        16384

Attention que les niveau de logs peuvent d’additionner pour afficher plusieurs catégories de logs en même temps, pour avoir le 16384 et le 2, on notera 16386 par exemple. Voir la page man pour les différents logs.

Solution du problème de synchronisation SLAPD

Ma première solution a été de forcer une réplication. Pour cela il faut éteindre slapd sur un slave et supprimer le contenu de /var/lib/ldap/. Je vous conseille de faire un tgz avant juste au cas 😉 Mais tous les éléments du ldap n’était pas répliqué. Pour vérifier  rapidement, on peut compter les lignes et comparer la dernière entrée :

slapcat | wc -l

slapcat | tail -n 30

Après avoir cherché dans les logs /var/log/debug, j’ai remarqué ceci :

do_syncrepl: rid=173 rc -1 retrying (9 retries left)

Et plus loin ceci est retenté avec un nouveau code :

do_syncrepl: rid=173 rc 21 retrying (7 retries left)

Un élément bloque la synchronisation, il a fallut chercher lequel.

En s’attardant sur les logs, on peut y voir ceci :

slapd[22822]: syncrepl_message_to_entry: rid=173 DN: uid=user1,ou=namedAccount,o=test, UUID: 8a477882-f0e3-102d-9ca7-3b8502e11a
15

slapd[22822]: syncrepl_message_to_entry: rid=173 mods check (postalAddress: value #0 invalid per syntax)

Cela vient du faite que dans certains champs « postalAddress » du LDAP, un caractère non autorisé est apparu, il s’agit du backslash « \ ». Cela est apparu lorsque quelqu’un à faire un import de données MySQL sans vérifier cela.

Le fait que mes serveurs LDAP slave en Lenny n’aient pas eu de souci avec ce caractère vient des schémas utilisés. Ce sont des machines Lenny comme mon LDAP master, alors que les autres sont des Wheezy. Les schémas ont changés entre ces 2 versions…

TODO

Pour que ce problème ne se repose plus à l’avenir il faut :
– soit faire attention aux champs entrés qui ne doivent pas contenir ce \
– soit analyser les schémas de part et d’autres et modifier ceux des slaves en conséquence, mais cela peut prendre du temps.

Articles relatifs :