[Date Prev][Date Next]
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
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
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172