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.