Why built-in schemas are a bad idea

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

Hi!

I had reported about trouble when upgrading the openldap from SLES11 SP4 to that from SLES12 SP3.
Besides the version jump, SUSE also removed some modules that had been static in SLES11, so that they need to be loaded dynamically now. Besides that, the bdb version was updated as well, and some other minor things.

The real problem is that I'll need to change cn=config to include the modules, one of them being accesslog.
The main problem there seems to be that the accesslog module provides the accesslog schema also, meaning the schema is unknown until the module is loaded.
Now no configuration change is accepted, because there are attributes in the config database without a schema:

# slapadd -q -n0 -F /etc/openldap/slapd.d/ -l module.ldif
5be00c86 <= str2entry: str2ad(olcAccessLogDB): attribute type undefined
slapadd: bad configuration directory

I once did edit the config-db files directly and managed to get slapd running (and bdb auto-upgraded itself), but I'm looking for a clean solution.

The other things I've noticed was that the old SLES11 openldap would not accept a module load directive when the module is not found (mdb in particular); loading modules that are statically included is no problem, however. This makes a replicated cn=config very difficult for a rolling upgrade of MMR servers.

Any splendid idea how to add the accesslog module to a cn=config that already has accesslog configured for ist databases? Even temporarily removing the conflicting attributes does not work.

Regards,
Ulrich