The ldapdb plug-in initialization for clients is too noisy!

Greg A. Woods woods-cyrus at
Thu May 28 16:02:45 EDT 2009

The ldapdb plug-in initialization for clients is too noisy!

I recently, and for the first time, have built Cyrus-SASL with the
ldapdb plug-in.  Now every client on every system _not_ using LDAP
complains on every start up with the following error:

	auxpropfunc error invalid parameter supplied

(which I've patched to be a little more detailed showing _which_ plug-in
returned the error! -- SASL error reporting is sometimes horribly
minimalistic and almost totally unhelpful!)

It seems the LDAP plug-in is a little too eager to initialize itself
even when it is not called upon or used, and a little too worried about
its inability to do this initialization when it is not actually needed.

I don't want to have to build custom versions of SASL (and, because I
need to link everything statically, custom versions of everything that
uses SASL) for just the LDAP users I support.  The question is how to
fix this in a way which would be acceptable for an upstream patch.

One simple possibility is to return some other more benign error from
ldapdb_auxprop_plug_init() instead of SASL_BADPARAM (eg. SASL_NOMECH)
and then transmute the log level flag from SASL_LOG_ERR to something
more like SASL_LOG_NOTE so that it won't spam the console and/or other
critical error log files.

More correct might be to defer configuring all of the plug-in until the
point where it is first actually called upon to do something.  I see
that some other plug-ins do try to load config parameters in their
_plug_init() routines, but almost universally they will 

Yet another possibility might be to have an explicit way to disable the
plug-in in the configuration file and thereby avoid all initialization
if it has been disabled.  Perhaps the default <none> entry for
ldapdb_uri should work this way?  (i.e. the error return should simply
be removed?)

(note all of the other plug-ins I compile into my SASL libraries run
their *_plug_init() function successfully -- though of course none of
the others I use require such extensive and crazy initialization!)

						Greg A. Woods

+1 416 218-0098                VE3TCP          RoboHack <woods at>
Planix, Inc. <woods at>      Secrets of the Weird <woods at>

More information about the Cyrus-devel mailing list