Re: (ITS#8799) slaptest fails to properly convert chain configuration

[ondra@mistotebe.net]

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

-- 
OndÅ?ej Kuzník
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP