Re: managing OpenLDAP / back-config

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

Michael Ströder writes:

[rearranging a little]

> Ok, why I'm writing this? Sometimes I'm getting sick about people asking
> for a software with features which I've already implemented since years.
> The same feeling Howard has when people are citing old OpenLDAP
> benchmarks. :-/

Oh, I'm unsurprised that some of this exists already.  I've written my
own bits and pieces long ago, after all.  (Not for back-config though.)
And we could collect some suggestions to software to use in the doc,
just as well as including some code.

The FAQ lists various clients, but it just lists them - doesn't give
much clue about which one would want to look at for what.

>Hallvard B Furuseth wrote:
>>
>> 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.
>
> BTW: web2ldap implements delta-modification. The entry is re-read right
> before the delta of the current entry and the user's input is generated.
> This works quite well since years with several LDAP servers. If there
> was a modification in between the delta modification still applies
> correctly.

Not sure if I should be writing this since I've hardly looked at
web2ldap yet, but anyway...  I don't quite get that.  I'd think a
correct delta would be generated by comparing with the entries as they
looked when the user started editing.  Minus any changes that have
happened already.  With back-config I would _not_ my changes to be
applied without asking me if there had been changes since I started
editing, hence my suggestion of assertions.  A delta agains the current
directory would be useful to see if my own changes conflict in intent
with the changes that have already happened (regardless of whether my
changes would apply cleanly.)

>> For similar reasons it'd help to have EQUALITY matching rules on all
>> cn=config attributes.
>
> The delta modification list generated by web2ldap does not contain
> a del <old value> to avoid problems with missing EQUALITY matching
> rules.o

As I said in the next sentence this would be useful when writing a
change LDIF by hand (instead of a tool which generates the diffs).

>> 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).
>
> A configuration UI can display more information when listing backend
> entries read from e.g. 'description'. Guess what, web2ldap is already
> doing this - not only for cn=config... ;-)

But it can't when you are not using it, just writing a change by hand.
Also it might not catch if someone has renamed the entries - like adding
a new database definition which gets the name of the one you are
editing.  You may end up adding a new overlay to thewrong database, or
something.  (Assuming back-config supports adding a new db in the middle
yet, I haven't checked.)  Don't know if web2ldap does this, but it's
in any case an unnecessary problem.

-- 
Hallvard