Initializing cn=config from existing multi-master setup via syncrepl - "glue: no superior found for"

[Thomas Chemineau <tchemineau@linagora.com>]

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.