[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

On 13.02.2009 01:23, Howard Chu wrote:
> Jonathan Clarke wrote:
>> hyc@symas.com wrote:
>>> Ah right. For the serverID code, we're doing a liberal match because 
>>> anything
>>> that matches the current name:port is obviously the current server, 
>>> and we
>>> want it to be identified as such.
>>> For syncrepl, we know full well that it may be the current server, 
>>> but for
>>> whatever reason you may want to replicate against yourself anyway 
>>> (e.g.,
>>> against a different baseDN, etc...).
>> Actually, this comes straight from test049 (config replication). With
>> multimaster config replication, it starts by replicating itself
>> (useless, but necessary for other masters). This problem doesn't appear
>> in the test case, since a variable ($URI1) is used for both the slapd -h
>> $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it
>> would produce weird results.
> 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.

If you patch the test as follows, it fails:
--- tests/scripts/test049-sync-config    10 Feb 2009 12:29:01 -0000
+++ tests/scripts/test049-sync-config    13 Feb 2009 10:11:22 -0000
@@ -112,7 +112,7 @@ $LDAPMODIFY -D cn=config -H $URI1 -y $CO
-olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple
+olcSyncRepl: rid=001 provider=`echo $URI1 | sed 
"s/localhost/"` binddn="cn=config" bindmethod=simple

Running ./scripts/test049-sync-config...
running defines.sh
Starting producer slapd on TCP/IP port 9011...
Using ldapsearch to check that producer slapd is running...
Inserting syncprov overlay on producer...
ldapmodify failed for syncrepl config (10)!

> 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.

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