[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: two databases replicating to one slave server doesn't work



Buchan Milne wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas wrote:
| openldap-2.1.30
| berkeley db 4.2.52 + 2 patches
|

I'm running the same versions, and it gets more interesting ... see below.

I have 3 databases, 4 replicas for the first two, 5 for the 3rd, but
each replica uses different replica DNs. But, it seems slurpd gets
confused, and uses the wrong replica DN for a specific database:

# grep -E "(^suffix|^replica|^replog|binddn)" /etc/openldap/slapd.conf
suffix          "cn=mail,ou=isp"
replogfile      /var/lib/ldap/mail/replog
replica         host=io:389
~                binddn="cn=root,cn=mail,ou=isp"
replica         host=ganymedes:389
~                binddn="cn=root,cn=mail,ou=isp"
replica         host=leda:389
~                binddn="cn=root,cn=mail,ou=isp"
replica         host=elara:389
~                binddn="cn=root,cn=mail,ou=isp"
#                binddn="cn=root,cn=mail,ou=isp" bindmethod=simple
credentials=mailme99
#                binddn="cn=root,cn=mail,ou=isp" bindmethod=simple
credentials=mailme99
suffix          "ou=radius,o=intekom,c=za"
replogfile      /var/lib/ldap/radius/replog
replica         host=io:389
~                binddn="cn=root,ou=radius,o=intekom,c=za"
replica         host=ganymedes:389
~                binddn="cn=root,ou=radius,o=intekom,c=za"
replica         host=leda:389
~                binddn="cn=root,ou=radius,o=intekom,c=za"
replica         host=elara:389
~                binddn="cn=root,ou=radius,o=intekom,c=za"
#                binddn="cn=root,ou=radius,o=intekom,c=za"
bindmethod=simple credentials=infranetpoid
#                binddn="cn=root,ou=radius,o=intekom,c=za"
bindmethod=simple credentials=infranetpoid
suffix          "dc=telkomsa,dc=net"
replogfile      /var/lib/ldap/openldap-master-replog
replica         host=io:389
~                binddn="cn=metis,ou=Hosts,dc=telkomsa,dc=net"
replica         host=ganymedes:389
~                binddn="cn=metis,ou=Hosts,dc=telkomsa,dc=net"
replica         host=leda:389
~                binddn="cn=metis,ou=Hosts,dc=telkomsa,dc=net"
replica         host=elara:389
~                binddn="cn=metis,ou=Hosts,dc=telkomsa,dc=net"
replica         host=jupiter:389
~                binddn="cn=metis,ou=Hosts,dc=telkomsa,dc=net"

And, in the log on one of the slaves, we see:

Jul 19 16:59:57 io slapd[9732]: conn=3 op=0 BIND
dn="cn=root,ou=radius,o=intekom
,c=za" method=128
Jul 19 16:59:57 io slapd[9732]: conn=3 op=0 BIND
dn="cn=root,ou=radius,o=intekom
,c=za" mech=SIMPLE ssf=0
Jul 19 16:59:57 io slapd[9732]: conn=3 op=0 RESULT tag=97 err=0 text=
Jul 19 16:59:57 io slapd[9735]: conn=3 op=1 ADD
dn="cn=iafrica,cn=mail,ou=isp"
Jul 19 16:59:57 io slapd[9735]: conn=3 op=1 RESULT tag=105 err=10 text=


So, slurpd is trying to write to the "cn=mail,ou=isp" database as the rootdn for ou=radius,o=intekom,c=za, which is clearly wrong and obviously not going to work.

| Just for fun, I replaced one of the replica lines with the IP
| address of the slave host instead of its name. That is, I made
| the directive different from the other one, but still pointing to
| the same host.
|
| Voilá, it started working.
| So, instead of:
| (...)
| replica uri=ldap://build-cl9.distro.conectiva:389
| (...)
| replica uri=ldap://build-cl9.distro.conectiva:389
| (...)
|
| I have:
| (...)
| replica uri=ldap://10.0.17.107:389
| (...)
| replica uri=ldap://build-cl9.distro.conectiva:389
| (...)
|
| Then it works (yes, I also switched to using "uri" instead of "host"
| midtesting, but that alone didn't help).
| 10.0.17.107 is the IP address of build-cl9.distro.conectiva. Just having
| it "different" in the two replica directives seemed to be the trick.
|
| So, is this scenario not supported? Is it a glitch? A bug? Am I mad? :)
| Thanks for any input.

In our setup, it's not that simple ... it can't work as slurpd is trying
to replicate as the wrong DN for the database it is trying to replicate.

Guess it's time to file an ITS.

This feature of slurpd has been known since at least 2002 and has not been changed. It seems unlikely that it will be changed any time soon...


--
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support