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.
