Ron Aitchison wrote:Ok so I snuck a couple of extra ones in! Thanks for your patience.
I'm using 2.4.7 on Freebsd (5.4 and 6.2) and have a couple of questions:
two couples, I'd say ;)
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?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.
Question 1: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)?
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 andI 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.
reconverted to slapd.d now I have three more questions about cn=monitor:
Will doQuestion 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 some more work and file an its if I think there is a problemQuestion 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.
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.
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.
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.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 ---------------------------------------
-- 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