Configuration du "Syncrepl" en utilisant OLC
Il n’y a pas de différence de configuration entre un mode de réplication "refreshOnly" et "refreshAndPersist" si ce n’est un paramètre (type) qui les identifie dans la configuration du consumer. Ainsi l’exemple de configuration qui va suivre peut très bien s’appliquer à ces deux modes.
1. Configuration du provider
À l’aide d’un navigateur LDAP, il faut tout d’abord se positionner dans le DIT de configuration (cn=config) du provider afin d’ajouter la fonctionnalité de réplication en créant la sous-entrée olcOverlay=syncprov dans la branche du DIT (identifiée par l’attribut olcDatabase) concernée.
Voici un exemple ci-dessous d’un fichier LDIF qui autorisera la réplication du DIT déclaré dans l’entrée olcDatabase={1}bdb,cn=config :
dn: olcOverlay=syncprov, olcDatabase={1}bdb,cn=config 
objectclass: olcSyncProvConfig 
olcOverlay: syncprov 
olcSpCheckpoint: 100 10
¬
Lorsque l’entrée olcOverlay est créée, elle possèdera (en supposant que c’est la première fonctionnalité ou overlay qui vient d’être ajoutée) le DN suivant : olcOverlay = {0} syncprov, olcDatabase = {1} bdb, cn = config. Un {0} a été attribué lorsque l’entrée a été ajoutée.
L’attribut, ou la directive olcCheckpoint (appelé point de contrôle) contrôle la gestion du cookie de synchronisation (contextCSN) utilisé pour maintenir le suivi des opérations de synchronisation qui ont été déjà réalisées précédemment. Ce cookie qui n’est ni plus ni moins qu’un horodatage, est mis à jour par le provider à la fin de chaque opération de réplication et transmis au consumer qui lui-même le (re)présentera au provider lors d’une nouvelle opération de synchronisation. Cependant, ce mode de fonctionnement ne permet pas de valider la mise à jour des entrées les unes à la suite des autres et s’expose au problème de retransmission des données en cas de coupure de la connexion ou de crash d’un des serveurs. Par exemple, imaginons un annuaire qui doit répliquer un millier d’entrées . La tâche est accomplie à 95 % lorsque survient une perte de connexion. Conséquemment, lors du rétablissement de la communication, la réplication devra repartir du début, car le cookie n’aura pas pu être mis à jour. La directive olcCheckpoint permet donc, non pas de résoudre, mais au moins de minimiser le volume de donnée à retransmettre, en forçant la transmission du cookie "context CSN" pendant les opérations de synchronisation et au lieu d’attendre la fin de la communication. Il se configure en spécifiant soit une transmission de ce cookie après "n" opération d’écriture réussies, soit après "x" minutes d’intervalle pendant les opérations d’écriture.
Dans l’exemple précédent, il est défini que le cookie sera transmis toutes les 100 écritures réussies ou toutes les 10 minutes.
2. Configuration du consumer
Côté consumer, il faudra ajouter l’attribut olcSyncrepl dans l’entrée olcDatabase contenant le DIT à répliquer.
Ainsi, si le DIT de réplication est défini par l’entrée olcDatabase = {1} bdb alors l’ajout de l’attribut olcSyncrepl par l’intermédiaire d’un fichier LDIF se présentera comme ci-dessous :
dn: olcDatabase={1},cn=config 
changetype: modify 
add:olcSyncrepl 
olcSyncrepl: {0}rid=000  
  provider=ldap://master-ldap.example.com 
# remplacer "type=refreshonly" si ce type est préféré 
  type=refreshAndPersist 
  retry="5 5 300 +"  
# Indiquer la base souhaitée 
  searchbase="dc=example,dc=com" 
# les attributs utilisateurs et opérationnels sont requis) 
  attrs="*,+" 
  bindmethod=simple 
  binddn="cn=root,dc=example,dc=com" 
# Attention le mot de passe est en clair 
  credentials=secret
¬
La valeur {0} sur la ligne olcSyncrepl: {0} rid = 000 n’est pas forcément nécessaire si c’est le premier attribut olcSyncrepl. En revanche si un nouvel attribut olcSyncrepl devait être ajouté, alors il faudra spécifier une valeur sans quoi l’entrée sera rejetée.