On 04/28/2015 01:53 PM, Emmanuel Lécharny wrote:
Where on OpenLDAP schema do you need a LAX mode ? AFAICT, we are able
to parse all the OpenLDAP schemas in Strict mode...
There seems to be plenty of issues:
ERR_04486_VALUE_ALREADY_EXISTS The value 'preferredDeliveryMethod'
already exists in the attribute (m-may)
ERR_04486_VALUE_ALREADY_EXISTS The value 'streetAddress' already exists
in the attribute (m-may)
ERR_04486_VALUE_ALREADY_EXISTS The value 'telephoneNumber' already
exists in the attribute (m-may)
ERR_04486_VALUE_ALREADY_EXISTS The value 'preferredDeliveryMethod'
already exists in the attribute (m-may)
ERR_04317 The created MatchingRule must refers to an existing SYNTAX element
...
ERR_04306 Cannot find a Syntax object 1.3.6.1.4.1.1466.115.121.1.42
while building cross-references for the protocolInformation AttributeType.
ERR_04308 Cannot find an Equality MatchingRule object for
protocolInformationMatch while building cross-references for the
protocolInformation AttributeType.
ERR_04306 Cannot find a Syntax object 1.3.6.1.4.1.1466.115.121.1.21
while building cross-references for the enhancedSearchGuide AttributeType.
ERR_04306 Cannot find a Syntax object 1.3.6.1.4.1.1466.115.121.1.31
while building cross-references for the matchingRuleUse AttributeType.
...
(OpenLDAP 2.4.31)
Strangely this seems to be the same in both strict and relaxed modes.
Also one clue about the whay the schemaManager processes schemas : - a
first pass is done where we simple read all the schema elements, not
controling any of the interdependence between them (for instance, if
an OC is declared but not the used AT, then we accept the OC). - a
second pass now check all the dependencies between all the schema
elements. So to speak, this is the STRICT mode. Does it make sense ?
Thanks. That helped a bit. I have been able to move forward by
explicitly calling schemaManager.loadAllEnabledRelaxed() instead of
connection.loadSchema(). And then ignoring all the errors
(schemaManager.getErrors()). This is not very intuitive for the
developers that try to use the API. But I can live with that.
However, there is something that bothers me a bit more. The API won't
survive attempts to work with such a schema. E.g. attempt to get root
DSE dies with:
ERR_04269 ATTRIBUTE_TYPE for OID configcontext does not exist!
After all of this I think the best option would be to resign on using
the schema-aware mode to connect to OpenLDAP. I've tried to switch to
schema-less mode by not setting any schemaManager to a connetion (is
this the correct way?). It looks like this might work. At least root DSE
fetch worked. I'll make more tests, but if it is like this then I'm
quite OK with this. I'm able to get a schema to be processed. And I'm
able to execute LDAP commands. Even though they are schema-less that's
OK for me as I need to convert them to ConnId (Java) data types and
therefore I need to process the schema explicitly anyway.
So, assuming that I do not run into any more problems I'm just thinking
that documenting what I've found on the API site would be enough for
other users to know what to do when connecting to OpenLDAP. I can write
the documentation.
Looking back it seems that my worst problem was that I haven't
understood how schema manager and schema loader works. I have probably
used them in a wrong way by naively calling connection.loadSchema() and
thinking that it will work. I guess that other API users will make the
same mistake. So I think that investing time to document this is really
going to help.
I still know about one more problem with root DSE in 389ds. I'll handle
that later.
BTW. I've also re-run my tests with OpenDJ and API 1.0.0-M31-SNAPSHOT
rev.1676504, schema-aware, quirks mode on. It seems to work well. Except
the small detail that the VLV support seems to be broken in the latest
stable OpenDJ (2.6.2) ... but that's not our problem :-)
--
Radovan Semancik
Software Architect
evolveum.com
