cn=Monitor and cn=Config

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Karsten posted a patch which provides 1.2ish cn=monitor/config
support.  Though the patch fulfills an immediate need, I believe
long term we need more.

First, I'd like to see families of subentries used to
hold information so as to avoid attributes with compound values.
This avoids having to introduce new syntaxes every time we want
to provide additional information.  It also allows for finer
grained matching, access controls, etc.  So, we'd end up with
  cn=X, cn=listener, cn=monitor for each listener
  cn=X, cn=sessions, cn=monitor for each sessions connection
  cn=X, cn=backends, cn=monitor for each backend
  cn=X, cn=database, cn=monitor for each database
  cn=X, cn=thread, cn=monitor for each thread
  cn=X, cn=subsystem, cn=monitor for each subsystem (SASL, TLS, etc)

Each subentry would be a subclass of monitorSubentry which itself
would subclass LDAPsubentry.  Such a structure allows for future
extension by adding new values or additional subentries underneath
each monitor subentry.  Some monitor DN can be dynamic aliases.
For example "cn=current, cn=session, cn=monitor" would provide
information regarding the current session.  Likewise for listener
(the one which this current session was accepted from) and thread.

Second, some information should be relocated into the root DSE.
cn=config, I believe, serves little purpose.

Lastly, operational attributes within the naming context can
provide cross reference.  For example, the root of each naming
context can contain operational attributes referring to the
appropriate backend and database entries.

This could be implemented as a 'virtual' backend.  That is,
it would plug into the architecture as a backend (so that
it would be optional).  Some special casing would be provided
to avoid listing "cn=monitor" as a namingContext (as it would
be DSA-specific).

Thoughts, comments, volunteers?



At 02:52 PM 9/13/00 +0000, Karsten.Kuenne@desy.de wrote:
>| 
>| 
>| I liked to see cn=Monitor and cn=Config significantly reworked.
>| We should discuss thoughts on what needed and how best to present
>| it on the devel mailing list.  For now, I'll mark this ITS
>| 'suspended' pending that discussion.
>| 
>
>O.k.. I need it for monitoring and statistics of our server.
>
>Karsten.