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

Re: Hardcode 'description' and 'seeAlso'

Pierangelo Masarati wrote:


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.

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.

As I said I have no overlook about the implications with upcoming
back-config etc.

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.

I agree.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support