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

Re: olcPasswordHash scheme not available

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/