I'm using the latest stable version: OpenLDAP 2.4.23 ( running on Ubuntu 10.10 ) I've also included the relevant configuration for my Provider and Consumer[s]. Consumer[s] # {1}hdb, config dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=test,dc=com olcAccess: {0}to attrs=userPassword by dn="cn=admin,dc=test,dc=com" write by an onymous auth by self write by group.exact="cn=DCNAS,o=Groups,dc=test,dc=com" w rite by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by dn="cn=admin,dc=test,dc=com" write by group.exact="cn=DCN AS,o=Groups,dc=test,dc=com" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=test,dc=com olcRootPW: test olcSyncrepl: {0}rid=001 provider=ldap://10.81.255.30 bindmethod=simple binddn= "cn=admin,dc=test,dc=com" credentials=test searchbase="dc=test,dc=com" logba se="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshOnly retry="60 +" interval=00:00:00:30 syncdata =accesslog olcUpdateRef: ldap://10.81.255.30 olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: cn eq olcDbIndex: memberOf eq olcDbIndex: entryUUID eq Provider: # {1}hdb, config dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=test,dc=com olcAccess: {0}to attrs=userPassword by dn="cn=admin,dc=test,dc=com" write by an onymous auth by self write by group.exact="cn=DCNAS,o=Groups,dc=test,dc=com" w rite by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by dn="cn=admin,dc=test,dc=com" write by group.exact="cn=DCN AS,o=Groups,dc=test,dc=com" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=test,dc=com olcRootPW: test olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: cn eq olcDbIndex: memberOf eq # {1}syncprov, {1}hdb, config dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpNoPresent: TRUE # {2}accesslog, {1}hdb, config dn: olcOverlay={2}accesslog,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {2}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE # {2}hdb, config dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=test,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # {0}syncprov, {2}hdb, config dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE -Yuri On Sun, Mar 13, 2011 at 11:47 AM, Quanah Gibson-Mount <quanah(a)zimbra.com > wrote: > --On Saturday, March 12, 2011 8:59 PM -0800 Yuri Bank <yuribank(a)gmail.com&gt; > wrote: > > >> I've found an interesting issue with delta-sync replication in which the >> > > > The first thing you should always provide is the version of OpenLDAP you > are using. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

Am Sun, 13 Mar 2011 17:39:17 -0700 schrieb Yuri Bank&lt;yuribank(a)gmail.com&gt;: > After doing more testing I have noticed that it is the 'Group member > modify entryCSNs' that seem to get ignored by the Provider, but > picked up by the Consumers. All other changes, adding or removing > users seems to update the ContextCSN on the Provider correctly. > > So a work around would be to make some kind of random change to an > entry in my DIT ( after making changes to group membership), so that > the Provider has the correct ContextCSN. A simple change like > modifying the description field for a user would accomplish this. I > would like to get to the bottom of this though, without such a work > around. > > Could this have anything to do with the memberOf overlay, which I am > using? It is more likely that the contextCSN of accesslog db is older than the last contextCSN provided by the provider.

Am Mon, 14 Mar 2011 02:43:53 -0700 schrieb Howard Chu&lt;hyc(a)symas.com&gt;: > Dieter Kluenter wrote: >> Am Sun, 13 Mar 2011 17:39:17 -0700 >> schrieb Yuri Bank&lt;yuribank(a)gmail.com&gt;: >> >>> After doing more testing I have noticed that it is the 'Group >>> member modify entryCSNs' that seem to get ignored by the Provider, >>> but picked up by the Consumers. All other changes, adding or >>> removing users seems to update the ContextCSN on the Provider >>> correctly. >>> >>> So a work around would be to make some kind of random change to an >>> entry in my DIT ( after making changes to group membership), so >>> that the Provider has the correct ContextCSN. A simple change like >>> modifying the description field for a user would accomplish this. I >>> would like to get to the bottom of this though, without such a work >>> around. >>> >>> Could this have anything to do with the memberOf overlay, which I >>> am using? >> >> It is more likely that the contextCSN of accesslog db is older than >> the last contextCSN provided by the provider. > > It's too unclear to make such an assumption. It's based on experience, my test environment shows the same results. A modify to one of the subordinate databases results in error 53 trying to sync the other subordinate database. Comparing contextCSN of all four databases showed that the client presents a CSN that is younger than that of access db, but I am still investigating

Dieter Kluenter wrote: > Am Sun, 13 Mar 2011 17:39:17 -0700 > schrieb Yuri Bank&lt;yuribank(a)gmail.com&gt;: > > After doing more testing I have noticed that it is the 'Group member >> modify entryCSNs' that seem to get ignored by the Provider, but >> picked up by the Consumers. All other changes, adding or removing >> users seems to update the ContextCSN on the Provider correctly. >> >> So a work around would be to make some kind of random change to an >> entry in my DIT ( after making changes to group membership), so that >> the Provider has the correct ContextCSN. A simple change like >> modifying the description field for a user would accomplish this. I >> would like to get to the bottom of this though, without such a work >> around. >> >> Could this have anything to do with the memberOf overlay, which I am >> using? >> > > It is more likely that the contextCSN of accesslog db is older than > the last contextCSN provided by the provider. > It's too unclear to make such an assumption. Best bet still is to switch to 2.4.24 and see if the problem remains. And yes, it's most likely related to the memberOf overlay. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/