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@zimbra.comwrote:
--On Saturday, March 12, 2011 8:59 PM -0800 Yuri Bank yuribank@gmail.com 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
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?
On Sun, Mar 13, 2011 at 2:50 PM, Yuri Bank yuribank@gmail.com wrote:
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@zimbra.com
wrote:
--On Saturday, March 12, 2011 8:59 PM -0800 Yuri Bank yuribank@gmail.com 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 yuribank@gmail.com:
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.
-Dieter
Dieter Kluenter wrote:
Am Sun, 13 Mar 2011 17:39:17 -0700 schrieb Yuri Bankyuribank@gmail.com:
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.
Am Mon, 14 Mar 2011 02:43:53 -0700 schrieb Howard Chu hyc@symas.com:
Dieter Kluenter wrote:
Am Sun, 13 Mar 2011 17:39:17 -0700 schrieb Yuri Bankyuribank@gmail.com:
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
Dieter Kluenter wrote:
Am Mon, 14 Mar 2011 02:43:53 -0700 schrieb Howard Chuhyc@symas.com:
Dieter Kluenter wrote:
Am Sun, 13 Mar 2011 17:39:17 -0700 schrieb Yuri Bankyuribank@gmail.com:
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
The original poster has no subordinate databases. Whatever behavior you're experiencing is totally unrelated, and you're making unfounded assumptions that there is any relevance between your situation and his.
Am Mon, 14 Mar 2011 04:53:21 -0700 schrieb Howard Chu hyc@symas.com:
Dieter Kluenter wrote:
Am Mon, 14 Mar 2011 02:43:53 -0700 schrieb Howard Chuhyc@symas.com:
Dieter Kluenter wrote:
Am Sun, 13 Mar 2011 17:39:17 -0700 schrieb Yuri Bankyuribank@gmail.com:
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
The original poster has no subordinate databases. Whatever behavior you're experiencing is totally unrelated, and you're making unfounded assumptions that there is any relevance between your situation and his.
But also more than one consumer.
-Dieter
I just tested my configuration & db with version 2.4.24, and I am seeing the exacat same problem.
-Yuri
On Mon, Mar 14, 2011 at 2:43 AM, Howard Chu hyc@symas.com wrote:
Dieter Kluenter wrote:
Am Sun, 13 Mar 2011 17:39:17 -0700 schrieb Yuri Bankyuribank@gmail.com:
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/
--On March 14, 2011 7:51:23 PM -0700 Yuri Bank yuribank@gmail.com wrote:
I just tested my configuration & db with version 2.4.24, and I am seeing the exacat same problem.
Please file an ITS:
--Quanah
openldap-technical@openldap.org
-
Dieter Kluenter -
Howard Chu -
Quanah Gibson-Mount -
Yuri Bank