HI!

I'd like to highlight a bit why I'm nitpicking on schema definitions for back-config and how careful schema crafting can help to have a better UX with less effort (even though I'm personally using back-config read-only for monitoring).

The goals of web2dap are:

1. guide the user to do it right rather than enforce stuff unless "stuff" is really well-known and thus can be handled strictly

2. no overzealous actions, don't surprise the user, be trustworthy

3. do as much as possible just by looking at the subschema

So why is the syntax or a known attribute constraint important for that?

Internally web2ldap uses plugin classes which are registered to - a syntax or - list of attribute types or - combinations of attribute types and structural object classes.

Lots of plugin classes cover handling of well-defined application schema, some proprietary stuff, and weird quirks for broken schema. The classes are organized in plugin modules described here: https://www.web2ldap.de/features.html#plugin

This all turned out to be quite powerful. Details upon request.

Now why this long story?

Of course there's also a plugin module for OpenLDAP-specific schema, especially for slapo-accesslog but also some stuff for cn=config (remember my presentation at ODD in Tübingen long time ago?).

https://fossies.org/linux/web2ldap/web2ldap/app/plugins/openldap.py

So here's a simple example for the case-exact vs. case-insensitive discussion:

For attribute 'olcMemberOfDangling' I could add such a class:

class OlcMemberOfDangling(SelectList): oid = 'OlcMemberOfDangling-oid' desc = 'Behavior in case of dangling references during modification' attr_value_dict = { u'':u'-/-', u'ignore':u'ignore', u'drop':u'drop', u'error':u'error', }

syntax_registry.registerAttrType( OlcMemberOfDangling.oid,[ '1.3.6.1.4.1.4203.1.12.2.3.3.18.1', # olcMemberOfDangling ] )

As you can imagine the dict keys in attr_value_dict are the real values, the values are the UI description.

Now if the existing entry contains a mixed-case value exactly this value is added to the select list to preserve this exact value in any case.

Example:

dn: olcOverlay={7}memberof,olcDatabase={2}mdb,cn=config olcMemberOfDangling: IGNore

The select list in the UI would contain: ignore drop error IGNore

Hmm, that likely looks confusing to the user in the UI.

So I could define a lower-case sanitizing like this:

class OlcMemberOfDangling(SelectList): [..class attrs like above..] simpleSanitizers = ( str.lower, )

But in this case the existing value would be altered and sent along with the modify request thus also confusing the user because the altering was not result of his/her action.

So it boils down that being more strict with values can lead to a better user experience. In this case I'd recommend that slapd would always *sanitize* the value to lower-case.

I'd be glad if OpenLDAP developers could consider those aspects in the future. Bear in mind that the above is just one very simple example.

web2ldap has also base classes for attribute type names or object class names where it displays direct links into the schema browsers. Hence I proposed to declare some cn=config attributes as OID syntax.

Interested readers can directly play with web2ldap and Æ-DIR's cn=config:

https://demo.ae-dir.com/web2ldap/dit?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%2...

Sorry, read-only, but you can display the input forms and see what's displayed along the attributes.

There is more you could do in later releases beyond 2.5. For inspiration here's the plugin module for OpenDJ's cn=config:

https://fossies.org/linux/web2ldap/web2ldap/app/plugins/opends.py

It can make heavy use of web2ldap's DynamicDNSelectList because many config values are just references to other entries.

Ciao, Michael.