From jclarke@linagora.com Fri Feb 13 16:24:15 2009 From: jclarke@linagora.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete Date: Fri, 13 Feb 2009 16:24:15 +0000 Message-ID: <200902131624.n1DGOFBS010943@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7630915010372813272==" --===============7630915010372813272== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------030704040902090700090604 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit On 13.02.2009 14:29, jclarke(a)linagora.com wrote: > On 13.02.2009 01:23, Howard Chu wrote: > =20 >> Jonathan Clarke wrote: >> =20 >>> hyc(a)symas.com wrote: >>> =20 >>>> 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...). >>>> =20 >>> 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=3D$URI1 LDIF. Otherwise it >>> would produce weird results. >>> =20 >> If you want a setup similar to test049, follow what it does. If you >> want to something else, do otherwise. >> =20 > I am following what test049 does. Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't=20 a problem for test049 indeed. Although I am curious as to why test049 creates a syncrepl consumer=20 targeted at itself? Can't quite get my head around it yet, but will keep=20 thinking, with regard to multimaster. --------------030704040902090700090604 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit On 13.02.2009 14:29, jclarke(a)linagora.com wrote: 
On 13.02.2009 01:23, Howard Chu wrote:
  
Jonathan Clarke wrote:
    
hyc(a)symas.com wrote:
      
Ah right. For the serverID code, we're doing a liberal=
 match because=20
anything
that matches the current name:port is obviously the current server,=20
and we
want it to be identified as such.

For syncrepl, we know full well that it may be the current server,=20
but for
whatever reason you may want to replicate against yourself anyway=20
(e.g.,
against a different baseDN, etc...).
        
Actually, this comes straight from test049 (config repli=
cation). 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=3D$URI1 LDIF. Otherwise it
would produce weird results.
      
If you want a setup similar to test049, follow what it doe=
s. If you=20
want to something else, do otherwise.
    
I am following what test049 does.
Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't a problem for test049 indeed.

Although I am curious as to why test049 creates a syncrepl consumer targeted at itself? Can't quite get my head around it yet, but will keep thinking, with regard to multimaster.
--------------030704040902090700090604-- --===============7630915010372813272==--