[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: managing OpenLDAP / back-config

On Dienstag, 15. Januar 2008, Hallvard B Furuseth wrote:
> 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.
Yes. But on the other hand you are a very experienced OpenLDAP user :)

> 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.
Hm, have you heard of ldapvi? I think that does exactly what you are 
describing above:


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