La mise en place d'une réplication de type miroir entre deux annuaires OpenLDAP est assez simple.
Une fois la mise en place effectuée, il s'agit de vérifier que la réplication se fait de manière satisfaisante. Car parfois, en cas de charge élevée sur l'un des annuaires, certaines transactions peuvent ne pas être propagées. Il est alors intéressant de savoir si les instances d'annuaires sont bien synchronisées, et comment les remettre d'aplomb si ce n'est pas le cas.
De même, en cas de coupure de communication entre les serveurs, on peut arriver à un décalage, qu'il faut pouvoir identifier.
Afficher les informations dans les logs
Par défaut, OpenLDAP est en niveau de log "Stats" (cf. http://www.openldap.org/doc/admin24/slapdconf2.html, § 5.2.1.2. olcLogLevel).
Les informations concernant la réplication n'apparaissent pas dans ces logs.
Une première possibilité est de modifier le niveau de logs, en ajoutant le niveau Sync. http://blog.suretecsystems.com/archives/163-OpenLDAP-Quick-Tips-Change-…
ldapsearch -x -b "cn=config" -D 'cn=admin,cn=config' -LLL -W olcLogLevel -s base Enter LDAP Password: dn: cn=config olcLogLevel: Stats
Pour ajouter un niveau de log, en passant par un LDIF :
cat addloglevel.ldif dn: cn=config changetype: modify add: olcLogLevel olcLogLevel: Sync
puis
ldapmodify -x -D 'cn=admin,cn=config' -W -f addloglevel.ldif
Pour enlever le niveau de log "Sync" :
cat delloglevel.ldif dn: cn=config changetype: modify delete: olcLogLevel olcLogLevel: Sync ldapmodify -x -D 'cn=admin,cn=config' -W -f delloglevel.ldif
Vérification des niveaux de réplication via LDAP
On peut aussi vérifier la réplication à partir des attributs ContextCSN de chaque instance d'annuaire, via une requête LDAP, sur la base du Root Suffix. En récupérant l'attribut ContextCSN, on peut avoir le timestamp de la dernière entrée modifiée sur chaque réplica.
Pour vérifier la réplication, on peut lancer le script shell :
#!/bin/bash account="cn=replicator,dc=example,dc=corp" credentials=MonSuperM0tDePasse ROOTSUFFIX="dc=example,dc=corp" echo "Sur le host principal (ldap1.example.com)" ldapsearch -x -LLL -s base -b $ROOTSUFFIX -D $account -w $credentials -h ldap1.example.com contextcsn echo "Sur le host secondaire (ldap2.example.com)" ldapsearch -x -LLL -s base -b $ROOTSUFFIX -D $account -w $credentials -h ldap2.example.com contextcsn
Résultat :
Sur le host principal (ldap1.example.com) dn: dc=example,dc=corp contextCSN: 20150204161826.092502Z#000000#001#000000 contextCSN: 20150202110352.797420Z#000000#002#000000 Sur le host secondaire (ldap2.example.com) dn: dc=example,dc=corp contextCSN: 20150204161826.092502Z#000000#001#000000 contextCSN: 20150204024957.794551Z#000000#002#000000
On constate que sur les CSN du replicat 002 sont décalés : sur le serveur secondaire (réplicat 002), la dernière modification a été faite le 04/02/2015, alors que sur le serveur primaire, ses mises à jour correspondant au réplicat 002 datent du 02/02/2015, soit 2 jours de décalage.
Ceci signifie que certains modifications effectuées sur le serveur secondaire n'ont pas été synchronisées vers le serveur primaire
Forcer la réplication
Pour remettre la réplication au carré, on peut redémarrer l'annuaire en retard (dans notre exemple, le 10.0.3.225) avec une option spécifique de slapd.
Cette option -c (cookie) prend plusieurs paramètres :
# A lancer sur le serveur correspondant au RID 001 slapd -c rid=002,csn=20150202110000.000000Z#000000#002#000000
ou si on veut forcer une réplication globale ; slapd -c rid=002,csn=0
Le RID de l'annuaire peut être récupéré en regardant dans le le fichier /etc/openldap/slapd.d/cn=config.ldif la valeur de l'attribut ContextCSN :
entryCSN: 20140930125102.400075Z#000000#002#000000 => L'annuaire a le RID 002
Et a contrario on peut avoir le RID de l'annuaire distant en regardant dans les fichiers de définition des databases. Par exemple, sur l'instance 2 (annuaire secondaire), on a :
olcSyncrepl: {0}rid=1 provider=ldap://ldap1.example.com binddn
="cn=replicator,dc=example,dc=corp" credentials=Replicat0r_ attrs="*,
+" bindmethod=simple searchbase="dc=example,dc=corp" type=refreshAndPersist r
etry="60 +"
Cette instance de l'annuaire va donc échanger avec le RID 001, qui se trouve être le serveur ldap1.example.com