At 12:36 AM 11/20/2006, michael stroeder.com wrote:
>Kurt D. Zeilenga wrote:
>> At 01:37 AM 11/19/2006, michaelstroeder.com wrote:
>>>
>>>I'd like to see support for RFC 3045 in slapd.
>>
>> The only reasonably decent use of such attributes
is for
>> administrators to determine whether they need to
upgrade
>> some software or not
>
>Yes, that's what I'm after.
This purpose is, I think, somewhat beyond the intended
purpose
of the vendorName/Version attributes. These attributes
appear
to be intended to be used by general LDAP clients, not just
administrative clients, for "limited feature
discovery".
The vendorName/Version you might want reported for
"limited
feature discovery" might be quite different than what
you want
reported for "need to upgrade" purposes.
And for "need to upgrade" purposes, one needs to
know not only
the version of the protocol engine (slapd(8)), but version
of
backend codes, overlay codes, underlying libraries, etc..
>> We provide cn=monitor for this purpose.
>
>This is proprietary. Think of vendor-independent
management/monitoring
>software which just gives an terse overview.
Generally speaking, DSA administrative interfaces are not
standardized. (Which is, to some degree, why I think use of
vendorName/Version for administrative purposes is beyond the
intentions of these attributes.)
>> While it certainly is possible for a client to
abuse
>> cn=monitor version information, the very fact that
the
>> version information is in cn=monitor, which
generally
>> requires special authorization to read, instead of
>> the root dse, which generally is readable by most
>> every client, is effective in discouraging this
abuse.
>
>The server admin can easily define access control for
vendor information
>in root DSE. The sample slapd.conf could endorse this.
Or another value
>for configuration directive 'allow'.
Yes, but...
Kurt
|