Re: managing OpenLDAP / back-config

["Gavin Henry" <ghenry@suretecsystems.com>]

<quote who="Hallvard B Furuseth">
> 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.

ldapvi is very good for all this.

http://www.lichteblau.com/ldapvi/

>
> 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
>