Will Dowling wrote:
No, you are never supposed to muck with any of the files inside slapd.d. You slapadd the LDIF files, same way you would load any other LDIF file into slapd.
Wow, okay. The online documentation doesn't make that clear at all (especially when it talks about converting your old config).
http://www.openldap.org/doc/admin24/slapdconf2.html
I'm not about to start picking fights with the Chief Architect though.
Keeping that in mind - are you advocating this from a design point of view (it won't work properly), or a precautionary one (you shouldn't unless you know what you're doing)?
If you know what you're doing, you can binary edit a BDB database file if you really want to. But most people don't want to, and certainly most people won't know what they're doing.
cn=config is a slapd database and should be treated as such. The contents are not vanilla LDIF files, and database internals are always subject to change. It was designed to be used like other LDAP databases - using ldap* tools when slapd is running, and using slap* tools when slapd is offline.
If it's the former (it won't work properly), can you make any recommendations for best-practice in terms of maintaining changes to third-party packaged configurations?
For example, if we roll out updated schmea, would it be best to drop and re-add the schema - or diff the structure and create an update LDIF?
Applying a diff via ldapmodify would be Best; that was the intended use case.
Seems a bit clunky if thats the case, but I have had a few settings not stick already (olcDatabaseDirectory).
Anyway, would love your insight and thanks for your time :)