[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#6864) delta-sync - contextCSN not updating on provider

Full_Name: Yuri Bank
Version: 2.4.23-24
OS: Linux Ubuntu 10.10
URL: http://yuri.easytospell.net/consumer.provider.txt
Submission from: (NULL) (

This issue exists in both versions 2.4.23 and 2.4.24

I've found an interesting problem with delta-sync replication in which the
ContextCSN on my consumers is higher than the contextCSN on my provider. This is
because the Provider does not properly update its contextCSN for its base suffix
(dc=test,dc=com) when changes are made to group membership. Of couse, if it so
happens that the last change in my database was not a group membership change,
then the contextCSNs will be consistent between my consumers and provider.

I use the following command to check the ContextCSN on each consumer:
Consumer: 1
root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b
"dc=test,dc=com" contextCSN dn: dc=test,dc=com
dn: dc=test,dc=com
contextCSN: 20110313041653.752098Z#000000#000#000000
Consumer: 2
ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b
"dc=test,dc=com" contextCSN dn: dc=test,dc=com
dn: dc=test,dc=com
contextCSN: 20110313041653.752098Z#000000#000#000000
So we can see that the two consumers have matching contextCSNs: 
ContextCSN. 20110313041653.752098Z#000000#000#000000
Lets check the Provider now.
root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b
"dc=test,dc=com" ContextCSN dn: dc=test,dc=com 
dn: dc=test,dc=com
contextCSN: 20110313041653.709140Z#000000#000#000000

The providers CSN is smaller!?
Lets take a closer look and search cn=accesslog
These are the last two entries: ( first the user was added, and then the user
was added to a group)
# 20110313041653.000003Z, accesslog
dn: reqStart=20110313041653.000003Z,cn=accesslog
objectClass: auditAdd
reqStart: 20110313041653.000003Z
reqEnd: 20110313041653.000004Z
reqType: add
reqSession: 34633
reqAuthzID: cn=admin,dc=test,dc=com
reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com
reqResult: 0
reqMod: sn:+ Bank
reqMod: userPassword:+ {SASL}banky
reqMod: uid:+ banky
reqMod: objectClass:+ top
reqMod: objectClass:+ person
reqMod: objectClass:+ shadowAccount
reqMod: structuralObjectClass:+ person
reqMod: cn:+ Bank, Yuri(banky)
reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5
reqMod: creatorsName:+ cn=admin,dc=test,dc=com
reqMod: createTimestamp:+ 20110313041653Z
reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000
reqMod: modifiersName:+ cn=admin,dc=test,dc=com
reqMod: modifyTimestamp:+ 20110313041653Z
# 20110313041653.000006Z, accesslog
dn: reqStart=20110313041653.000006Z,cn=accesslog
objectClass: auditModify
reqStart: 20110313041653.000006Z
reqEnd: 20110313041653.000007Z
reqType: modify
reqSession: 34633
reqAuthzID: cn=admin,dc=test,dc=com
reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com
reqResult: 0
reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com
reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000
reqMod: modifiersName:= cn=admin,dc=test,dc=com
reqMod: modifyTimestamp:= 20110313041653Z

You can see that the consumers have the latest entryCSN (20110313041653.752098Z)
as their contextCSN, but the provider has the entryCSN (20110313041653.709140Z)
before that as its contextCSN:

If I search the contextCSN on -s base -b cn=accesslog it yields correctly, the
same result as the consumers:
As you can see, the provider is not using the latest entryCSN as its ContextCSN,
where as the consumer nodes are. Also notice that the last modification was to
group membership. This problem only seems to exist when Adding/Removing users
from a group. 

A side effect of this issue causes brand new consumers to get stuck in an
infinite loop while syncing for the first time. 

A work around is to make a random change to a User/Person, such as injecting a
random number into their description field AFTER making a change to a group
membership. Such a change will:  A. cause the Provider to correctly update its
contextCSN, B. provider and all consumer[s] will have the same contextCSN C.
brand new consumers can be added without getting stuck in an infinite loop when
syncing the database. ( they seem to get stuck on the last entry which makes
sense if the last entry has a higher entryCSN than that of the Providers
contextCSN? )

Confgiuration: ( See URL )


Please feel free to email me about reproducing this problem. I have a lab with
various configurations and would be happy to give access to anyone interested.

- Yuri Bank