Will Dowling wrote:
> No, you are never supposed to muck with any of the files inside
> You slapadd the LDIF files, same way you would load any other LDIF file
> into slapd.
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
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
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
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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/