[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: cn=config and cn=monitor questions

To: Ron Aitchison <ron@zytrax.com>
Subject: Re: cn=config and cn=monitor questions
From: Pierangelo Masarati <ando@sys-net.it>
Date: Mon, 04 Feb 2008 09:43:52 +0100
Cc: openldap-software@openldap.org
In-reply-to: <47A6659D.5040009@zytrax.com>
References: <47A5731C.3090303@zytrax.com> <47A61CDB.1040407@sys-net.it> <47A6659D.5040009@zytrax.com>
User-agent: Mail/News 1.5.0.8 (X11/20061210)
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
---------------------------------------
Follow-Ups:
- Re: cn=config and cn=monitor questions
  - From: Ron Aitchison <ron@zytrax.com>
References:
- cn=config and cn=monitor questions
  - From: Ron Aitchison <ron@zytrax.com>
- Re: cn=config and cn=monitor questions
  - From: Pierangelo Masarati <ando@sys-net.it>
- Re: cn=config and cn=monitor questions
  - From: Ron Aitchison <ron@zytrax.com>
Prev by Date: ACL or a default deny policy
Next by Date: Re: cn=config and cn=monitor questions
Index(es):
- Chronological
- Thread