Re: managing OpenLDAP / back-config

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Howard Chu writes:
> One thing I find to be extremely awkward about other directory server
> products is the fact that they corral you into using their custom
> tools to do administration. If they even have a generic admin
> interface it's poorly documented and hidden in a corner somewhere.
> (...)
> Tools that make certain commonplace tasks easier are certainly a good
> thing.  But when the tools get in the way, (e.g., FedoraDS where there
> are even more bug reports about getting their admin server running
> than for their actual directory server), the whole effort is just
> pointless.

Indeed.  For most of my tasks, my editor is the best API I've got.
Or it would be if the task allowed it.

One main difference is tasks I don't know very well, when a specialized
API can know it better than I do.  Assuming it's correct, of course:-)
Similarly, a good config API would be useful when one first sets up
OpenLDAP.

> (...)  On the command line, the only thing I ever wish for is a more
> compact input format than LDIF.

ITS#5312 - ldapmodify defaults:-)

Seriously, some suggestions to simplify that:

We can include a program which dumps out a subset of cn=config, lets you
edit it, generates a diff from the original, shows the changes, and
applies it.  That at least gets rid the add:/delete:/replace: LDIF
verbosity.

It'd be nice if if it prettified the ldif a bit first, e.g. chose good
places for line breaks in access statements.  But I guess that needs a
way for the server to tell the client how to format attributes, so it's
a lot more work.

(I'd like even more if something could generate slapd.conf-format and
convert back to ldif, but that would have to be a slap tool or some
magic LDAP request which gets a lot of help from slapd.  I can't think
of a reasonably simple way to do the latter.)

As I think I've mentioned before, it'd help make things less verbose if
back-config did not create attributes with defaulted values, or marked
such defaults with an attribute option.

Assertion controls in the generated LDIF, to check that the config entry
being updated indeed matches the entry we read from cn=config and
edited.

This requires support for assertion controls in back-ldif/back-config,
and some attribute for the assertion to test.  Maybe an automatically
maintained md5sum(contents of entry) attribute.  From an implicitly
included overlay, I guess.  (Lacking that, it could at least check
modifyTimeStamp.)


For similar reasons it'd help to have EQUALITY matching rules on all
cn=config attributes.  When we write by hand an LDIF to feed ldapmodify,
we can then write delete: <old value> / add: <new value>.  That adds a
extra check for what we are changing.

I suggested once to give config entries more informative names than
things like olcDatabase={0}<backend> too, more like
oldDatabaseName=(something derived from suffix, if possible).  That'd
also make it easier to see what one is doing, and ensure it is done to
the right entry.  assert(olcSuffix=...) helps when editing the database
entry, but can't be used on its subordinates.

-- 
Regards,
Hallvard