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.
--On Thursday, February 05, 2009 11:07 AM +0100 Thomas Chemineau tchemineau@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
openldap-software@openldap.org