Monitor backend

[Pierangelo Masarati <masarati@aero.polimi.it>]

I'm about to commit a snapshot of the monitor backend.
It provides the basic initialization of the backend, its feeding
with a few dummy subsystems and some database/backend
monitoring stuff.
The architecture is very simple.

First, it is a real backend, with in-memory storage of the
entries whose values may be subjected to dynamic update
when they're about to be returned.

It supports search (base/one/sub), with filter matching,
and eventually it will support compare and abandon.

There will be an api to allow easy adding of new subsystems
with a few hooks to provide entry update.

At present there's a static naming context ("cn=Monitor")
with a static first level DIT made of the CN's of the subsystems
(e.g. "cn=Backend, cn=Monitor", "cn=Database, cn=Monitor",
"cn=Listener, cn=Monitor", "cn=SASL ,cn=Monitor" and so)
each subsystem may allow subtrees. At present, to test the
subtree recursion mechanism, I implemented the backend
subsystem, which contains all the supported backend types
and subentries for each type, and the database subsystem,
which contains all the currently configured databases, with their
type and naming contexts.
I used the "namingContexts" attribute for the naming contexts
each database serves, and "description" for the backend types.

On the schema side, at present if the objectClass "monitorSubEntry"
is defined, it is used as a common ancestor of all the entries.
It has no OID yet; when the monitor schema will be designed
(help/suggestions are welcome) OpenLDAP is supposed to assign
OIDs to these slapd-specific objectClasses/attributes.
At present, the "extensibleObject" is used, taking care of defining
new attribute types only when strictly required.

On the implementation side, I used a dn-based cache to allow easy
entry recover. Then each entry holds a pointer to its siblings and to
its children, to allow tree recursion, and a flag that marks entries
as static, having static children, volatile, having volatile children
and so. These flags are subsystem-dependent.

If an entry is not found in the cache, its dn is parsed looking for
an ancestor that allows volatile children, in which case the tree
is walked back creating these volatile ancestors up tp the required
entry.

An update mechanism is provided which is invoked right before
returning an entry.

Thanks for your patience; I'll work now on adding all the
monitor info that are already present; please give me all the
suggestions you may find useful.

Pierangelo.


--
Dr. Pierangelo Masarati               | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 | mailto:masarati@aero.polimi.it
via La Masa 34, 20156 Milano, Italy   | http://www.aero.polimi.it/~masarati