Surveiller la réplication
Afin de vérifier le bon fonctionnement de la réplication entre deux annuaires, il faudra surveiller le numéro de séquence de modification contenu dans le cookie de synchronisation (SyncCookie) mis à jour par le provider à la fin de chaque connexion de réplication. Ce numéro se trouve dans la valeur de l’attribut contextCSN de chaque entrée de l’annuaire répliqué.
Ainsi, la méthode de surveillance de la réplication consistera, dans une architecture de réplication "Peer-to-Peer", à consulter les valeurs de l’attribut contextCSN sur chacun des annuaires. L’exemple de la figure 16-1 illustre un cas où la réplication fonctionne correctement, car les valeurs sont identiques pour les deux annuaires.
[root@ldap01 ~]# ldapsearch -h ldap01 -D  
"cn=root,dc=exemple,dc=com" -W -b "dc=exemple,dc=com" -s base 
’contextCSN’ -LLL ; ldapsearch -h ldap02 -D  
"cn=root,dc=exemple,dc=com" -W -b "dc=exemple,dc=com" -s base 
’contextCSN’ -LLL 
 
Enter LDAP Password:  
dn: dc=exemple,dc=com 
contextCSN: 20160810133053.733199Z#000000#001#000000 
contextCSN: 20160810133115.876608Z#000000#002#000000 
 
Enter LDAP Password:  
dn: dc=exemple,dc=com 
contextCSN: 20160810133053.733199Z#000000#001#000000 
contextCSN: 20160810133115.876608Z#000000#002#000000
Figure 16-1 : Commande de surveillance de la réplication
¬
Il y a deux valeurs pour l’attribut contextCSN, car il s’agit d’une réplication "Peer-to-Peer" ou encore appelé "miroir" qui est en fait la configuration de deux réplications provider/consumer.
Dans le cas contraire, cela signifierait qu’il y a un problème de réplication. Si une seule de ces valeurs est différente, il faudra chercher de quel sens de réplication il s’agit. Dans l’exemple ci-dessous, il apparaît un décalage de valeurs entre les attributs ContextCSN des deux serveurs LDAP qui correspond à un peu plus de trois jours :
(ldap01) 
Enter LDAP Password:  
dn: dc=exemple,dc=com 
contextCSN: 20160810133053.733199Z#000000#001#000000 
contextCSN: 20160810133115.876608Z#000000#002#000000 
(ldap02) 
Enter LDAP Password:  
dn: dc=exemple,dc=com 
contextCSN: 20160810133053.733199Z#000000#001#000000 
contextCSN: 20160813163115.876608Z#000000#002#000000
Cela signifie que le serveur "ldap02" a effectué des mises à jour de son annuaire et que celles-ci n’ont pas été répercutées sur le serveur "ldap01".
Ainsi, pour forcer la réplication, il faudra redémarrer le serveur possédant l’annuaire obsolète ’ldap01’ avec la valeur contextCSN du serveur "ldap02".
Exemple
/usr/sbin/slapd -c 
rid=002,csn=20160813163115.876608Z#000000#002#000000
¬
Il est également possible de lancer une réplication totale en mettant csn=0.
La méthode précédente est à employer de façon ponctuelle sous forme de script ou bien via un agent de surveillance afin de l’automatiser à intervalle de temps régulier.
Par ailleurs, certains agents de surveillance de type Nagios implémentent une méthode de création d’une entrée sur un annuaire et vérifient leur bonne réplication sur le second. Puis ils effacent cette même entrée sur le second annuaire et contrôlent que l’entrée a bien été supprimée. Cette méthode, bien que simple, est véritablement efficace pour s’assurer que la réplication fonctionne parfaitement.