directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: [Studio] Dealing with various LDAP servers...
Date Wed, 17 Jun 2015 21:32:03 GMT
Le 17/06/15 21:11, Stefan Seelmann a écrit :
> 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? 
no, in my case, I'm talking about the OpenLDAP config editor, which
tries to read the config from a running server.

> It's not about the LDAP
> Browser. Both of them handle schema loading differently. I tried to
> explain that in the following mail:

This is what I see in my case : first, we read the schema using the
detected SchemaConnector, then we try to save it as LDIF, but this fail
because we don't know how to deal with the created Schema element which
are not present in OpenLDAP (at some point, I get an error because the
OID is not numeric, which is expected considering that they are created
this way when missing).
> 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.
Yes, I went through those methods today.

>> 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 wonder if it woudl not be a good idea to give the users an opportunity
to specify the kind of server they are working with, when the connection
is created, then to use the associated Schema handler.

If we don't have this information, then we are back to a smart guess (as
much as we can).

> 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.

The needs are different, that's for sure, but I wonder if we are not
trying to overdo, just to be able to handle any server.

Anyway, I was just trying to expose the problem I was facing, and I
don't know enough about the way we handle the schema in both contexts,
so I don't have a clear solution right now. I appreciate your inputs
that help me to get a better understanding of the existing code.

It's not urgent, we have plenty of time to rethink this part (if needed)
and I think it would be better suited for a 3.0.

Thanks Stefan !

View raw message