[Date Prev][Date Next]
Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
> email@example.com wrote:
>> firstname.lastname@example.org 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__
>> 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).
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172