[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Questions about the Monitor Backend

On 9 mai 09, at 08:06, Howard Chu wrote:

Thierry Lacoste wrote:

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

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?


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.