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