On Mon, Jan 22, 2018 at 11:57:38PM +0000, ondra@mistotebe.net wrote:

On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah@openldap.org wrote:

...

After doing conversion, the resulting cn=config database has *two* ldap backends defined:

dn: olcDatabase={-1}frontend,cn=config dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf

This is the catchall database used to handle referrals that are not handled by any other database you configure by hand. It collects all the chain-* settings that appear before the first chain-uri.

...

dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf

The first instance ({0}ldap,...) isn't even valid. If you remove the entire chain configuration from this database, and then attempt to import it, you get the following:

Yeah that is a problem.

Turns out the problem is different yet. When the overlay is started up after adding its entry, it generates a default backend internally. On adding the above backend it now thinks it has a default one already (even though there is no entry for it yet) and rejects it.

...

This is because the first instance ({0}) is *missing* the required olcDbURI attribute. In addition, it generates completely bogus attribute values (See ITS#8693)

Maybe we just need to inherit objectclass: olcLdapDatabase somehow in olcChainOverlay and keep these settings in the overlay entry, or specify a bogus URI to be configured there. Whatever is most useable and still allows for seamless expansion.

Still thinking making the overlay objectclass inherit the attributes from olcLdapDatabase instead of creating a fake DB but that can't be done for 2.4 and I have no idea how to properly go about that yet anyway.

For 2.4 at least it might make sense to just use the flags on the default backend to say it has no entry associated with it (yet) and: - clear that in ldap_chain_cfadd_apply so we know it can be replaced later - also create the entry if slapd is just starting up (How about cn=config replication though? Upgrades need to be planned) - maybe only let a default backend be added if there really is no other backend yet (including the temporary ones used during normal operation), since those will get some defaults from it