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.
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?
Anyway, I agree that cn=monitor should always be activated.
Seems indeed an easy requirement.
--
Clément OUDOT
Responsable LinID - http://linid.org
