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.