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.
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 but then it seems a bit weird to not use it in the ACL below: access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,dc=my,dc=org" write by users read by * none
Can someone please post his monitor configuration?
Regards, Thierry
I have two independent servers, with both variations, both work.
---- moduleload back_bdb moduleload back_monitor
backend bdb database bdb suffix "dc=xyz" directory "/var/lib/ldap" rootdn "cn=Directory Manager,dc=xyz"
database monitor rootdn "cn=Administrator,cn=Monitor" rootpw foobar --------
-------- moduleload back_bdb moduleload back_monitor
backend bdb database bdb suffix "dc=abc" rootdn "cn=Directory Manager,dc=abc" directory "/var/lib/ldap"
database monitor rootdn "cn=Directory Manager,dc=abc" -----------
Note I didn't specify suffix for monitor database. In 2nd case, credentials for monitor rootdn are taken from other db.
P.
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.
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.
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
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.
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...)
On 9 mai 09, at 10:47, Howard Chu wrote:
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.
Well I restrict acces and I have no rootdn and slapd works like a charm.
database monitor access to dn.subtree="cn=monitor" by dn.exact="the_rootdn_of_my_main_database" write by * none
This ACL is working as expected.
I have nothing else in my slapd.conf regarding monitor (except "moduleload back_monitor").
FWIW this is slapd 2.4.16 on FreeBSD 6.4.
Regards, Thierry
Thierry Lacoste wrote:
On 9 mai 09, at 10:47, Howard Chu wrote:
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.
Well I restrict acces and I have no rootdn and slapd works like a charm.
My mistake. That note was added to the Guide on September 3 2007. A few days after that I wrote a fix for this behavior and it was committed on September 15 2007. I guess we can remove that note...
Will do.
On 09/05/2009, Howard Chu hyc@symas.com wrote:
Thierry Lacoste wrote:
On 9 mai 09, at 10:47, Howard Chu wrote:
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.
Well I restrict acces and I have no rootdn and slapd works like a charm.
My mistake. That note was added to the Guide on September 3 2007. A few days after that I wrote a fix for this behavior and it was committed on September 15 2007. I guess we can remove that note...
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
openldap-software@openldap.org
-
Gavin Henry -
Howard Chu -
Piotr Wadas -
Thierry Lacoste