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

[ondra@mistotebe.net]

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

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