Re: problem perl-ldap-0.22 working with OpenLDAP

[Chris R. <chr...@me...>]

Javier <te...@rd...> wrote:
> Hello guys!
> 
> I have found one problem with module LDAP.pm working with the LDAP server
> OpenLDAP.
> 
> When I try request the schema of the server, it don't answer, it is
> becouse in the subroutine of LDAP.pm
> 
> sub schema {
> 
> ...
> $mesg = $self->search(
>    base=>$base,
>    scope=>'base',
>    filter =>'(objectclass=*)',
>   );
> ....
> }
> 
> but OpenLDAP need to specify the name of attribute request. Then it anwer
> correctly. For this reason when I write a script how this:
> 
> $schema = $ldap->schema(); don't answer correctly , becouse OpenLDAP
> don't answer the attribute subschemasubentry if it don't request
> specifically.
> 
> Can somebody helpme?

The code is broken, I think.

If the Net::LDAP::schema() method is trying to read the subschema subentry
mentioned in the root DSE, then it should be doing this:

	$mesg = $self->search(
		base => "$base",
		scope => 'base',
		filter => '(objectclass=subschema)',
		attrs => [qw(attributeTypes objectClasses ldapSyntaxes)]
	);

in order to comply with the last paragraph of RFC 2251 section 3.2.2. It is
debatable whether the 'attrs' line has to be there; the specs do not
indicate either way.

However, there's another way to get at the schema. In LDAPv3 the schema is
accessible directly from every entry in operational attributes. So don't
use the Net::LDAP::schema() method. Just do a read (well, a base object
search) of the normal entry that your schema will be applying to, and
request the 'attributeTypes', 'objectClasses' and 'ldapSyntaxes' attributes
back. Then construct a schema object directly:

	$schema = Net::LDAP::Schema->new($entry);

This is somewhat less efficient than using a subschema subentry because you
cannot cache the schema. If you read the createTimestamp/modifyTimestamp
attributes from the subschema subentries you can avoid repeatedly reading
and parsing the schema.

But it will avoid you modifying the Net::LDAP code.

> I would like don' modify LDAP.pm to resolve this problem!

It's a bug though. The filter should be (objectclass=subschema), and
*probably* the three interesting schema attributes should be requested.

> Thanks for all!
> 
> 
> 
> 



Cheers,

Chris