Pierangelo Masarati wrote:
Howard Chu wrote:
Pierangelo Masarati wrote:
That sounds like a bug. In fact, {K5KEY} is loaded by smbk5pwd, so if
in slapd.conf you correctly load the module __before__ using
password-hash things work as expected. However, when the configuration
is loaded from the back-config database, modules are loaded __after__
the global entry, which contains password-hash. Apparently, checking
the value of the password-hash attribute must be deferred to __after__
loading the entire configuration. This might be true in general. I
suggest you file an ITS for this issue <http://www.openldap.org/its/>.
If it's a general problem, then we're going to need to re-shuffle the
layout of the cn=config tree so that global directives are processed
after any modules are loaded. But I think password mechs are the only
item that can be registered at runtime that currently have a problem.
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.
- 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 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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
