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