[Date Prev][Date Next]
Re: Hardcode 'description' and 'seeAlso'
> 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
> 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.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497