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.
Hi Howard,
I'm still having problems understanding the basis for this design.
Can you please elaborate on why the files in slapd.d are not considered editable? What is stopping OpenLDAP supporting processing user-edited files in this location?
These files are database entries. Each entry contains operational attributes such as modifyTimestamp and such. If you edit by hand without updating the operational attributes correctly, Things Can Break.
Also, these are not RFC-compliant LDIF files. They are a slapd-specific format that is 98% LDIF-compliant. We will never document what the differences are from the standard format, because internal file formats are *always* open to change without notice.
Assuming users aren't editing the configuration "database", what is the point of making it a dot-d style directory as opposed to a seperate backend database?
It is of course possible for a careful, clueful admin to edit the files by hand without breaking anything. Just like it is possible for a careful, clueful admin to binary edit the *.bdb files in a back-bdb or back-hdb database. But let's face it, the majority of people out there, and particularly the people having problems that drive them to post on this mailing list, are neither careful enough nor clueful enough to qualify for these activities.
This seems at-odds with the concept of a dot-d style configuration directory: a reasonable person having experience with other software packages would assume that the contents of the slapd.d directories are editable and read into memory when slapd is started.
A reasonable person should understand (since the documentation states this clearly, multiple times) that this is an LDAP database and is meant to be manipulated using LDAP operations. Period, end of story.
Once you get used to manually editing the raw files, you run into the very real danger of editing while slapd is running, and then confusing the hell out of yourself when things behave in ways other than you expected. The only way to avoid creating such messes is to simply be disciplined enough in the first place to only manipulate things the way they were designed to be done.
If you go back into the openldap-devel discussions from 2003 or so when we first started working on cn=config you may see that there's of course a desire to keep slapd.d human-readable, to make things less painful in case of disaster recovery. So yes, while cn=config is an LDAP database and we could at any point in the future migrate it to a binary file format, it's not really likely to happen. But, in the interests of keeping our options open, we continue to drive the point - cn=config is an LDAP database. The underlying storage format is open to change at any time without warning. You should *never* rely on the internal storage format of any of these databases. You should *only* use the standard tools to manipulate them, that's why those tools exist in the first place.
I'm all for the benefits that are introduced by making the configuration reflectable and allowing for runtime configuration - don't get me wrong.
But I think there is room for valuable other benefits to be realised also, and I'm trying to figure out whether or not there is opportunity for my organisation to contribute resources to help realise this.