jclarke@linagora.com wrote:
On 14.02.2009 01:51, Howard Chu wrote:
Jonathan Clarke wrote:
On 13.02.2009 01:23, Howard Chu wrote:
There are valid reasons to point a syncrepl consumer at the same slapd (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a subtree of a main database, etc.). Using the exhaustive matching that serverID uses would preclude those cases from working.
I see. I understand you don't want to break existing functionality. However, I still feel this is a bug, or at least that you need to "hack" the setup to get things working as expected.
The docs state that "syncrepl provider" is the LDAP URI of the master server. If you're not putting in the same URI as the master is using, that's a config error, not a bug.
Understood. Nothing is broken, and we have worked around this issue using explicit listeners to slapd -h.
This behaviour did surprise me, considering the behaviour of serverID matching. May I suggest that a note of warning is included in the admin guide? For example: http://milopita.phillipoux.net/jonathan-clarke-20090216.patch
Would I be right in assuming that in all the "valid reasons to point a syncrepl consumer at the same slapd" you mention, the syncrepl consumer uses a different base DN than the base DN of the database that the syncrepl consumer is configured on? If so, maybe the exhaustive matching that serverID uses could be used, if and only if those two base DNs are different?
Actually, the exhaustive matching is only needed if the two base DNs are the same. This is now patched in HEAD, please test.
That sounds reasonable. Will think about it a bit more. Certainly if the two base DNs are the same, it will cause a loop...
Indeed. For what it's worth, while testing on cn=config, I noticed this having various consequences including:
- cn=config becoming read-only (shadow) and updates returning a referral.
- in a MMR setup, some updates not being replicated to all N servers.
-
hyc＠symas.com