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
