directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: [Studio] Dealing with various LDAP servers...
Date Wed, 17 Jun 2015 19:11:20 GMT
Hi Emmanuel,

On 06/17/2015 04:21 PM, Emmanuel L├ęcharny wrote:
> Hi guys,
> we have a serious problem with the way we deal with the various LDAP
> server we want to support. Well, I would say we try to avoid knowing
> which server we are talking to, expecting all the servers to provide
> pure and compatible LDAP information.
> Sadly, this is not a perfect world, and there are *many* differences
> between the various LDAP server out there. Here is a use case where it's
> critical to know beforehand what is the server we are daling with :
> - I'm trying to create an OpenLDAP schema project, loading the schema
> from an OpenLDAP server. It should be easy, but at some point, I get
> some error, because some AttributeType uses some MatchingRules that are
> not visible in the cn=subschema. As a matter of fact, we try to
> workaround the problem by *creating* fake MR, that has no OID, but a
> name instead. This work up to the point you want to actually write the
> schema on disk, because the OID is not numeric.
> We do have some method used to try to discover the type of LDAP Server
> we are working with, based on the VendorName attribute (rfc3045), but
> OpenLDAP, for instance, does not expose this Attribute. But even if we
> had this information, that would not be enough : we also need to know
> whcih version of the LDAP server we are dealing with, as their schema
> may evolve in the time.
> So at the end of the day, it works most of the time, but when it
> doesn't, there is no simple way to workaround the problem.

So you talk about the Schema Editor, right? It's not about the LDAP
Browser. Both of them handle schema loading differently. I tried to
explain that in the following mail:

In the LDAP Browser plugins we have some server detection code
(ServerTypeDetector) which not only checks for VendorName but also for
other attributes like suppportedControls in RootDSE. However that is not
really reliable, it is only used to display the server type in the
connection properties.

> I'd like to suggest we add some information in the Connection to help
> Studio with those aspects. Typically, it would be quiet useful to
> propose a list of Server we know we support, and their versions. If one
> decide to use OpenDLAP 2.4.31, for instance, then we could add some
> specific classes to suport what is specific for this server.
> I know that it would add a lot of specific classes, each one of them
> being dedicated to a range of versions of a specific LDAP server, but I
> don't really see what we could do other than that to fix this situation.
> And btw, we already have such dedicated classes :
> ApacheDsSchemaConnector and GenericSchemaConnector.

For the Schema Editor I totally agree with you. It's better to say we
don't support editing of schema (or configuration) of an LDAP server and
avoid to generate invalid schema/config or even break the server.

For the LDAP Browser I see it differently. Here we should basically
suppport any server type. Of course we can also try to detect the server
type and add additional functionality for it.

I'm not sure if we should try to combine the connection and schema
handling of LDAP Browser on the one hand and Schema Editor / Config
Editor on the other hand.

> Note that it's not going to be easy, and it might impact Studio in many
> aspects, so I'm not suggesting to do it right away, I just like to have
> your opinion about those problems.
> Thanks !

View raw message