On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah(a)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