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.