[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: olcPasswordHash scheme not available

Howard Chu wrote:

It seems to be so.  I'm considering different approaches:

* force some sequentiality in parsing config entries; for example:
    - schema first
    - then modules (modules may rely on presence of schema)

True, the ppolicy module has this problem. I consider that a design flaw but we were specifically requested to write it that way. IMO modules should load their own schema and not have such external dependencies, which is generally how we've coded all the others.

I was not just concerned by issues like schema loaded from configuration, but also by issues like modules using stuff that depends on standard track schema, which modules could assume it's always available. Right now this is true for hardcoded schema, but might not be for configuration-loaded schema.

A possible approach would be to hardcode more of standard track, for example by using a "stdschema" module; for example, the dsaschema that's in contrib should do something like this.


    - then the rest
   but this is not ensuring the right ordering of thngs

Right. Also, modules may be used to load new syntaxes and matching rules. As such, schema needs to be loaded after modules, which is why I've ordered things that way in the current cn=config tree.

The simplest solution is to move any global options that may have module dependencies

We know which have dependencies now, but more might gain dependencies later, as soon as they get abstracted and factored out.

out of the top cn=config entry and into a subordinate entry that is parsed later. In this case it may be most appropriate to move olcPasswordHash into the database structures, and allow it to be set in the frontendDB and overridden in individual databases.

In all the above cases there's no guarantee the original ordering is preserved, so the safest solution would be to keep a changelog of configuration to be rolled-in again at startup instead of relying on the configuration stored on disk.

There should not be any other ordering dependencies.

Not now. By carefully changing stuff we should be able to avoid further issues.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------