[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
This is a multi-part message in MIME format.
--------------030704040902090700090604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 13.02.2009 14:29, jclarke@linagora.com wrote:
> 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.
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
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 13.02.2009 14:29, <a class="moz-txt-link-abbreviated" href="mailto:jclarke@linagora.com";>jclarke@linagora.com</a> wrote:
<blockquote cite="200902131329.n1DDTKF6072656@boole.openldap.org"">mid:200902131329.n1DDTKF6072656@boole.openldap.org";
type="cite">
<pre wrap="">On 13.02.2009 01:23, Howard Chu wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Jonathan Clarke wrote:
</pre>
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com";>hyc@symas.com</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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...).
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">If you want a setup similar to test049, follow what it does. If you
want to something else, do otherwise.
</pre>
</blockquote>
<pre wrap=""><!---->I am following what test049 does.</pre>
</blockquote>
Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this
isn't a problem for test049 indeed.<br>
<br>
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.<br>
</body>
</html>
--------------030704040902090700090604--