hyc@symas.com wrote:

h.b.furuseth@usit.uio.no wrote:

...

ando@sys-net.it writes:

...

I suspect something like: if back-monitor and/or back-ldap are built as modules, and loaded in the wrong order (back-ldap first, back_monitor then), 'olmDbURIList' is likely to be registered __before__ 'managedInfo'.

So, a manpage fix something like this?

If monitor is a dynamically loaded module, it should be "moduleload"ed before any modules it wants to monitor. A dynamically loaded monitor may be unable to monitor a statically built module.

Not necessary. The order of moduleloads is irrelevant.

back-monitor initializes its schema as soon as the module is loaded. All of the other backends initialize their monitor schema when a backend is first instantiated. The problem you're talking about here doesn't exist.

well, all modules do. So if a module needs to register schema dependent on another module that's not loaded yet, it should either fail or, if that piece of schema is to be considered optional, just complain it couldn't do all the job. So it seems pertinent: if you load modules in the "wrong" order, you could miss monitoring functionalities. I note that back-bdb actually tries to register the schema all times a database is instantiated, unless already done. In any case, if the back_monitor module is loaded __after__ the server is already running, existing databases will not gain monitoring capabilities; only subsequent ones will. I don't consider this necessarily a bug (it could be worked out by explicitly setting "monitoring" to "on" after loading the back_monitor module, provided some backend-specific hook is invoked).

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------