Re: Questions about the Monitor Backend

[Thierry Lacoste <lacoste@miage.univ-paris12.fr>]

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%20Backend
> > ).
> >
> > 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.