Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete

[jclarke@linagora.com]

On 14.02.2009 01:51, Howard Chu wrote:
> Jonathan Clarke wrote:
>> On 13.02.2009 01:23, Howard Chu wrote:
>>> If you want a setup similar to test049, follow what it does. If you
>>> want to something else, do otherwise.
>> I am following what test049 does. Only difference is test049 starts
>> slapd with "-h $URI1" (with URI1="ldap://localhost:9011/";) and I start
>> slapd with no -h option or a slightly different URI. This is quite
>> common, I believe.
>
> And the slapd(8) manpage clearly states that with no -h option, it
> defaults to "ldap:///";. If the default suits your purpose, use it. If
> not, then specify the URL you want explicitly. Yes, it's quite common to
> start slapd with no -h option, because it suits the general case. This
> discussion is not about the general case.
>
>> If you patch the test as follows, it fails:
>
> Obviously you should not do that.
>
>>> 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?
>
> 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:
1) cn=config becoming read-only (shadow) and updates returning a referral.
2) in a MMR setup, some updates not being replicated to all N servers.

Regards,
Jonathan