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.
Show replies by date
--On Thursday, February 05, 2009 11:07 AM +0100 Thomas Chemineau
<tchemineau(a)linagora.com> wrote:
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.
I suggest you file an ITS.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration