On 9 mai 09, at 08:06, Howard Chu wrote:
Thierry Lacoste wrote:
Hello,
I have recently upgraded from 2.3.24 to 2.4.16. I find two points confusing in the "Monitor Backend" section of the B annex "Upgrading from 2.3.x" in the admin guide (http://www.openldap.org/doc/admin24/appendix-upgrading.html#Monitor%20Backen... ).
First my slapd happily starts even when I have no rootdn in my "database monitor" section.
The admin guide says: A monitor (slapd-monitor(5)) now needs a rootdn entry. If you do not have one, slapd will fail to start up with an error message like so:
monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one
filter="(namingContexts:distinguishedNameMatch:=dc=example,dc=com)": unable to find entry backend_startup_one: bi_db_open failed! (1) slap_startup failed (test would succeed using the -u switch)
Am I the only one to not experience this? Or is it going to happen somewhere in the 2.4 series?
Second the example of the admin guide reads: database monitor rootdn cn=monitor rootpw change_me
Is it on purpose that the rootdn equals the hadcoded suffix of the monitor database?
Yes.
In the "Monitor" section of the admin guide, the example reads: database monitor rootdn "cn=monitoring,cn=Monitor" rootpw monitoring
The choice of the rootdn seems much more intuitive
Seems less intuitive to me... "root" means the base / origin / trunk / whatever. Calling something that is clearly *below* the root the "rootdn" is nonsensical. The fact that it's been standard practice for others says to me that those other folks' brains were muddled when they defined all these things.
So I guess you would say the same thing about this example which is quite ubiquitous: suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com"
but then it seems a bit weird to not use it in the ACL below:
You seem to have forgotten that the current database's rootdn always ignores all ACLs on that database. The purpose of this ACL is to allow the "uid=Admin" identity that resides in some *other* database to have privileges in this database.
access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,dc=my,dc=org" write by users read by * none
Thanks a lot.
Thierry.