[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: portable.h contents in back-monitor (Was: [Fwd: commit: ldap/servers/slapd/back-monitor...)

Kurt D. Zeilenga wrote:
At 11:09 AM 1/12/2006, Pierangelo Masarati wrote:
I suggested to hack OL_DEFINE because ...

The problem is that this will only produce a correct
capabilities list when folks go through configure.
Folks however enable/disable capabilities via other
means. You also have the problem that capabilities can
be added by module.  Nothing ensures that all modules
were built using the same configure output as slapd.

For these reasons, I think we need to be very careful
as to how we manage capabilities.  For instance,
just because slapd was not built with back-ldap,
the installed and running slapd could have a back-ldap
module loaded.  So instead of just having:

#ifdef something
        "Backend LDAP"
#endif

in a common capabilities file, we actually need the
backend to register the capabilities it provides.

Since backends already do so (they register themselves
as backends), we should consider backends themselves
as 'capabilities'. (Though you might have inter-backend
features.)

Given that back-monitor already lists all of the available backends and overlays, perhaps we don't need to include them in the feature we're discussing here. 
And as we move other 'capabilities' (SLAPI, ACIs, etc.)
to overlays/modules, it seems we should advertise their
presence through overlay/module mechanisms.

So, it seems, we're down to frontend capabilities (SASL,
TLS, etc.) and possibly a way for modules (overlays,
backends, etc.) to register what they provide.

That sounds OK. Currently back-monitor exposes the slapd version string; we should add whatever version strings are available for any other libraries we know about (OpenSSL and SASL come to mind as frontend libraries). The database backends (bdb/hdb, ldbm) should register a version string for their underlying database library, and modules in general should register a module version string.

I'm reluctant to put exhaustive build environment info into back-monitor. Lots of that information can be easily determined after the fact with common tools like nm, strings, ldd, etc., so it doesn't seem worth the effort to capture that info explicitly. (Also, from the Symas perspective, we only work two ways - supporting packages that we built, and thus we know everything about the build, or requiring interactive access to the customer's site if they want us to support something someone else built.)

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/