ando@sys-net.it wrote:
h.b.furuseth@usit.uio.no wrote:
michael@stroeder.com writes:
The following attribute type declaration references 'managedInfo' which is not declared:
( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of URIs a proxy is serving; can be modified run-time' SUP managedInfo )
Please mention where the code is which you refer to.
Anyway, this is in back-ldap/monitor.c and managedInfo *is* declared - in back-monitor/init.c. Have you observed a failure, e.g. with back-ldap and ./configure --disable-monitor?
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'. I don't see a quick fix (or anything but requiring loading the modules in the right order) to this issue. In fact, the only "clean" solution would be for back-ldap to register a function that is executed when back-monitor is loaded, in order to register dependent schema items and enable the monitoring feature it implements. The safest thing to do right now is condition the registration of 'olmDbURIList' to the existence of 'managedInfo', conditioning the availability of the monitoring feature to loading the modules in the right order. Of course this ought to be documented somewhere. Note that probably similar issues exist in back-bdb's specific monitoring features. The fact that I seldom develop while building backends and overlays as modules might have an impact on this type of issues, though.
We already solved this dependency in back-ldap and back-bdb - their monitor_init() functions will return without doing anything if backend_info("monitor") fails. As such, these schema items will only be registered if back-monitor has already beeen loaded. There's no issue here.