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