OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Archive.Incoming/2137
Full headers

From: bruno.spieler@atosorigin.com
Subject: Slurpd cannot handle multiple replica statements for a single slave server
Compose comment
Download message
State:
0 replies:
1 followups: 1

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 11 Oct 2002 13:38:28 GMT
From: bruno.spieler@atosorigin.com
To: openldap-its@OpenLDAP.org
Subject: Slurpd cannot handle multiple replica statements for a single slave server
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).




Followup 1

Download message
Date: Mon, 19 Jul 2004 13:56:41 -0300
From: Andreas <andreas@conectiva.com.br>
To: openldap-its@OpenLDAP.org
Subject: Slurpd cannot handle multiple replica statements for a single slave server (ITS#2137)]
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.


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org