Thierry Lacoste wrote:
On 9 mai 09, at 08:06, Howard Chu wrote:
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?
If your default ACL allows general read access to cn=monitor, then you won't see any problems. If you define ACLs to restrict access to cn=monitor, then you'll need to define a rootdn.
Actually, I'm pretty sure this has been true since at least 2004.
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"
Yes. Just because it's ubiquitous doesn't mean it's right. The main reason we still have so much work to do in the OpenLDAP Project is because so much of the work in LDAP that came before us was wrongheaded to begin with. (E.g., everywhere it intentionally diverged from X.500, for starters...)