Re: (ITS#5829) Missing moduleload doc. confusing chain/distproc/slapi.

[hyc@symas.com]

h.b.furuseth@usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS:
> URL:
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> slapd.conf(5)'s moduleload description should say which filename a
> module has: foo.so or foo.la.  (Or worse - is that different on
> different OSes?  Windows, anyone?)

"foo.la" will work on all platforms. The actual shared object that the .la 
file points to may have different naming conventions on different platforms.

> It should say where the standard installed modules are found.

> Also that is a default modulepath which as far as I can tell from
> strace includes the standard installation directory and the system
> loader's standard load path.  And again, is it OS-dependent?  It
> uses libtool's lt_dlopenext(), I haven't looked for what it does yet.

I would expect that of course yes, the system loader's standard path is 
OS-dependent.

> slapd.plugin(5) should mention that slapi itself is a module which
> may need to be loaded.  And that it's "slapi.la", not "plugin.la".

> The chain and distproc overlays are not found in<overlay>.la but in
> back_ldap.la.  This should be documented.  I suggest a "moduleload
> back_ldap.la" statement before all the other directives, with
> explanation.
>
> However, even if documented, people will miss that.  One does't look
> for doc about what one already "knows".
>
> The simplest and maybe most informative fix would be to add dummy
> modules which simply give an error message that the overlays are found
> in the back_ldap module.

When the software knows exactly what must be done, failing with an error 
message is just annoying. If we were to do anything here at all, dummy modules 
would better be replaced by symlinks to the actual module, so that It Just 
Works. But I think just noting the discrepancy in the documentation is sufficient.

> An alternative would be to move them to separate modules which depend on
> back-ldap - and document their dependency on back-ldap.  More correct I
> guess, but personally I don't see how it's an improvement.  That might
> just be because I have had little to do with maintaining binary
> distributions though.

I don't think it's an improvement either.

> A third would be to store a module registry where module names are
> mapped to one or more module filenames to load.  Overkill?  More
> general, but also more complex.

Yes, overkill. And there are probably more modules out there than we would 
ever know about for a registry, so ultimately not useful.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/