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.
