I'm using 2.4.7 on Freebsd (5.4 and 6.2) and have a couple of questions: I had a couple of nasty signal 11 crashes trying to start cn=monitor using cn=config (OK - a tad ambitious) which obviously lost all my configuration changes: Question 1: Is there anyway I can force or control an update to the cn=config LDIF files in slapd.d To get cn=monitor running I finally dropped back into slapd.conf and reconverted to slapd.d now I have three more questions about cn=monitor: Question 2: The log section in the 2.4 manual (18.4.5) has a slightly bizarre explanation suggesting that the log values are controlled via the description attribute. Whereas the description attribute under cn=log,cn=monitor suggests that they are controlled via managedInfo attributes which seems more sensible. Perhaps someone could confirm. Question 3: I have a olcLogLevel attribute of any (-1) visible through cn=config but was surprised this was not used to initialize the log settings of cn=log,cn=monitor. I added a managedInfo attribute under cn=log,cn=monitor (for ACL) which did precisely zilch (it did not add a logging object which I would have expected). Further after a stop/start the managedInfo attribute had disappeared from cn=log,cn=monitor. Question 4: Where is/are the schema/objectclasses for cn=monitor stored! I tried to get them using cn=subschema,cn=monitor - nada. Thanks in advance for any help
Ron Aitchison wrote:
I'm using 2.4.7 on Freebsd (5.4 and 6.2) and have a couple of questions:
two couples, I'd say ;)
I had a couple of nasty signal 11 crashes trying to start cn=monitor using cn=config
I suggest you file an ITS http://www.openldap.org/its/ for this, with steps to reproduce consistently from a simple configuration.
(OK - a tad ambitious) which obviously lost all my configuration changes: Question 1: Is there anyway I can force or control an update to the cn=config LDIF files in slapd.d To get cn=monitor running I finally dropped back into slapd.conf and reconverted to slapd.d now I have three more questions about cn=monitor:
Not sure what you mean there. If you know what you're doing, you could even populate the cn=config tree by hand, by adding the appropriate directory tree and LDIF files. Of course, this is not recommended (nor documented). So you should use regular LDAP write operations, and if they don't work, or crash the server, notify it (by way of the ITS) so that they can be (hopefully) fixed.
Question 2: The log section in the 2.4 manual (18.4.5) has a slightly bizarre explanation suggesting that the log values are controlled via the description attribute.
Incorrect (you could file an ITS for the documentation as well)
Whereas the description attribute under cn=log,cn=monitor suggests that they are controlled via managedInfo attributes which seems more sensible. Perhaps someone could confirm.
Correct.
Question 3: I have a olcLogLevel attribute of any (-1) visible through cn=config but was surprised this was not used to initialize the log settings of cn=log,cn=monitor.
cn=monitor presents whatever value of loglevel was set at startup time - by startup I mean startup of the monitor database. Subsequently, if you modify cn=config or cn=monitor, the managedInfo attribute should reflect it. Your message seems to indicate there's a mishandling of modifications. If you could clarify it a little bit further, it could be investigated and fixed, if a fix is needed.
I added a managedInfo attribute under cn=log,cn=monitor (for ACL) which did precisely zilch (it did not add a logging object which I would have expected). Further after a stop/start the managedInfo attribute had disappeared from cn=log,cn=monitor.
You can't fall back to slapd.conf __and__ preserve cn=config stuff. Either you fall back to slapd.conf, you need to generate a new cn=config, losing any modifications. Or, slapd.conf is ignored.
Question 4: Where is/are the schema/objectclasses for cn=monitor stored! I tried to get them using cn=subschema,cn=monitor - nada.
cn=subschema, like all OpenLDAP's slapd schema.
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: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo: Thanks for the quick and helpful response - couple of follow ups - I've deleted a number of items that you have covered perfectly.
Pierangelo Masarati wrote:
Ron Aitchison wrote:
I'm using 2.4.7 on Freebsd (5.4 and 6.2) and have a couple of questions:
two couples, I'd say ;)
Ok so I snuck a couple of extra ones in! Thanks for your patience.
I had a couple of nasty signal 11 crashes trying to start cn=monitor using cn=config
I suggest you file an ITS http://www.openldap.org/its/ for this, with steps to reproduce consistently from a simple configuration.
Will try and reproduce consistently and file its if I can - but I suspect it could have been me since it was tad ambitious as a starting point. Still one could argue that even my screw-ups should not cause a signal 11?
Question 1: Is there anyway I can force or control an update to the cn=config LDIF files in slapd.d
This caused me some problems and seems to be a potential weakness of cn=config. If I am changing the run-time configuration and slapd ever crashes all the modifications will be lost unless I can force an on-disc update - by writing to some dummy attribute - or by some kind of periodic on-disc write update timer (a checkpoint)?
To get cn=monitor running I finally dropped back into slapd.conf and reconverted to slapd.d now I have three more questions about cn=monitor:
I did not explain well - I deleted slapd.d, modified slapd.conf to add the database monitor service and then reconverted to use slapd.d - I wanted to see how the objects were initialised in cn=config because I thought I was doing something wrong in question 1 - I used the process as a diagnostic technique.
Question 2: The log section in the 2.4 manual (18.4.5) has a slightly bizarre explanation suggesting that the log values are controlled via the description attribute.
Incorrect (you could file an ITS for the documentation as well)
Will do
Question 3: I have a olcLogLevel attribute of any (-1) visible through cn=config but was surprised this was not used to initialize the log settings of cn=log,cn=monitor.
cn=monitor presents whatever value of loglevel was set at startup time - by startup I mean startup of the monitor database. Subsequently, if you modify cn=config or cn=monitor, the managedInfo attribute should reflect it. Your message seems to indicate there's a mishandling of modifications. If you could clarify it a little bit further, it could be investigated and fixed, if a fix is needed.
Will do some more work and file an its if I think there is a problem
You can't fall back to slapd.conf __and__ preserve cn=config stuff. Either you fall back to slapd.conf, you need to generate a new cn=config, losing any modifications. Or, slapd.conf is ignored.
Understand absolutely your point - see my previous note - but at this stage I was back using full cn=config slapd.d features when I added the managedInfo - stopped and started under slapd.d and still it lost the maangedInfo - will reproduce a couple of times and file an its if consistent. I'll also add a log extract to confirm the slapd.d startup/shutdown.
Question 4: Where is/are the schema/objectclasses for cn=monitor stored! I tried to get them using cn=subschema,cn=monitor - nada.
cn=subschema, like all OpenLDAP's slapd schema.
tried there also - no monitorXXX object classes at all. Found a README file in source under servers/slap/back-monitor which suggested some strange use of object classes so am going to poke around the source and see what I can find - any pointer would be appreciated.
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: pierangelo.masarati@sys-net.it
Ron Aitchison wrote:
Pierangelo: Thanks for the quick and helpful response - couple of follow ups - I've deleted a number of items that you have covered perfectly.
Pierangelo Masarati wrote:
Ron Aitchison wrote:
I'm using 2.4.7 on Freebsd (5.4 and 6.2) and have a couple of questions:
two couples, I'd say ;)
Ok so I snuck a couple of extra ones in! Thanks for your patience.
I had a couple of nasty signal 11 crashes trying to start cn=monitor using cn=config
I suggest you file an ITS http://www.openldap.org/its/ for this, with steps to reproduce consistently from a simple configuration.
Will try and reproduce consistently and file its if I can - but I suspect it could have been me since it was tad ambitious as a starting point. Still one could argue that even my screw-ups should not cause a signal 11?
Exactly.
Question 1: Is there anyway I can force or control an update to the cn=config LDIF files in slapd.d
This caused me some problems and seems to be a potential weakness of cn=config. If I am changing the run-time configuration and slapd ever crashes all the modifications will be lost unless I can force an on-disc update - by writing to some dummy attribute - or by some kind of periodic on-disc write update timer (a checkpoint)?
All writes are atomic (I mean: if a write operation succeeds, it will write on disk). SO you'll only lose the change you were trying to perform. (unless slapd's crash interferes with the os/fs write caching or so, which I doubt.
To get cn=monitor running I finally dropped back into slapd.conf and reconverted to slapd.d now I have three more questions about cn=monitor:
I did not explain well - I deleted slapd.d, modified slapd.conf to add the database monitor service and then reconverted to use slapd.d - I wanted to see how the objects were initialised in cn=config because I thought I was doing something wrong in question 1 - I used the process as a diagnostic technique.
OK.
Question 2: The log section in the 2.4 manual (18.4.5) has a slightly bizarre explanation suggesting that the log values are controlled via the description attribute.
Incorrect (you could file an ITS for the documentation as well)
Will do
Question 3: I have a olcLogLevel attribute of any (-1) visible through cn=config but was surprised this was not used to initialize the log settings of cn=log,cn=monitor.
cn=monitor presents whatever value of loglevel was set at startup time - by startup I mean startup of the monitor database. Subsequently, if you modify cn=config or cn=monitor, the managedInfo attribute should reflect it. Your message seems to indicate there's a mishandling of modifications. If you could clarify it a little bit further, it could be investigated and fixed, if a fix is needed.
Will do some more work and file an its if I think there is a problem
My point is that there might well be some problem there, since back-monitor came before back-config (otherwise back-monitor would probably have done well without update capabilities, at least in areas now covered by back-config). Sometimes, those issues, if any, don't show up immediately, but rather when users try to do something uncommon, either on purpose or by chance. That's why I ask you to explain the best you can what inconsistency you see and what operation triggered that inconsistency (if there's any inconsistency at all, we'll judge that later).
You can't fall back to slapd.conf __and__ preserve cn=config stuff. Either you fall back to slapd.conf, you need to generate a new cn=config, losing any modifications. Or, slapd.conf is ignored.
Understand absolutely your point - see my previous note - but at this stage I was back using full cn=config slapd.d features when I added the managedInfo - stopped and started under slapd.d and still it lost the maangedInfo - will reproduce a couple of times and file an its if consistent. I'll also add a log extract to confirm the slapd.d startup/shutdown.
OK, that's intended. When back-config came in, we decided to let back-monitor updated capabilities in place, with the understanding that back-config was intended for __permanent__ configuration changes, while back-monitor was intended for __temporary__ configuration changes. This is exactly the case: you should use back-monitor to temporarily raise the log level without changing the configuration. This will be lost if you restart slapd. The (subtle) reason is that a modification via back-config requires all other operations to be temporarily suspended, and cannot start until all active operations are concluded. This could cause some slowdown of the service, which is completely justified when, say, adding a database or changing access policies, but not when raising the log level :).
Question 4: Where is/are the schema/objectclasses for cn=monitor stored! I tried to get them using cn=subschema,cn=monitor - nada.
cn=subschema, like all OpenLDAP's slapd schema.
tried there also - no monitorXXX object classes at all. Found a README file in source under servers/slap/back-monitor which suggested some strange use of object classes so am going to poke around the source and see what I can find - any pointer would be appreciated.
Well, monitor schema is schema like any other. Since slapd puts all of its schema in there, it should be there:
bash-3.00$ ldapsearch -x -H ldap://:9011 -b cn=subschema -s base objectclasses attributetypes | grep -i monitor attributeTypes: ( 1.3.6.1.4.1.4203.666.1.10 NAME 'monitorContext' DESC 'monito attributeTypes: ( 1.3.6.1.4.1.4203.666.11.1.3.2.0.18 NAME 'olcMonitoring' SYNT attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.1 NAME 'monitoredInfo' DESC 'monit attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.2 NAME 'managedInfo' DESC 'monitor attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.3 NAME 'monitorCounter' DESC 'moni attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.4 NAME 'monitorOpCompleted' DESC ' monitor completed operations' SUP monitorCounter NO-USER-MODIFICATION USAGE d attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.5 NAME 'monitorOpInitiated' DESC ' monitor initiated operations' SUP monitorCounter NO-USER-MODIFICATION USAGE d attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.6 NAME 'monitorConnectionNumber' D ESC 'monitor connection number' SUP monitorCounter NO-USER-MODIFICATION USAGE attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.7 NAME 'monitorConnectionAuthzDN' DESC 'monitor connection authorization DN' EQUALITY distinguishedNameMatch SY attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.8 NAME 'monitorConnectionLocalAddr ess' DESC 'monitor connection local address' SUP monitoredInfo NO-USER-MODIFI attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.9 NAME 'monitorConnectionPeerAddre ss' DESC 'monitor connection peer address' SUP monitoredInfo NO-USER-MODIFICA attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.10 NAME 'monitorTimestamp' DESC 'm attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.11 NAME 'monitorOverlay' DESC 'nam e of overlays defined for a given database' SUP monitoredInfo NO-USER-MODIFIC attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.14 NAME 'monitorConnectionProtocol ' DESC 'monitor connection protocol' SUP monitoredInfo NO-USER-MODIFICATION U attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.15 NAME 'monitorConnectionOpsRecei ved' DESC 'monitor number of operations received by the connection' SUP monit attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.16 NAME 'monitorConnectionOpsExecu ting' DESC 'monitor number of operations in execution within the connection' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.17 NAME 'monitorConnectionOpsPendi ng' DESC 'monitor number of pending operations within the connection' SUP mon attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.18 NAME 'monitorConnectionOpsCompl eted' DESC 'monitor number of operations completed within the connection' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.19 NAME 'monitorConnectionGet' DES C 'number of times connection_get() was called so far' SUP monitorCounter NO- attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.20 NAME 'monitorConnectionRead' DE SC 'number of times connection_read() was called so far' SUP monitorCounter N attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.21 NAME 'monitorConnectionWrite' D ESC 'number of times connection_write() was called so far' SUP monitorCounter attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.22 NAME 'monitorConnectionMask' DE SC 'monitor connection mask' SUP monitoredInfo NO-USER-MODIFICATION USAGE dSA attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.23 NAME 'monitorConnectionListener ' DESC 'monitor connection listener' SUP monitoredInfo NO-USER-MODIFICATION U attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.24 NAME 'monitorConnectionPeerDoma in' DESC 'monitor connection peer domain' SUP monitoredInfo NO-USER-MODIFICAT attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.25 NAME 'monitorConnectionStartTim e' DESC 'monitor connection start time' SUP monitorTimestamp SINGLE-VALUE NO- attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.26 NAME 'monitorConnectionActivity Time' DESC 'monitor connection activity time' SUP monitorTimestamp SINGLE-VAL attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.27 NAME 'monitorIsShadow' DESC 'TR attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.28 NAME 'monitorUpdateRef' DESC 'u pdate referral for shadow databases' SUP monitoredInfo SINGLE-VALUE USAGE dSA attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.29 NAME 'monitorRuntimeConfig' DES SC 'Number of items in Entry Cache' SUP monitorCounter NO-USER-MODIFICATION U 'Number of items in DN Cache' SUP monitorCounter NO-USER-MODIFICATION USAGE d 'Number of items in IDL Cache' SUP monitorCounter NO-USER-MODIFICATION USAGE SC 'Missing indexes resulting from candidate selection' SUP monitoredInfo NO- rrorMode $ olcMonitoring ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.1 NAME 'monitor' DESC 'OpenLDAP sys tem monitoring' SUP top STRUCTURAL MUST cn MAY ( description $ seeAlso $ labe ledURI $ monitoredInfo $ managedInfo $ monitorOverlay ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.2 NAME 'monitorServer' DESC 'Server monitoring root entry' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.3 NAME 'monitorContainer' DESC 'mon itor container class' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.4 NAME 'monitorCounterObject' DESC 'monitor counter class' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.5 NAME 'monitorOperation' DESC 'mon itor operation class' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.6 NAME 'monitorConnection' DESC 'mo nitor connection class' SUP monitor STRUCTURAL ) r managed entity class' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.8 NAME 'monitoredObject' DESC 'moni tor monitored entity class' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.4.1 NAME 'olcMonitorConfig' DES C 'Monitor backend configuration' SUP olcDatabaseConfig STRUCTURAL )
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: pierangelo.masarati@sys-net.it ---------------------------------------
See notes below - deleted all completed points to keep mail size down
Pierangelo Masarati wrote:
Question 3: I have a olcLogLevel attribute of any (-1) visible through cn=config but was surprised this was not used to initialize the log settings of cn=log,cn=monitor.
cn=monitor presents whatever value of loglevel was set at startup time - by startup I mean startup of the monitor database. Subsequently, if you modify cn=config or cn=monitor, the managedInfo attribute should reflect it. Your message seems to indicate there's a mishandling of modifications. If you could clarify it a little bit further, it could be investigated and fixed, if a fix is needed.
Will do some more work and file an its if I think there is a problem
My point is that there might well be some problem there, since back-monitor came before back-config (otherwise back-monitor would probably have done well without update capabilities, at least in areas now covered by back-config). Sometimes, those issues, if any, don't show up immediately, but rather when users try to do something uncommon, either on purpose or by chance. That's why I ask you to explain the best you can what inconsistency you see and what operation triggered that inconsistency (if there's any inconsistency at all, we'll judge that later).
subtle but understandable - as a passing note for the future there does seem to be some merit in combining monitor and config into a single capability - ah if there was only enough time
Question 4: Where is/are the schema/objectclasses for cn=monitor stored! I tried to get them using cn=subschema,cn=monitor - nada.
cn=subschema, like all OpenLDAP's slapd schema.
tried there also - no monitorXXX object classes at all. Found a README file in source under servers/slap/back-monitor which suggested some strange use of object classes so am going to poke around the source and see what I can find - any pointer would be appreciated.
Well, monitor schema is schema like any other. Since slapd puts all of its schema in there, it should be there:
tried command exactly as you stated - no objectclasses or attributetypes for 'monitor' - did the same with + - can send full list if required - I could not see any relevant schema - the original slapd.conf had includes for core, cosine and inetorgperson only- but I'm on cn=config though I can't see what difference that would make? Am I missing an include?
bash-3.00$ ldapsearch -x -H ldap://:9011 -b cn=subschema -s base objectclasses attributetypes | grep -i monitor attributeTypes: ( 1.3.6.1.4.1.4203.666.1.10 NAME 'monitorContext' DESC 'monito attributeTypes: ( 1.3.6.1.4.1.4203.666.11.1.3.2.0.18 NAME 'olcMonitoring' SYNT attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.1 NAME 'monitoredInfo' DESC 'monit attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.2 NAME 'managedInfo' DESC 'monitor attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.3 NAME 'monitorCounter' DESC 'moni attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.4 NAME 'monitorOpCompleted' DESC ' monitor completed operations' SUP monitorCounter NO-USER-MODIFICATION USAGE d attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.5 NAME 'monitorOpInitiated' DESC ' monitor initiated operations' SUP monitorCounter NO-USER-MODIFICATION USAGE d attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.6 NAME 'monitorConnectionNumber' D ESC 'monitor connection number' SUP monitorCounter NO-USER-MODIFICATION USAGE attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.7 NAME 'monitorConnectionAuthzDN' DESC 'monitor connection authorization DN' EQUALITY distinguishedNameMatch SY attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.8 NAME 'monitorConnectionLocalAddr ess' DESC 'monitor connection local address' SUP monitoredInfo NO-USER-MODIFI attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.9 NAME 'monitorConnectionPeerAddre ss' DESC 'monitor connection peer address' SUP monitoredInfo NO-USER-MODIFICA attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.10 NAME 'monitorTimestamp' DESC 'm attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.11 NAME 'monitorOverlay' DESC 'nam e of overlays defined for a given database' SUP monitoredInfo NO-USER-MODIFIC attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.14 NAME 'monitorConnectionProtocol ' DESC 'monitor connection protocol' SUP monitoredInfo NO-USER-MODIFICATION U attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.15 NAME 'monitorConnectionOpsRecei ved' DESC 'monitor number of operations received by the connection' SUP monit attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.16 NAME 'monitorConnectionOpsExecu ting' DESC 'monitor number of operations in execution within the connection' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.17 NAME 'monitorConnectionOpsPendi ng' DESC 'monitor number of pending operations within the connection' SUP mon attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.18 NAME 'monitorConnectionOpsCompl eted' DESC 'monitor number of operations completed within the connection' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.19 NAME 'monitorConnectionGet' DES C 'number of times connection_get() was called so far' SUP monitorCounter NO- attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.20 NAME 'monitorConnectionRead' DE SC 'number of times connection_read() was called so far' SUP monitorCounter N attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.21 NAME 'monitorConnectionWrite' D ESC 'number of times connection_write() was called so far' SUP monitorCounter attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.22 NAME 'monitorConnectionMask' DE SC 'monitor connection mask' SUP monitoredInfo NO-USER-MODIFICATION USAGE dSA attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.23 NAME 'monitorConnectionListener ' DESC 'monitor connection listener' SUP monitoredInfo NO-USER-MODIFICATION U attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.24 NAME 'monitorConnectionPeerDoma in' DESC 'monitor connection peer domain' SUP monitoredInfo NO-USER-MODIFICAT attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.25 NAME 'monitorConnectionStartTim e' DESC 'monitor connection start time' SUP monitorTimestamp SINGLE-VALUE NO- attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.26 NAME 'monitorConnectionActivity Time' DESC 'monitor connection activity time' SUP monitorTimestamp SINGLE-VAL attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.27 NAME 'monitorIsShadow' DESC 'TR attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.28 NAME 'monitorUpdateRef' DESC 'u pdate referral for shadow databases' SUP monitoredInfo SINGLE-VALUE USAGE dSA attributeTypes: ( 1.3.6.1.4.1.4203.666.1.55.29 NAME 'monitorRuntimeConfig' DES SC 'Number of items in Entry Cache' SUP monitorCounter NO-USER-MODIFICATION U 'Number of items in DN Cache' SUP monitorCounter NO-USER-MODIFICATION USAGE d 'Number of items in IDL Cache' SUP monitorCounter NO-USER-MODIFICATION USAGE SC 'Missing indexes resulting from candidate selection' SUP monitoredInfo NO- rrorMode $ olcMonitoring ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.1 NAME 'monitor' DESC 'OpenLDAP sys tem monitoring' SUP top STRUCTURAL MUST cn MAY ( description $ seeAlso $ labe ledURI $ monitoredInfo $ managedInfo $ monitorOverlay ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.2 NAME 'monitorServer' DESC 'Server monitoring root entry' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.3 NAME 'monitorContainer' DESC 'mon itor container class' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.4 NAME 'monitorCounterObject' DESC 'monitor counter class' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.5 NAME 'monitorOperation' DESC 'mon itor operation class' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.6 NAME 'monitorConnection' DESC 'mo nitor connection class' SUP monitor STRUCTURAL ) r managed entity class' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.3.16.8 NAME 'monitoredObject' DESC 'moni tor monitored entity class' SUP monitor STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.4.1 NAME 'olcMonitorConfig' DES C 'Monitor backend configuration' SUP olcDatabaseConfig STRUCTURAL )
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: pierangelo.masarati@sys-net.it
Ron Aitchison wrote:
My point is that there might well be some problem there, since back-monitor came before back-config (otherwise back-monitor would probably have done well without update capabilities, at least in areas now covered by back-config). Sometimes, those issues, if any, don't show up immediately, but rather when users try to do something uncommon, either on purpose or by chance. That's why I ask you to explain the best you can what inconsistency you see and what operation triggered that inconsistency (if there's any inconsistency at all, we'll judge that later).
subtle but understandable - as a passing note for the future there does seem to be some merit in combining monitor and config into a single capability - ah if there was only enough time
Well, an important reason for keeping them separate is that working with monitor does not impact other operations, while working with config in most cases requires other operations to be idle.
Well, monitor schema is schema like any other. Since slapd puts all of its schema in there, it should be there:
tried command exactly as you stated - no objectclasses or attributetypes for 'monitor' - did the same with + - can send full list if required - I could not see any relevant schema - the original slapd.conf had includes for core, cosine and inetorgperson only- but I'm on cn=config though I can't see what difference that would make? Am I missing an include?
That schema is hardcoded in back-monitor code (it is registered run-time when the monitor backend is initialized). If you don't see it, probably you're not loading the back_monitor module or something like that.
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: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Well, monitor schema is schema like any other. Since slapd puts all of its schema in there, it should be there:
tried command exactly as you stated - no objectclasses or attributetypes for 'monitor' - did the same with + - can send full list if required - I could not see any relevant schema - the original slapd.conf had includes for core, cosine and inetorgperson only- but I'm on cn=config though I can't see what difference that would make? Am I missing an include?
That schema is hardcoded in back-monitor code (it is registered run-time when the monitor backend is initialized). If you don't see it, probably you're not loading the back_monitor module or something like that.
I had a loadmodule back_monitor.la in slapd.conf it was converted to olcModuleLoad {1)monitor_back.la - tried changing from .la to .so for all overlays - no effect (OK I tried) included relevant log extract below: Feb 4 15:30:38 host1 slapd[84777]: @(#) $OpenLDAP: slapd 2.4.7 (Jan 25 2008 03:03:41) $ ron@host1.zytrax.com:/usr/ports/net/openldap24-server/work/openldap-2.4.7/servers/slapd Feb 4 15:30:38 host1 slapd[84777]: => str2entry: "dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_bdb.so olcModuleLoad: {1}back_monitor.so olcModuleLoad: {2}back_meta.so structuralObjectClass: olcModuleList entryUUID: 7d0c2126-6638-102c-8fa3-3be499f3820c creatorsName: cn=config createTimestamp: 20080203001245Z entryCSN: 20080203043824.585318Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20080203043824Z " ...... Feb 4 15:30:38 host1 slapd[84777]: loaded module back_bdb.so Feb 4 15:30:38 host1 slapd[84777]: bdb_back_initialize: initialize BDB backend Feb 4 15:30:38 host1 slapd[84777]: bdb_back_initialize: Berkeley DB 4.6.19: (August 10, 2007) Feb 4 15:30:38 host1 slapd[84777]: module back_bdb.so: null module registered Feb 4 15:30:38 host1 slapd[84777]: loaded module back_monitor.so Feb 4 15:30:38 host1 slapd[84777]: module back_monitor.so: null module registered Feb 4 15:30:38 host1 slapd[84777]: loaded module back_meta.so Feb 4 15:30:38 host1 slapd[84777]: module back_meta.so: null module registered .... Feb 4 15:30:38 host1 slapd[84777]: => str2entry: "dn: olcDatabase={2}monitor objectClass: olcDatabaseConfig olcDatabase: {2}monitor olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,cn=monitor olcRootPW:: c2VjcmV0 structuralObjectClass: olcDatabaseConfig entryUUID: 7d236bd8-6638-102c-8fab-3be499f3820c creatorsName: cn=config createTimestamp: 20080203001245Z olcMonitoring: TRUE entryCSN: 20080203021339.946650Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20080203021339Z " Feb 4 15:30:38 host1 slapd[84777]: >>> dnPrettyNormal: <olcDatabase={2}monitor> Feb 4 15:30:38 host1 slapd[84777]: <<< dnPrettyNormal: <olcDatabase={2}monitor>, <olcDatabase={2}monitor> Feb 4 15:30:38 host1 slapd[84777]: >>> dnNormalize: <cn=config> Feb 4 15:30:38 host1 slapd[84777]: <<< dnNormalize: <cn=config> Feb 4 15:30:38 host1 slapd[84777]: >>> dnNormalize: <cn=admin,cn=config> Feb 4 15:30:38 host1 slapd[84777]: <<< dnNormalize: <cn=admin,cn=config> Feb 4 15:30:38 host1 slapd[84777]: <= str2entry(olcDatabase={2}monitor) -> 0x82e1054 Feb 4 15:30:38 host1 slapd[84777]: => test_filter Feb 4 15:30:38 host1 slapd[84777]: PRESENT Feb 4 15:30:38 host1 slapd[84777]: => access_allowed: search access to "olcDatabase={2}monitor,cn=config" "objectClass" requested Feb 4 15:30:38 host1 slapd[84777]: <= root access granted Feb 4 15:30:38 host1 slapd[84777]: => access_allowed: search access granted by manage(=mwrscxd) Feb 4 15:30:38 host1 slapd[84777]: <= test_filter 6 Feb 4 15:30:38 host1 slapd[84777]: >>> dnPrettyNormal: <cn=admin,cn=monitor> Feb 4 15:30:38 host1 slapd[84777]: <<< dnPrettyNormal: <cn=admin,cn=monitor>, <cn=admin,cn=monitor> Feb 4 15:30:38 host1 slapd[84777]: >>> dnPrettyNormal: <cn=Monitor> Feb 4 15:30:38 host1 slapd[84777]: <<< dnPrettyNormal: <cn=Monitor>, <cn=monitor> Feb 4 15:30:38 host1 slapd[84777]: >>> dnPrettyNormal: <cn=admin,cn=monitor> Feb 4 15:30:38 host1 slapd[84777]: <<< dnPrettyNormal: <cn=admin,cn=monitor>, <cn=admin,cn=monitor> Feb 4 15:30:38 host1 slapd[84777]: send_ldap_result: conn=-1 op=0 p=0 Feb 4 15:30:38 host1 slapd[84777]: send_ldap_result: err=0 matched="" text="" Feb 4 15:30:38 host1 slapd[84777]: matching_rule_use_init ....... Feb 4 15:30:39 host1 slapd[84778]: slapd startup: initiated. Feb 4 15:30:39 host1 slapd[84778]: backend_startup_one: starting "cn=config" Feb 4 15:30:39 host1 slapd[84778]: config_back_db_open Feb 4 15:30:39 host1 slapd[84778]: backend_startup_one: starting "dc=example,dc=com" Feb 4 15:30:39 host1 slapd[84778]: bdb_db_open: "dc=example,dc=com" Feb 4 15:30:39 host1 slapd[84778]: bdb_db_open: database "dc=example,dc=com": dbenv_open(/var/db/openldap/example-com). Feb 4 15:30:39 host1 slapd[84778]: backend_startup_one: starting "cn=Monitor" Feb 4 15:30:39 host1 slapd[84778]: >>> dnNormalize: <cn=Monitor> Feb 4 15:30:39 host1 slapd[84778]: <<< dnNormalize: <cn=monitor> ......
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: pierangelo.masarati@sys-net.it
openldap-software@openldap.org
-
Pierangelo Masarati -
Ron Aitchison