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.