[Date Prev][Date Next]
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:
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
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
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/