Re: (ITS#6837) slapd doesn't start anymore after adding olcChainDatabase

[hyc@symas.com]

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.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/