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: [EMAIL PROTECTED]
---------------------------------------
--
Ron Aitchison www.zytrax.com
ZYTRAX [EMAIL PROTECTED]
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
