directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: [Studio] Configuration UI
Date Fri, 03 Apr 2015 08:27:05 GMT
Le 03/04/15 10:12, Clément OUDOT a écrit :
> Le 03/04/2015 10:08, Emmanuel Lécharny a écrit :
>> Le 03/04/15 09:20, Clément OUDOT a écrit :
>>> Le 02/04/2015 07:47, Emmanuel Lécharny a écrit :
>>>> Le 01/04/15 23:28, Emmanuel Lécharny a écrit :
>>>>> Hi,
>>>>> I face an issue that requires some thought - and potentially some
>>>>> rework
>>>>> in both the ApacheDS and OpenLDAP configuration editors -.
>>>>> Once upon a time, we had many versions of the ApacheDS configuration
>>>>> plugin, because every time we changed the configuration, we had to
>>>>> adapt
>>>>> the UI. We decided to get rid of all those plugins, to only keep the
>>>>> latest version (ie 2.0). Th pb is exactly teh same for the OpenLDAP
>>>>> configuration : it evolves...
>>>>> Finding the best way to deal with this problem is not simple. It's
>>>>> not
>>>>> only a pb of loading the right config, it's also a pb with the UI
>>>>> itself. ATM, I don't see any good solution to get an UI that is
>>>>> adaptative, but defining a new plugin for each version, which is
>>>>> extremelly heavy, or a complex handling of the UI with various
>>>>> checks to
>>>>> handle all the possibilities.
>>>>> First, I do think that for ApacheDS, we can keep going with only one
>>>>> plugin, because we expect our users to migrate to the latest ApacheDS
>>>>> version, until we reach a 2.0. It's not ideal, but this is most
>>>>> certainly the right thing to do.
>>>>> For OpenLDAP, it's really different, because there are tens of
>>>>> thousand
>>>>> users with many different versions (and I'm just talking about the
>>>>> 2.4
>>>>> revision, which, as of today, has 41 versions). It makes it
>>>>> impossible
>>>>> to ignore older versions (up to a point), especially for all those
>>>>> who
>>>>> are installing the broken and antiquated versions 'provided' (so to
>>>>> speak) by distribution (RH, Debian, etc...)
>>>>> So, what are our options ?
>>>>> Currently, we define some Java bean to store the attribute's value.
>>>>> That
>>>>> means we have to also keep a track of which attribute exists in each
>>>>> version (this is not done atm), so that we don't inject unexisting
>>>>> attributes, or simply have missing ones. The other aspect we have to
>>>>> deal with is the GUI itself : how do we present the parameters and
>>>>> their
>>>>> values, when it can change fro version to version ?
>>>>> At some point in the future, we coud imagine to leverage the template
>>>>> editor, but that would require some adaptation (typically, if we
>>>>> want to
>>>>> add popups, as it's not supported). But that would be a lot of work.
>>>>> A simpler option would be to have templates for each configuration
>>>>> ObjectClass, but we would use a much simpler GUI : the user would
>>>>> have
>>>>> to use the LDAP browser to switch from one configuration element to
>>>>> another. Quite basic, but an elegant presentation is possible.
>>>>> Anyway, a lot to think about, and I'd liek to have your opinion about
>>>>> what could be the best way to go.
>>>>> Thanks !
>>>> I would add that, for OpenLDAP, it's impossible to know which
>>>> version we
>>>> are connected to, as it does not provide the vendorVersion
>>>> attribute in
>>>> the rootDSE :/
>>>> The only way would be to provide such an information at the connection
>>>> level, which is highly problematic...
>>> Hi Emmanuel,
>>> We get this information in the cn=monitor backend, see:
>>> dn: cn=Monitor
>>> structuralObjectClass: monitorServer
>>> creatorsName:
>>> modifiersName:
>>> createTimestamp: 20150403064323Z
>>> modifyTimestamp: 20150403064323Z
>>> monitoredInfo: OpenLDAP: slapd 2.4.40 (Oct  1 2014 11:57:04)
>>> entryDN: cn=Monitor
>>> subschemaSubentry: cn=Subschema
>>> hasSubordinates: TRUE
>>> But it would be indeed easier to get it from RootDSE. Maybe you should
>>> open an ITS for this.
>> Yes, I will. The pb is that the monitor backend is not always setup...
>> Anyway, tahnks for the info.
> Yes, when we implemented LinID OpenLDAP Manager
> (, we choose to require
> the presence of the monitor backend. It was used to know the OpenLDAP
> version and the list of available backends and overlays.

As Kurt says - and I agree with him -, providing such an info in the
rootDSE, which can be read by everyone, is a kind of security breach

This is the reason it has been moved into the monitor backend, which can
be subject to access control.

For the list of backends/overlays, the best is to have access to the
cn=config partition : it has everything you need, and it's always present.

Anyway, I agree that cn=monitor should always be activated.

View raw message