[Date Prev][Date Next]
Re: Hardcode 'description' and 'seeAlso'
Pierangelo Masarati wrote:
This is too error-prone for a variety of reasons. We already see cases
where people fail to keep their core.schema and slapd binaries in sync.
If admins had to worry about keeping internal schema files in sync as
well, things would only get more difficult.
I do not know details about hard-coded schema elements in OpenLDAP. But
I'd like to raise a short discussion about it. To me hard-coded schema
elements are generally something to avoid.
My rather naive suggestion is rather than hard-coding all the schema
elements ever needed by a backend into OpenLDAP all these backends and
overlays should lookup required schema elements in the currently schema
config set by the directory admin and fail to start (or just log) if
they are not present.
As I said I have no overlook about the implications with upcoming
Well, let aside back-config, the essential issue that drives currently
hardcoded schema items is that since they're required for directory
operations (think of "userPassword" in simple bind, or "uid" and "cn" in
mapping SASL identities, or "ref" in referrals and so) hardcoding them is
an easy, safe and reliable way to ensure they're defined as expected by
the code. Otherwise, leaving them to a configuration file would require
extra checks to ensure their definition (in terms of syntax, matching
rules, constraints and so) complies with the expectations of the software.
With respect to the issue I'm raising, the point is that the objectClass
"monitor", which allows "description" and "seeAlso" (and requires "cn" and
allows "labeledURI", which already are hardcoded), is mostly based on
operational attributes, and operational attributes cannot be parsed from
schema files (unless one resorts to the "dsaschema" module; but this would
really be a nasty workaround).
So, to avoid the chicken'n'egg problem that arises when one needs to
define monitor schema before reading slapd.conf, while allowing as much
flexibility as possible, I think hardcoding well-known, standard track
attributes is a reasonable trade-off. But that's my (humble) opinion, so
here's the reason for my request for comments.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support