Re: Net::LDAP::schema brokenness

[Kurt D. Z. <Ku...@Op...>]

My suggestion is to have three routines:

subschema( targetDN ) which reads the subschema contained in the
entry (or subentry) named by the DN.  This would do a base
search of the DN with the filter (objectClass=subschema) and
specifically request the return of attribute types describing
the schema elements.

subschemasubentry( targetDN ) which returns the DN contained
as a value of the subschemaSubentry attribute type within
the entry (or subentry) named by the DN.  Would return error
if multiple values of subschemasubentry exist (subschemasubentry
is a single valued attributed type).

schema( DN ) [named this for historical purposes] which is
a basically a shortcut for
        subschema( subschemasubentry( targetDN ) )

Note this would return an error if the root DSE subschemasubentry
contained multiple values.  This is a FEATURE as the user needs
to select the correct one manually to obtain the appropriate
schema.

Kurt


At 06:02 PM 1/29/01 +0000, Chris Ridd wrote:
>I think the schema method of the Net::LDAP class is fairly broken. It isn't
>documented, either :-)
>
>Here's my take on the existing behaviour:
>
>schema ( [ dn => DN ] )
>
>DN is an optional distinguished name. If not present, the method will use a
>random DN from the Root DSE's subschemaSubentry attribute. If this
>attribute is not present, the method will try <cn=schema>.
>
>It then tries to do a base object search of that DN with a filter of
>(objectClass=*).
>
>However, this is useless if you specify the DN, because the schema object
>can only be constructed if the search requests some operational attributes.
>
>This is also useless if you don't specify the DN and there is a
>subschemaSubentry attribute in the root DSE, because the filter is wrong
>(see RFC 2251 section 3.2.2, last para.)
>
>It's probably also useless in the <cn=schema> case, though that case seems
>to be a band-aid for broken versions of a particular server (Netscape?) and
>so all bets are probably off on that one's behaviour ;-)
>
>So the code's kind of trying to do two different things (reading a subentry
>and reading an entry) and failing at both.
>
>Here's what I think this code should do.
>
>schema ( [ dn => DN ] )
>
>        If a DN is passed, return a Net::LDAP::Schema object using the subschema
>retrieved from the objectClasses and attributeTypes operational attributes
>from that entry (specifically entry, *not* subentry.)
>
>        If a DN is not specified, return a Net::LDAP::Schema object using the
>objectClasses and attributeTypes held in the subentry (again, specifically
>subentry, *not* entry) referenced by one of the values from the Root DSE's
>subschemaSubentry attribute. If the Root DSE doesn't contain a
>subschemaSubentry attribute, try using the DN of <cn=schema> for
>compatibility with some broken directory servers.
>
>I'm attaching some diffs against Net::LDAP 0.20 which implements this
>behaviour. The line offsets are probably a bit out too because I've been
>experimenting with some other local changes. Sigh. Anyway, sorry it isn't
>against a clean 0.22, but the guts of the change are:
>
>In schema() add a $filter variable and set it depending on the existence of
>$arg{'dn'};
>
>In schema() set the attrs array when reading the subschema to include the
>necessary operational attributes;
>
>In root_dse() set the attrs array when reading the Root DSE to include all
>the standard (RFC 2251) operational attributes.
>
>I suppose I must get around to installing 0.22 at some point :-)
>
>Cheers,
>
>Chris