Full_Name: Michael Str�der Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.96.75) 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 )
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? -- Hallvard
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. 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 -----------------------------------
On Jun 23, 2008, at 4:58 PM, michael@stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.96.75) > > > 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 ) THe fact that this element is published with a .666 OID is a bug. . 666 are intended for experiments and should never be published. -- Kurt
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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
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. > 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. Well, that's doable, if anyone cares. Or a simpler variant would be: back-monitor complains if it can tell it's not the first moduleloaded module, or modules that try to use back-monitor set a "I couldn't find back-monitor" flag and back-monitor logs a warning if that flag is set. -- Hallvard
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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hallvard B Furuseth 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'm simply looking an cn=monitor of RE24. I probably have to rephrase that: The schema elements of back-monitor seems not to be available in the subschema subentry. Ciao, Michael.
Kurt Zeilenga wrote: > > On Jun 23, 2008, at 4:58 PM, michael@stroeder.com wrote: >> ( 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 ) > > THe fact that this element is published with a .666 OID is a bug. .666 > are intended for experiments and should never be published. Sorry, could have been in my build because of -DDEVEL. Nevertheless I'd appreciate if the schema elements of back-monitor are published in subschema subentry. Ciao, Michael. P.S.: Frankly I see no problem with publishing a .666 OID.
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 -----------------------------------
Michael Ströder wrote: > Kurt Zeilenga wrote: >> >> On Jun 23, 2008, at 4:58 PM, michael@stroeder.com wrote: >>> ( 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 ) >> >> THe fact that this element is published with a .666 OID is a bug. >> .666 are intended for experiments and should never be published. > > Sorry, could have been in my build because of -DDEVEL. Built without -DDEVEL and this schema element is still there but not 'managedInfo'. > P.S.: Frankly I see no problem with publishing a .666 OID. Personally I'd prefer to see interims schema elements in the subschema subentry over seeing no schema declaration for existing attributes. Ciao, Michael.
moved from Incoming to Software Bugs
Fixed by ITS#9351, monitor is always static now *** This issue has been marked as a duplicate of issue 9351 ***