[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: cn=config and cn=monitor questions

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=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.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it

-- Ron Aitchison www.zytrax.com ZYTRAX ron@zytrax.com tel: 514-315-4296 Suite 22 6201 Chemin Cote St. Luc Hampstead QC H3X 2H2 Canada Author: Pro DNS and BIND (Apress) ISBN 1-59059-494-0