directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: [Studio] Configuration UI
Date Fri, 03 Apr 2015 08:42:43 GMT
Le 03/04/15 10:31, Clément OUDOT a écrit :
> Le 03/04/2015 10:27, Emmanuel Lécharny a écrit :
>> 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
>>> (https://www.linid.org/projects/linid-om/wiki), 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
>> (http://www.openldap.org/lists/openldap-bugs/200611/msg00115.html)
>>
>> This is the reason it has been moved into the monitor backend, which can
>> be subject to access control.
>
> I am pretty sure that we can do access control on the RootDSE in
> OpenLDAP.

Yes. Something like :

|access to attrs="||vendorversion" by * none by dn="<admin dn or whatever>" read|


will protect the info.
>
>> 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.
>
> You don't have the list of compiled backend and overlays in cn=config,
> just those which have been configured. Or you plan to extract this
> list from the built-in schema?

As I will have to read the config schema anyway, I will have all what I
need.
>
>> Anyway, I agree that cn=monitor should always be activated.
>>
>
> Seems indeed an easy requirement.
Indeed. Plus it offers many other important infos.


Mime
View raw message