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).
changed notes
changed notes changed state Open to Suspended moved from Incoming to Software Bugs
moved from Software Bugs to Historical
moved from Historical to Incoming
changed notes changed state Suspended to Closed
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.
moved from Incoming to Archive.Incoming
has workaround inherit issue