Hi all,
Same subject, but with a minor change :) For now, as I explain in a
previous mail, it seems we have a working N-Way multimaster
replication, still with some problems.
we use RE24, checked out 2 days ago.
But, even if cn=config seems to be correclty replicated, there is a
problem with gluing database declarations.
We have a primary provider. Its config backend has been initialized by
this command : slapd -f slapd.conf -F slapd.d. All work fine, no
errors. The configuration has multiple backends (8), and some are glued.
In the slapd.conf we have something like the following :
database ldap
suffix dc=example,o=test
subordinate
database bdb
suffix o=test
glue
So, in cn=config, we have :
olcDatabase={2}ldap,cn=config
olcSuffix dc=example,o=test
olcSubordinate TRUE
olcDatabase={3}bdb,cn=config
olcSuffix o=test
olcOverlay={0}glue,olcDatabase={4}bdb,cn=config
olcOverlay {0}glue
Fine. But when the new provider replicates the entire cn=config of the
primary provider, it can not replicate this kind of configuration :
8<--------
Feb 5 10:42:37 server2 slapd[5093]: => access_allowed: add access to
"olcDatabase={2}ldap,cn=config" "entry" requested
Feb 5 10:42:37 server2 slapd[5093]: <= root access granted
Feb 5 10:42:37 server2 slapd[5093]: => access_allowed: add access
granted by manage(=mwrscxd)
Feb 5 10:42:37 server2 slapd[5093]: <= acl_access_allowed: granted to
database root
Feb 5 10:42:37 server2 slapd[5093]: => access_allowed: add access to
"cn=config" "children" requested
Feb 5 10:42:37 server2 slapd[5093]: <= root access granted
Feb 5 10:42:37 server2 slapd[5093]: => access_allowed: add access
granted by manage(=mwrscxd)
Feb 5 10:42:37 server2 slapd[5093]: >>> dnPrettyNormal:
<dc=example,o=test>
Feb 5 10:42:37 server2 slapd[5093]: <<< dnPrettyNormal:
<dc=example,o=test>, <dc=example,o=test>
Feb 5 10:42:37 server2 slapd[5093]: >>> dnPrettyNormal:
<dc=example,o=test>
Feb 5 10:42:37 server2 slapd[5093]: <<< dnPrettyNormal:
<dc=example,o=test>, <dc=example,o=test>
Feb 5 10:42:37 server2 slapd[5093]: glue: no superior found for sub
dc=example,o=test!
Feb 5 10:42:37 server2 slapd[5093]: olcSubordinate: value #0:
<olcSubordinate> handler exited with 32!
Feb 5 10:42:37 server2 slapd[5093]: send_ldap_result: conn=-1 op=0 p=0
Feb 5 10:42:37 server2 slapd[5093]: send_ldap_result: err=80 matched=""
text="<olcSubordinate> handler exited with 32"
Feb 5 10:42:37 server2 slapd[5093]: null_callback : error code 0x50
Feb 5 10:42:37 server2 slapd[5093]: syncrepl_entry: rid=001 be_add
failed (80)
Feb 5 10:42:37 server2 slapd[5093]: connection_get(12)
Feb 5 10:42:37 server2 slapd[5093]: connection_get(12): got connid=0
Feb 5 10:42:37 server2 slapd[5093]: daemon: removing 12
Feb 5 10:42:37 server2 slapd[5093]: do_syncrepl: rid=001 retrying (4
retries left)
Feb 5 10:42:37 server2 slapd[5093]: daemon: epoll: listen=7
active_threads=0 tvp=zero
Feb 5 10:42:37 arv2b slapd[5093]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Feb 5 10:42:37 arv2b slapd[5093]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Feb 5 10:42:37 arv2b slapd[5093]: daemon: epoll: listen=10
active_threads=0 tvp=zero
8<--------
Is it a bug ?
I have an idea : reorder declarations into the cn=config to have
something like that :
olcDatabase={2}bdb,cn=config
olcSuffix o=test
olcOverlay={0}glue,olcDatabase={2}bdb,cn=config
olcOverlay {0}glue
olcDatabase={3}ldap,cn=config
olcSuffix dc=example,o=test
olcSubordinate TRUE
I have the first olcDatabase={2}bdb,cn=config replicated successfully.
But an other problem appears : the DN of
olcOverlay={0}glue,olcDatabase={4}bdb,cn=config is not correclty
renamed, because of a inexcepted "charset" ? I can reproduce this
problem for all types of database. OpenLDAP complains itself and
replication does not work. Hum... but I realized that even this "tips"
works, OpenLDAP could not be restarted correctly anymore because of the
configuration's test...
Any hints, or advice would be most appreciated.
Regards,
Thomas.
