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="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--
-
jclarke＠linagora.com