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

The process for converting a slapd configuration to cn=config making use of slapo-chain at a global level is seriously broken.

It's not as bad, just a little bit broken:

This can be trivially illustrated by using the slapd.conf generated by test032.

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.

ldap_add: Object class violation (65)

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.

The *second* generated LDAP backend database is what is correct.

Here's the LDIF for the incorrect database:

[...]

Here's the LDIF for the *correct* database:

[...]