Issue 2137 - Slurpd cannot handle multiple replica statements for a single slave server
Summary: Slurpd cannot handle multiple replica statements for a single slave server
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-11 13:38 UTC by bruno.spieler@atosorigin.com
Modified: 2014-08-01 21:05 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description bruno.spieler@atosorigin.com 2002-10-11 13:38:28 UTC
Full_Name: Bruno Spieler
Version: 2.1.4
OS: Solaris 8
URL: 
Submission from: (NULL) (195.68.44.148)


Hi,

My configuration is the following (multimaster option NOT enabled) :

Two slapd servers : ldap1.mydomain.com and ldap2.mydomain.com, each of which
handling four back-ends (BDB):
 - BE #1 for suffix "o=myRoot"
 - BE #2 for suffix "ou=pub1,o=myRoot" (subordinate)
 - BE #3 for suffix "ou=pub2,o=myRoot" (subordinate)
 - BE #4 for suffix "ou=private,o=myRoot" (subordinate)

I'd like to define replication agreements between ldap1 and ldap2 so that :
 - ldap1 is master on "ou=pub1,o=myRoot" and "ou=pub2,o=myRoot" and replicates
them towards ldap2 (slave)
 - ldap2 is master on "ou=private,o=myRoot" and replicates it (some attributes
are filtered, but its does not matter here) towards ldap1 (slave)

No replication occurs at root level. No problem to set up replication from ldap2
to ldap1. The problem is to set up the replication from ldap1 to ldap2.

To do this, I added two "replica" statements in ldap1 configuration file, with
the same "host" parameter set to ldap2.mydomain.com and no "suffix" parameter.
In this case, slurpd on ldap1 get confused : when adding an entry in
"ou=pub1,o=myRoot" for exemple, each thread of slurpd (one per replica
statement)  tries to perform the same add operation on the ldap2. Ldap2
logically complains about the second update.

I guess the problem is linked to the way used by slurpd to identify the replica
agreements : "hostname:port" in the *.rej files but also in the slurpd.status
and in the slurpd.replog ("replica" statement).

Indeed, a workaround that worked fine for me (no DNS nor DHCP stuff) is to add
an alias for ldap2.mydomain.com (let's say ldap2-alias.mydomain.com) in my
/etc/hosts file on ldap1, and to use the "ldap2.mydomain.com" as "host"
parameter for the first replica statement and "ldap2-alias.mydomain.com" for the
second one.

A solution could be to add a new parameter to the replica statement: something
like agreementId="pub1replica" for example. The administrator would be in charge
of the unicity of this parameter among all the replica statements of a single
slapd configuration file, so that slurpd could use it to uniquely identify the
various replication agreements. 
A simpler solution could also be to make slurpd identify the various agreements
with something like "host:port:back-end-id" instead of "host:port", where
back-end-id would be the number of the back-end concerned by the replica
statement. Less handy when adding future back-ends definitions...

I also tried another solution : I replaced both replica statements by a single
"replica" statements in ldap1 configuration file, at the root back-end level
this time, with two "suffix" parameters : suffix="ou=pub1,o=myRoot" and
suffix="ou=pub2,o=myRoot", but no replication occurs at all in this case (seems
ok since the root back-end is not responsible for these suffixes).



Comment 1 Kurt Zeilenga 2003-02-08 22:39:48 UTC
changed notes
Comment 2 Kurt Zeilenga 2003-02-08 22:40:13 UTC
changed notes
changed state Open to Suspended
moved from Incoming to Software Bugs
Comment 3 Kurt Zeilenga 2003-02-09 06:38:08 UTC
changed notes
Comment 4 Kurt Zeilenga 2003-03-14 20:43:28 UTC
changed notes
Comment 5 Kurt Zeilenga 2003-05-31 17:49:40 UTC
changed notes
Comment 6 Kurt Zeilenga 2003-05-31 17:51:38 UTC
changed notes
Comment 7 Kurt Zeilenga 2003-06-05 09:37:15 UTC
changed notes
Comment 8 Kurt Zeilenga 2003-06-05 09:37:46 UTC
moved from Software Bugs to Historical
Comment 9 Kurt Zeilenga 2003-09-24 17:35:49 UTC
moved from Historical to Incoming
Comment 10 Kurt Zeilenga 2003-10-12 04:09:47 UTC
changed notes
Comment 11 Kurt Zeilenga 2003-12-05 07:43:58 UTC
changed notes
changed state Suspended to Closed
Comment 12 andreas@canonical.com 2004-07-19 16:56:41 UTC
The workaround doesn't work for TLS because openldap can only serve one certificate.
One cannot use two different names for the slave and only one certificate, because
the common name won't match and the TLS connection will error.

Comment 13 Howard Chu 2004-12-06 01:42:18 UTC
moved from Incoming to Archive.Incoming
Comment 14 OpenLDAP project 2014-08-01 21:05:44 UTC
has workaround
inherit issue