On 8 Jul 2009, at 17:12, bill.co...@unh.edu wrote:
Chris Ridd recently wrote (in part):
I think the problem's in the way Oracle's representing the
SYNTAX oid value. RFC 4512 ... You could ask Oracle how to
configure the server to return valid schema.
After looking at the RFC's you referenced, as well as
http://www.openldap.org/doc/admin23/schema.html
I would have to agree (with what little I know on the subject)
that it doesn't look like Oracle is following the spec. On
the other hand the V3.2 of LDAPsoft's LDAP Admin Tool appears
to consume the schema definitions without problems.
You could try changing the "die" when checking the extra {128} token
into a "warn". Looks like the die on line 355 (ie without the "Drop of
end of list" comment) is the culprit - try that and see.
I'll try submitting a bug report to Oracle, but given past
experience with this company, I'm not optimistic.
As for correctly handling schema errors, how can the error()
method (as described in Net::LDAP::Schema documentation) be
used if the value being returned by the schema method is
undefined?
If I'm trying to analyze schema parsing problems I create a schema
object first, and then call parse with the contents of a subschema
subentry. Something like:
$dn = $ldap->root_dse()->get_value("subschemaSubentry");
$res = $ldap->search(base => $dn,
scope => 'base',
filter => '(objectclass=subschema)',
attrs => ['objectClasses', 'attributeTypes']);
die "Search failed " . $res->code . "\n" if $res->code;
$schema = Net::LDAP::Schema->new;
$schema->parse($res->entry(0)) or print "Schema parse failed with " .
$schema->error . "\n";
Cheers,
Chris
