cn=config schema, matching rules and UX with web2ldap

[Michael Ströder]

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%2Fldapi/olcDatabase%3D%7B2%7Dmdb%2Ccn%3Dconfigbindname=uid%3Daead%2Ccn%3Dae%2Cou%3Dae-dir,X-BINDPW=CorrectHorseBatteryStaple

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.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ITS#8286 pending questions

[Michael Ströder]

Howard Chu wrote:
> Michael Ströder wrote:
>> Quanah Gibson-Mount wrote:
>>>  servers/slapd/bconfig.c ---
>>> olcInclude -- case ignore match?
>>
>> Is already defined with caseExactMatch via "SUP labeledURI".
>> IMO deriving from labeledURI does not make sense though.
> 
> olcInclude takes URIs. Typically file:// URIs. It could also take
> ldap:// URIs.

Ok. Anyway nothing to change because file and ldap URIs must be treated
case-sensitive.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ITS#8286 pending questions

[Michael Ströder]

Some more comments on a sub-set of the attributes.

Quanah Gibson-Mount wrote:
> olcReferral -- case ignore match?

It's already declared SUP labeledURI and therefore has caseExactMatch.
This makes sense because it could specify an LDAPI URL with
case-sensitive socket path name.

> olcRootPw -- case exact match?

Any EQUALITY matching rule needed at all?
If yes, use EQUALITY octetStringMatch as with userPassword.

> olcTCPBuffer -- case ignore match?

Also might contain listener URL. So maybe same like olcReferral even
though an LDAPI URI does not make sense with TCP buffers?

> olcTLSCipherSuite -- case ignore match?

I don't have a strong opinion on that because I don't have an oversight
how the supported crypto libs treat this strings.

> olcTLSSECName -- case ignore match?

??? Cannot find this in 2.4 schema. Is that new in 2.5?

> olcTLSProtocolMin -- case ignore match?
> 
>  BACKENDS ---
> --- back-asyncmeta
> olcDbURI -- case ignore match?

Same like olcReferral.

> olcDbURI -- case ignore match?

Same like olcReferral for back-ldap and back-meta.

> --- back-sql
> olcDbHost -- case ignore match?

This could also contain a Unix domain socket?
If yes, caseExactMatch.

> olcDbName -- case ignore match?

Hmm, I'm not sure. Also not sure about all the attrs containing SQL
statements.

> --- dds.c
> olcDDSmaxTtl -- case ignore match?
> olcDDSminTtl -- case ignore match?
> olcDDSdefaultTtl -- case ignore match?
> olcDDSinterval -- case ignore match?
> olcDDStolerance -- case ignore match?

Why are the TTL attributes strings at all? I see no reason why there are
not defined as Integer syntax.

> --- memberof.c
> olcMemberOfDangling -- case ignore match?

This serves as a good example for an enum type. I'd argue that it should
be limited to this particular set of lower-cased values.

> olcMemberOfGroupOC -- case ignore match?
> olcMemberOfMemberAD -- case ignore match?
> olcMemberOfMemberOfAD -- case ignore match?

AFAICS these always reference a single object class or attribute type.
So why not declare them with syntax OID?
Same suggestion for similar attributes of other overlays.

> olcMemberOfDanglingError -- case ignore match?

Is this just the LDAP error code?
If yes, define it as Integer.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ITS#8286 pending questions

[Howard Chu]

Michael Ströder wrote:

Quanah Gibson-Mount wrote:

I've done a first pass through the source tree adding missing matching
rules to the olc* attributes to address ITS#8286
().  However,
many of the attributes are string types, and can either be case
exact/ignore match.  The following is a list of those attributes, and my
best guess at which they should be.


It really depends on the default use-case and whether an attribute could
be used in a RDN or not.

Since POSIX file systems are case-sensitive I'd say that all attributes
containing file-system path names must be defined with caseExactMatch.

   Once I have a definitive answer on

these, I'll commit them:

 servers/slapd/bconfig.c ---
olcInclude -- case ignore match?


Is already defined with caseExactMatch via "SUP labeledURI".
IMO deriving from labeledURI does not make sense though.

Ciao, Michael.


olcInclude takes URIs. Typically file:// URIs. It could also take ldap:// URIs.

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: ITS#8286 pending questions

[Michael Ströder]

Quanah Gibson-Mount wrote:
> I've done a first pass through the source tree adding missing matching
> rules to the olc* attributes to address ITS#8286
> ().  However,
> many of the attributes are string types, and can either be case
> exact/ignore match.  The following is a list of those attributes, and my
> best guess at which they should be.

It really depends on the default use-case and whether an attribute could
be used in a RDN or not.

Since POSIX file systems are case-sensitive I'd say that all attributes
containing file-system path names must be defined with caseExactMatch.

  Once I have a definitive answer on
> these, I'll commit them:
> 
>  servers/slapd/bconfig.c ---
> olcInclude -- case ignore match?

Is already defined with caseExactMatch via "SUP labeledURI".
IMO deriving from labeledURI does not make sense though.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature