Hi all,
I'm currently in the process of migrating LDAP data from a really outdated system to something a bit fresher. So, I started with the OpenLDAP as provided by Debian, and learned that a good part of the system management knowledge I had is outdated. So, I stared reading TFM.
... and stumbled over the section where I wanted to learn how to set up monitoring with the cn=config configuration scheme.
Naturally, that was exactly the incentive I needed to actually start giving back something to the community. So, I ended up playing around a bit and googling a bit and scratching my head a lot, taking notes, and came up with something you might want to add into the manual -- see below.
Unfortunately, the whole thing did not exactly work out as I intended, because the crucial step insists on failing. Namely, trying to create a monitor database fails, indicating there already is one in existence. However, I can't find any such beast:
root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(|(olcDatabase=monitor)(objectClass=olcMonitorConfig))' root@host:~/ldap#
I have actually tried to add the above data using slapadd, with slapd shut down, and got an even more confusing error message: root@host:~/ldap# slapadd -n 0 -l addMonitorDB.ldif slapadd: could not add entry dn="olcDatabase=Monitor,cn=config" (line=1): autocreation of "olcDatabase={-1}frontend" failed _######### 46.91% eta none elapsed none spd 1.3 M/s Closing DB...
So, what do I need to do to get my manual suggestion into working condition? (And also allow me to monitor my all fresh LDAP instance :-)
Cheers,
Arno
-----8<--------------cut here... manual text below ------------->8------
20.1. Monitor configuration via cn=config(5)
To enable monitoring an OpenLDAP server, the "monitor" database needs to be available and configured, also allowing read acces to it.
20.1.1. Ensure the monitor backend is available
The first step is to ensure the monitor database is part of the running slapd process. As database backends can be build into the main binary, or loaded dynamically, as configured, the initial step is to check if the module is built in, is already loaded, or, if not, add it to the configuration.
20.1.2. Check the binary for built-in modules
By running
root@host:~/ldap# slapd -VVV @(#) $OpenLDAP: slapd (May 23 2018 04:25:19) $ Debian OpenLDAP Maintainers pkg-openldap-devel@lists.alioth.debian.org
Included static backends: config ldif root@host:~/ldap#
it is easy to check if the monitor backend database is built-in; in the above case, it is not. If it already is part of the slapd binary, the process goes to section 20.1.5 further below.
20.1.3. Check module loader configuration
*Note* that the below examples use one particular scheme to access LDAP with administrative, i.e. full, privileges; things may be configured differently in other environments. (The example is correct for a stock Debian 9 installation, by the way.)
Checking if the monitor backend is already configured to be loaded requires querying the LDAP configuration, in particular the module loader configuration:
root@host:~/ldap# ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(objectClass=olcModuleList)' olcModuleLoad SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=module{0},cn=config olcModuleLoad: {0}back_mdb olcModuleLoad: {1}back_monitor
root@host:~/ldap#
In this example, we see the back_monitor module to be loaded. If a line referencing this module was not shown, the next step is described below. Otherwise, proceed at section 20.1.5.
20.1.4. Add the monitor module to the module loader configuration
20.1.4.1. Verify the necessary module exists.
A careful administrator will ensure the needed module is actually available to be loaded. This is done by checking the needed file exists in the module loader's path.
We assume the path to be correctly set up in the loaders configuration in the first place, trusting that the package builder prepared this step. Thus:
root@host:~/ldap# ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(objectClass=olcModuleList)' olcModulePath SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=module{0},cn=config olcModulePath: /usr/lib/ldap
root@host:~/ldap# ls -l /usr/lib/ldap/*monitor* lrwxrwxrwx 1 root root 26 May 23 2018 /usr/lib/ldap/back_monitor-2.4.so.2 -> back_monitor-2.4.so.2.10.7 -rw-r--r-- 1 root root 109408 May 23 2018 /usr/lib/ldap/back_monitor-2.4.so.2.10.7 -rw-r--r-- 1 root root 976 May 23 2018 /usr/lib/ldap/back_monitor.la lrwxrwxrwx 1 root root 26 May 23 2018 /usr/lib/ldap/back_monitor.so -> back_monitor-2.4.so.2.10.7 root@host:~/ldap#
and voilà, things look good, the module shared object file is available, and things are prepared for different versions coexisting in the usual Unix/Linux way. (The author has no idea what to expect on a windows system.)
If things did *not* look good, it would be time to check the distribution repositories for packages with OpenLDAP modules, or verify the build and installation process, both of which is out of scope of this chapter.
20.1.4.2. Adding the monitor backend to the loader configuration
Assuming paths and binaries are all correct, it's now merely a matter of adding some attributes to the module loader's configuration. This can be done with just a few lines of LDIF:
root@host:~/ldap# cat loadMonitor.ldif dn: cn=config,cn=module changetype: modify add: olcModuleLoad olcModuleLoad: back_monitor
root@host:~/ldap# ldapmodify -H ldapi:/// -Y EXTERNAL -f loadMonitor.ldif
should do all that is necessary. Error messages hopefully provide an indication of what went wrong in case there is a problem.
20.1.5. Verifying the monitor backend needs to be configured
Of course, we start out being extra-careful, by checking that no monitor backend is already configured:
root@host:~/ldap# ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(objectClass=olcDataBaseConfig)' olcDatabase objectClass SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb
root@host:~/ldap#
Carefully checking the output, it becomes clear no monitor database is available as yet, so we need to continue.
20.1.6. Adding a "monitor" database Again, a simple LDAP add operation will be sufficient:
root@host:~/ldap# cat addMonitorDB.ldif dn: olcDatabase=monitor,cn=config objectClass: olcDatabaseConfig objectClass: olcMonitorConfig olcDatabase: monitor olcAccess: to dn.subtree=cn=monitor by users read
root@host:~/ldap#
Naturally, the ACL(s) may be adjusted as needed.
root@host:~/ldap# ldapadd -H ldapi:/// -Y EXTERNAL -f addMonitorDB.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase=monitor,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: only one monitor database allowed
(BETTER NOT PUBLISH THE FINAL TWO LINES...)
Arno Lehmann wrote:
Hi all,
I'm currently in the process of migrating LDAP data from a really outdated system to something a bit fresher. So, I started with the OpenLDAP as provided by Debian, and learned that a good part of the system management knowledge I had is outdated. So, I stared reading TFM.
... and stumbled over the section where I wanted to learn how to set up monitoring with the cn=config configuration scheme.
Naturally, that was exactly the incentive I needed to actually start giving back something to the community. So, I ended up playing around a bit and googling a bit and scratching my head a lot, taking notes, and came up with something you might want to add into the manual -- see below.
Unfortunately, the whole thing did not exactly work out as I intended, because the crucial step insists on failing. Namely, trying to create a monitor database fails, indicating there already is one in existence. However, I can't find any such beast:
root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(|(olcDatabase=monitor)(objectClass=olcMonitorConfig))' root@host:~/ldap#
Did you try searching to see if cn=monitor is actually there?
Hi Howard, all,
On 07.02.2019 at 03:31, Howard Chu wrote: ...>> Unfortunately, the whole thing did not exactly work out as I intended, because the crucial step insists on failing. Namely, trying to create a monitor database
fails, indicating there already is one in existence. However, I can't find any such beast:
root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(|(olcDatabase=monitor)(objectClass=olcMonitorConfig))' root@host:~/ldap#
Did you try searching to see if cn=monitor is actually there?
Yes, although I'm not exactly sure I have this sorted out correctly. What I did was for example this:
root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b '' -s base + '*' | grep -v supported dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=<redacted>,dc=de entryDN: subschemaSubentry: cn=Subschema
... which shows more or less what I would expect -- a naming context, configuration under cn=config, the subschemaSubentry, and nothing resembling monitoring stuff.
If there are other, possibly better ways to check, let me know - I'm quite aware I'm far from really understanding LDAP in general, and OpenLDAP in particular.
Thanks,
Arno
On 2/7/19 9:34 AM, Arno Lehmann wrote:
On 07.02.2019 at 03:31, Howard Chu wrote:
Did you try searching to see if cn=monitor is actually there?
Yes, although I'm not exactly sure I have this sorted out correctly. What I did was for example this:
root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b '' -s base + '*' | grep -v supported dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=<redacted>,dc=de entryDN: subschemaSubentry: cn=Subschema
To me it seems it is *not* there. The operational attribute 'monitorContext' contains the suffix of "database monitor".
So if back-monitor is correctly configured this query goes like this:
$ ldapsearch -H ldapi:/// -Y EXTERNAL -b '' -s base monitorContext dn: monitorContext: cn=Monitor
Ciao, Michael.
Hi Michael,
On 08.02.2019 at 20:29, Michael Ströder wrote:
On 2/7/19 9:34 AM, Arno Lehmann wrote:
On 07.02.2019 at 03:31, Howard Chu wrote:
Did you try searching to see if cn=monitor is actually there?
Yes, although I'm not exactly sure I have this sorted out correctly. What I did was for example this:
root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b '' -s base + '*' | grep -v supported dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=<redacted>,dc=de entryDN: subschemaSubentry: cn=Subschema
To me it seems it is *not* there. The operational attribute 'monitorContext' contains the suffix of "database monitor".
So if back-monitor is correctly configured this query goes like this:
So I guess I really did not add a monit database yet, which is exactly what I'd like to achieve.
Thanks for confirming.
In fact, I noticed that slapd, when started f.e. as slapcat, complains that no monitoring database is configured:
root@host:~/ldap# slapcat -n 1 >/dev/null 5c5e0a7d mdb_monitor_db_open: monitoring disabled; configure monitor database to enable
... but adding the monitor database was impossible.
Which is what I was trying to solve these days.
Thanks and cheers,
Arno
Arno Lehmann wrote:
Hi Michael,
On 08.02.2019 at 20:29, Michael Ströder wrote:
On 2/7/19 9:34 AM, Arno Lehmann wrote:
On 07.02.2019 at 03:31, Howard Chu wrote:
Did you try searching to see if cn=monitor is actually there?
Yes, although I'm not exactly sure I have this sorted out correctly. What I did was for example this:
root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b '' -s base + '*' | grep -v supported dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=<redacted>,dc=de entryDN: subschemaSubentry: cn=Subschema
To me it seems it is *not* there. The operational attribute 'monitorContext' contains the suffix of "database monitor".
So if back-monitor is correctly configured this query goes like this:
So I guess I really did not add a monit database yet, which is exactly what I'd like to achieve.
Thanks for confirming.
That is not a confirmation. Did you actually do an ldapsearch using a base of "cn=monitor" ?
It sounds to me like you manually added or deleted elements of your configuration while slapd was running, thus leaving things in a confused state.
On 09.02.2019 at 04:42, Howard Chu wrote:
Arno Lehmann wrote:
Hi Michael,
On 08.02.2019 at 20:29, Michael Ströder wrote:
On 2/7/19 9:34 AM, Arno Lehmann wrote:
On 07.02.2019 at 03:31, Howard Chu wrote:
Did you try searching to see if cn=monitor is actually there?
Yes, although I'm not exactly sure I have this sorted out correctly. What I did was for example this:
root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b '' -s base + '*' | grep -v supported dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=<redacted>,dc=de entryDN: subschemaSubentry: cn=Subschema
To me it seems it is *not* there. The operational attribute 'monitorContext' contains the suffix of "database monitor".
So if back-monitor is correctly configured this query goes like this:
So I guess I really did not add a monit database yet, which is exactly what I'd like to achieve.
Thanks for confirming.
That is not a confirmation. Did you actually do an ldapsearch using a base of "cn=monitor" ?
I actually did. And while we might have had too many negated statements in the conversation to be absolutely clear, I think Michael's impression was correct, as I now get
root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b '' -s base '+' '*' | grep -v supported dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=<redacted>,dc=de monitorContext: cn=Monitor entryDN: subschemaSubentry: cn=Subschema
i.e., the Monitor context does appear.
It sounds to me like you manually added or deleted elements of your configuration while slapd was running, thus leaving things in a confused state.
Quite likely, however, the steps I did that could modify the configuration were exactly the ones I described (in particular, no deletions, no manual fiddling with files in /etc/ldap/slapd.conf/)
Otherwise, I would have been less confused.
Well, I still think that a bit more detailed information in the manual about setting up the monitoring backend would have been useful.
Cheers,
Arno
Hi all,
guess I have this sorted out, so see below for my last few paragraphs that I suggest to put into the manual.
Thanks for all your suggestions, though it seems the problem was something rather unrelated. Just don't ask me what it might have been...
On 03.02.2019 at 22:56, Arno Lehmann wrote:
-----8<--------------cut here... manual text below ------------->8------
...
Naturally, the ACL(s) may be adjusted as needed.
root@host:~/ldap# ldapadd -H ldapi:/// -Y EXTERNAL -f addMonitorDB.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase=monitor,cn=config"
If this command succeds, the OpenLDAP instance can now be monitored using LDAP. If it fails with an error message such as
ldap_add: Other (e.g., implementation specific) error (80) additional info: only one monitor database allowed
it may be necessary to stop and restart the slapd process. (In at least one case, it only worked after a few restarts and after adding some other objects to a real database backend first. The author is absolutely not sure what eventually lead to success adding the above LDAP data.)
20.1.7. Verifying monitoring does work
After the above steps are taken, queries such as
root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=Statistics,cn=Monitor' -s children 'monitorCounter' dn: cn=Bytes,cn=Statistics,cn=Monitor monitorCounter: 1393550
dn: cn=PDU,cn=Statistics,cn=Monitor monitorCounter: 401
dn: cn=Entries,cn=Statistics,cn=Monitor monitorCounter: 224
dn: cn=Referrals,cn=Statistics,cn=Monitor monitorCounter: 0
will provide useful results.
-----8<--------------cut here... manual text above ------------->8------
So, this is my proposal to add to the manual. Feel free to use it, itf needed, tell me where I have to assign legal permission!
Cheers,
Arno
Arno Lehmann wrote:
So, this is my proposal to add to the manual. Feel free to use it, itf needed, tell me where I have to assign legal permission!
Please read the website. That's why it's there.
http://www.openldap.org/devel/contributing.html
Hi Howard,
On 09.02.2019 at 04:40, Howard Chu wrote:
Arno Lehmann wrote:
So, this is my proposal to add to the manual. Feel free to use it, itf needed, tell me where I have to assign legal permission!
Please read the website. That's why it's there.
Thanks for the pointer.
My understanding is that you'd expect a patch against the current git head. That, at this time, is something I hesitate to do, mostly because it's way outside my usual work...
I also see that a very basic patch to add the bare essentials has not (yet) been incorporated, because it's not generic enough. Thus, I fear my longer text would be even less suitable.
As I have not received any feedback on the actual text suggestion, I'll keep this on the backburner for now. If anybody involved in maintaining the documentation stumbles over it, all the better, I'm happy to attach the public domain assignment as needed.
Let's see if I find more things where I believe to be able to provide contents... if things start piling up, I may end up checking out the git tree :-)
Cheers,
Arno
openldap-technical@openldap.org