synchronisation monitoring, contextCSN and operational attributes

[Guillaume Rousse <Guillaume.Rousse@inria.fr>]

Hello list.

I'm using delta-syncrepl in search-and-persist mode between my slaves 
and my master server. And I'm using a nagios plugin to check sync 
status, based on value of contextCSN attribute. But I'm often sync 
alerts for unknown reasons.

First issue, is this an expected result to have an higher contextCSN on 
the slave side ? From what I've understood from contextCSN, this 
attribute is updated each time a write operation is performed on the 
server. As the slave server is not supposed not to perform any write 
operation, this should never happens. However, it does:

[root@etoile ~]# /usr/share/nagios/plugins/check_syncrepl.py 
ldap://ldap1.msr-inria.inria.fr ldap://ldap2.msr-inria.inria.fr -b 
dc=msr-inria,dc=inria,dc=fr -v
[..]
2009-05-25 13:36:49,740 - check_syncrepl.py - DEBUG - Retrieving 
Provider contextCSN
2009-05-25 13:36:49,741 - check_syncrepl.py - DEBUG - contextCSN = 
20090520141922.274229Z#000000#000#000000
2009-05-25 13:36:49,742 - check_syncrepl.py - DEBUG - Retrieving 
Consumer contextCSN
2009-05-25 13:36:49,742 - check_syncrepl.py - DEBUG - contextCSN = 
20090525095027.118111Z#000000#000#000000
2009-05-25 13:36:49,752 - check_syncrepl.py - INFO -   Consumer NOT in SYNCH
2009-05-25 13:36:49,753 - check_syncrepl.py - INFO -   Delta is -5 days, 
4:28:55

Second issue, how does syncrepl sync operational attributes ? When using 
ppolicy, for instance, each failed bind operation result in a 
pwdChangedTime attribute added to the user entry. From my own attempts, 
the slave and the master maintain their own list separatly.

As synchronisation is performed from master to slave only, it seems 
quite logical failed authentication on the slaves doesn't impact the 
user entry on the master. However, from reading slapd.conf man page, 
syncrepl is supposed to synchronise operational attributes too by default:
 The attrs list defaults to "*,+" to return all user and operational 
attributes, and attrsonly  is unset  by  default.

Also, the logs on the slave clearly show something happens when a failed 
autentication is performed on the master.

Start state:
Provider contextCSN = 20090525122053.257812Z#000000#000#000000
Consumer contextCSN = 20090525122053.257812Z#000000#000#000000

Logs:
May 25 14:18:34 nation slapd[28717]: do_syncrep2: 
cookie=rid=123,csn=20090525121834.036489Z#000000#000#000000
May 25 14:18:34 nation slapd[28717]: slap_queue_csn: queing 0x93d55d8 
20090525121834.036489Z#000000#000#000000
May 25 14:18:34 nation slapd[28717]: slap_graduate_commit_csn: removing 
0x9450550 20090525121834.036489Z#000000#000#000000
May 25 14:18:34 nation slapd[28717]: syncrepl_message_to_op: rid=123 
be_modify uid=rousse,ou=users,dc=msr-inria,dc=inria,dc=fr (0)
May 25 14:18:34 nation slapd[28717]: slap_queue_csn: queing 0x9461d18 
20090525121834.036489Z#000000#000#000000
May 25 14:18:34 nation slapd[28717]: slap_graduate_commit_csn: removing 
0x945e640 20090525121834.036489Z#000000#000#000000

End state
Provider contextCSN = 20090525122053.257812Z#000000#000#000000
Consumer contextCSN = 20090525122122.287486Z#000000#000#000000

The provider didn't increases its contextCSN value, while performing a 
change, and the consumer did increase its own, while not performing the 
change :(

Here is my syncrepl configuration:
syncrepl rid=123
    provider=ldaps://ldap1.msr-inria.inria.fr
    type=refreshAndPersist
    retry="60 +"
    logbase="cn=log"
    logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
    syncdata=accesslog
    searchbase="dc=msr-inria,dc=inria,dc=fr"
    scope=sub
    schemachecking=off
    bindmethod=simple
    binddn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr"
    credentials=XXXXXX

--
Guillaume Rousse
Service des Moyens Informatiques
INRIA Saclay - Île-de-France
Parc Orsay Université, 4 rue J. Monod
91893 Orsay Cedex France
Tel: 01 69 35 69 62