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.
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. Instead the whole attribute is deleted and all attribute values
are re-added. And before anyone complains: Managing large group entries
with lots of values in the member attribute (being member, memberUID or
whatever) is done in a separate UI with another modification approach
which requires a EQUALITY matching rule for the member attribute.
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... ;-)
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. :-/
Ciao, Michael.