Hi Guys
debian stable
openldap 2.4.23-7.2
I have multiple consumers with a single provider, when making changes too the provider ie creating a new user, sometimes the change doesnt propagate too all the consumers some have the correct entries and some dont. If I then compare the contextcsn on both the provider and the consumer it is identical on the consumers with the missing entry. The only way I can then resync is by shutting down openldap on the consumer deleting the tree and restarting which then syncs the directory with the missing entry.
How would I go about troubleshooting this issue? Or am I missing something simple? Any help would be appreciated.
On Wed, 25 Apr 2012, Mark Coetser wrote: [...]
I have multiple consumers with a single provider, when making changes too the provider ie creating a new user, sometimes the change doesnt propagate too all the consumers some have the correct entries and some dont. If I then
[...]
Although this description doesn't allow a conclusive statement, there's a very likely correlation between this behavior and some known, already fixed, bugs[0].
So go to http://www.openldap.org/ to upgrade to the latest version, and see if this behavior persists.
On 25/04/2012 14:17, Aaron Richton wrote:
On Wed, 25 Apr 2012, Mark Coetser wrote: [...]
I have multiple consumers with a single provider, when making changes too the provider ie creating a new user, sometimes the change doesnt propagate too all the consumers some have the correct entries and some dont. If I then
[...]
Although this description doesn't allow a conclusive statement, there's a very likely correlation between this behavior and some known, already fixed, bugs[0].
So go to http://www.openldap.org/ to upgrade to the latest version, and see if this behavior persists.
Hi Aaron
the thing is that all the versions on the servers are all the same so if it was a bug surely the issue would occur across all the servers?
another issue is that using debian stable due too internal company policies means that I would have too stick too the current version until a newer version is released within the debian stable package tree.
Is there no way too debug the syncrepl too try and see if I can find the cause?
On Wed, 25 Apr 2012, Mark Coetser wrote:
the thing is that all the versions on the servers are all the same so if it was a bug surely the issue would occur across all the servers?
Most of the bugs that make it far enough to ship in a tagged release are quite a bit more subtle than 100% reproducibility. Especially with replication, there are extremely minute timing subtleties/races/etc. (Things that are that easy to find tend to make it into the test suite, after all.)
another issue is that using debian stable due too internal company policies means that I would have too stick too the current version until a newer version is released within the debian stable package tree.
Not necessarily the best idea...
Is there no way too debug the syncrepl too try and see if I can find the cause?
Of course you can; that's the beauty of an open project. Runtime, "slapd -d sync" and similar (see slapd(8)/slapd.conf(5) man pages). For potentially faster results, you can go to http://www.openldap.org/its/ and read through the debugging, triage, and resolution that occurred for known issues. Perhaps you could reproduce those steps in your environment, to confirm if your scenario matches.
And assuming there's a match in the ITS, you'd mail debian stable with "hey, OpenLDAP fixed their ITS#1234 five months ago, let's get that fix into debian stable?"
And Debian would probably write you back with something similar to: http://www.openldap.org/faq/data/cache/1456.html
And then you'd end up going to www.openldap.org and upgrading to the latest published release, OR saying "this is a known issue of debian stable, debian stable is desired via internal policies, therefore this known issue is desired under internal policies. Don't complain about things that are desired."
openldap-technical@openldap.org
-
Aaron Richton -
Mark Coetser