From 916ed340aae764a24c9cad4a1a4df79a3bdf12ad Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Fri, 8 Dec 2006 20:09:35 +0000 Subject: [PATCH] As support for the monitor backend is included by default, the --enable-monitor steps are not needed. Best just to note this section assumes a default build and briefly note requirements if built as a module. Note that some example LDIFs don't include userApplications attributes. --- doc/guide/admin/monitoringslapd.sdf | 73 +++++++++++++---------------- 1 file changed, 33 insertions(+), 40 deletions(-) diff --git a/doc/guide/admin/monitoringslapd.sdf b/doc/guide/admin/monitoringslapd.sdf index 2c79dc019f..2c93bbaa42 100644 --- a/doc/guide/admin/monitoringslapd.sdf +++ b/doc/guide/admin/monitoringslapd.sdf @@ -26,41 +26,36 @@ explicitly requested. For example: As there are may be many objects under {{EX:cn=Monitor}}, a search with a narrower search criteria may be more appropriate. +Support for the monitor backend is included in slapd(8) in default +builds. The monitor backend may also be built as a loadable module. +The remainder of this section assumes slapd(8) was with with monitor +backend support (e.g., {{EX:--enable-monitor=yes}}, the default), +or build as a module (e.g., {{EX:--enable-monitor=mod}} and loaded +into slapd(8). + H2: Configuration -These {{slapd.conf}}(5) options apply to the monitor backend database. That is, -they must follow a {{EX:database monitor}} line and come before any subsequent -{{backend}} or {{database}} lines. +These {{slapd.conf}}(5) options apply to the monitor backend database. +That is, they must follow a {{EX:database monitor}} line and come +before any subsequent {{backend}} or {{database}} lines. -As opposed to most databases, the monitor database can be instantiated only -once, i.e. only one occurrence of {{EX:database monitor}} can occur in -the {{slapd.conf}}(5) file. Moreover, the suffix of the database cannot be -explicitly set by means of the suffix directive. The suffix is automatically -set to {{EX:cn=Monitor}} +As opposed to most databases, the monitor database can be instantiated +only once, i.e. only one occurrence of {{EX:database monitor}} +can occur in the {{slapd.conf}}(5) file. Moreover, the suffix of +the database cannot be explicitly set by means of the suffix +directive. The suffix is automatically set to {{EX:cn=Monitor}} -The monitor backend honors access control semantics as indicated in -{{slapd.access}}(5), including the disclose access privilege, on all currently -implemented operations. +The monitor backend honors access control semantics as indicated +in {{slapd.access}}(5), including the disclose access privilege, +on all currently implemented operations. For understanding how to do the following with dynamic configuration, see {{SECT:Configuring slapd}} -H3: Enabling the monitor backend - -Enable at configure: - -> configure --enable-monitor - -Or if you have enabled modules, put in {{slapd.conf}}(5): - -> # Load dynamic backend modules: -> modulepath /usr/local/libexec/openldap -> moduleload back_monitor.la - -Also ensure that the {{core.schema}} file is loaded. The monitor backend -relies on some standard track {{attributeTypes}} that must be already defined -when the backend is started. +Also ensure that the {{core.schema}} file is loaded. The monitor +backend relies on some standard track {{attributeTypes}} that must +be already defined when the backend is started. H3: Activate the monitor database @@ -83,20 +78,18 @@ More information is detailed in {{slapd.access}}(5) H2: Available Subsystems -There are various subsytems you can explicitly query for, with most information -being held in the {{monitoredInfo}} attribute. +There are various subsytems you can explicitly query for, with most +information being held in the {{monitoredInfo}} attribute. H3: Backends -The main entry contains the type of backends enabled at compile time; -the subentries, for each backend, contain the type of the backend. -It should also contain the modules that have been loaded if dynamic -backends are enabled. +The main entry contains the type of backends enabled at compile +time; the subentries, for each backend, contain the type of the +backend. It should also contain the modules that have been loaded +if dynamic backends are enabled. For example: -Backend 1: - > dn: cn=Backend 1,cn=Backends,cn=Monitor > structuralObjectClass: monitoredObject > monitoredInfo: ldif @@ -105,9 +98,7 @@ Backend 1: > entryDN: cn=Backend 1,cn=Backends,cn=Monitor > subschemaSubentry: cn=Subschema > hasSubordinates: FALSE - -Backend 2: - +> > dn: cn=Backend 2,cn=Backends,cn=Monitor > structuralObjectClass: monitoredObject > monitoredInfo: hdb @@ -123,9 +114,7 @@ Backend 2: > entryDN: cn=Backend 2,cn=Backends,cn=Monitor > subschemaSubentry: cn=Subschema > hasSubordinates: FALSE - -Backend 3: - +> > # Backend 3, Backends, Monitor > dn: cn=Backend 3,cn=Backends,cn=Monitor > structuralObjectClass: monitoredObject @@ -136,6 +125,10 @@ Backend 3: > subschemaSubentry: cn=Subschema > hasSubordinates: FALSE +In this example, the server has three backends: 1) a {{ldif}} backend, +2) a {{hdb}} backend, and 3) a {{monitor}} backend. + + H3: Connections The main entry is empty; it should contain some statistics on the number -- 2.39.5