rhafer@suse.de wrote:

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.243.151)

After adding the following LDIF to cn=config (via ldapadd), slapd does not start anymore:

---

dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectclass: olcChainConfig

dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectclass: olcLDAPConfig objectclass: olcChainDatabase olcDbUri: ldap://ldap.server olcDatbase: {0}ldap

---

To add some fun. Everything works as expected if I reorder the "objectClass" Values so that "olcLDAPConfig" appears after "olcChainDatabase".

Additionally the error messages I get in the log when slapd fails to start with the above config seem to be completely unrelated:

---

olcRootPW: value #0:<olcRootPW> can only be set when rootdn is under suffix config error processing olcDatabase={0}config,cn=config:<olcRootPW> can only be set when rootdn is under suffix

---

The underlying problem seems to be that, when the "olcLDAPConfig" objectclass appears first slapd seems to choose the wrong ConfigTable for the olcDatabase attribute of the olcChainDatabase object. Instead of using olcDatabaseDummy as defined in back-ldap/chain.c it uses the "normal" ConfigTable and starts up the LDAP Database as if it were in "normal" database, including adding it to the backendDB list. As I configured the chain overlay as a global overlay this back-ldap database is put to the front of the backendDB list leading to problems when initializing the cn=config database itself, because the code assumes that the config database is always the first one, which will than lead to the strange error message above.

(... that's how far I got with analyzing the problem, I have no idea yet how to fix it though. Suggestions are welcome.)

The cleanest solution would probably be to make olcChainDatabase structural, copying all of the attributes of olcLDAPConfig into it, and dropping olcLDAPConfig itself from this situation. Too bad changing that now would break existing deployments.

I'll look into this some more.