On 01/26/2015 12:55 PM, Emmanuel Lécharny wrote:
In ApacheDS, there are two ways you can update the schema : - though
the subschemaSubentry - directly modifying the cn=schema partition. In
fact, updating one will update the other. The only little difference
(well, little is an understatement) is that cn=schema has a
proprietary format, when the DSE has a standard one. This is why we do
favor the DSE approach.
Actually, I do not care at all about schema updates. That is too hard.
And it is out of scope of loadSchema() operation anyway.
As long as loadSchema() works I'm happy.
ATM, this approach sounds reasonable, indeed . I'm quite sure that it
would work with OpenLDAP, except that we have to change the code that
check if the remote server is ApacheDS. I can do that immediately. If
this approach does not fly for, say, server X, then we have to find a
way to know which kind of server it is, and then we can fail back to
cn=schema.
No problem. I can do that.
At this point, the code will more or less looks like :
- check with RootDSE
- if it fails, try to get the server vender information
- if we have some, read the schema using the appropriate method
- otherwise, check cn=schema
- for each server we support, try to read the schema, until we get
it read correctly
I would suggest not to use vendor data at all unless it is really
necessary. These can change between product versions. This may be a
difficult maintenance burden.
I would rather suggest this:
- get root DSE
- check vendor-specific data in root DSE for known special cases that
fail with the "automagic" process below (hopefully not needed now, but
we may need it in the future)
- try to use subschemasubentry from root DSE. If it works return the schema.
- if that fails, try going directly to cn=schema. If it works return the
schema.
- if that fails, try X. If it works return the schema.
- if that fails, try Y. If it works return the schema.
- ...
- if all fails throw an error
Or, if there are issues we can modify it to something like:
- get root DSE
- check vendor-specific data in root DSE for known special cases that
fail with the "automagic" process below (hopefully not needed now, but
we may need it in the future)
- try to use subschemasubentry from root DSE.
- try strict schema parser, If it works return the schema.
- try more relaxed schema parser, If it works return the schema.
- if that fails, try going directly to cn=schema.
- try strict schema parser, If it works return the schema.
- try more relaxed schema parser, If it works return the schema.
- if that fails, try X. If it works return the schema.
- if that fails, try Y. If it works return the schema.
- ...
- if all fails throw an error
So, this will prefer servers that follow the standard way. Less
roundtrips. But it should eventually find the schema for most servers in
most cases without any configuration. And it is unlikely to break with
new LDAP server versions and/or product rebranding as vendors tend to
keep some form of backward compatibility.
This obviously needs some experimentation to get this right ... and I'm
willing to do it.
BTW, I've just checked that at least OpenDJ and 389ds (and of course
also OpenLDAP) all seems to support subschemasubentry in root DSE. And
they all return the schema in what seems to be the RFC format. There may
be some issues, of course. But it looks like that the support for these
servers should not be difficult to implement.
--
Radovan Semancik
Software Architect
evolveum.com
