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:
[...]