Hi Stefan, Thanks for adding your contribution to this collaborative "brainstorming". :)
On 4 nov. 2010, at 17:09, Stefan Seelmann wrote: > Thanks Pierre-Arnaud for the detailed idea. > > On Thu, Nov 4, 2010 at 3:48 PM, Pierre-Arnaud Marcelot <[email protected]> > wrote: >> Hi Dev, >> >> I'm currently starting to work on the new ApacheDS Configuration Editor for >> the upcoming Apache DS 2.0. >> >> Instead of taking the (dead and removed in ApacheDS 2.0) 'server.xml' it >> used to take in previous versions of Apache DS, this editor is now intended >> to read the 'Configuration Partition' of the new ApacheDS 2.0 version. >> The idea is to be able to edit (read and write) the configuration from the >> 'config.ldif' file on disk, but also from a running ApacheDS via LDAP >> operations (under the 'ou=config' partition). >> >> I'd like to propose some ideas around the design of the UI for the editor, >> and to have your thoughts about them, in order to make it as usual as >> possible. >> >> First, the new editor will inherit a lot of things from the current one. >> Especially, its layout, with a tab based editor. >> >> After a look at the current configuration partition implementation, here are >> the tabs I have identified: >> - Overview >> - LDAP(S) Server >> - Kerberos Server >> - Partitions >> - Password Policy >> - Replication >> - Options >> >> I excluded the configuration of the Interceptor Chain on purpose. I really >> think that it's an internal configuration the end-users should not be >> dealing with, but that can be inferred from the other configuration. Like, >> for example, if the Kerberos Server is enabled, we know that the >> KeyDerivation interceptor must be added to the interceptor chain at a >> particular location in it, and the editor will do that for the user under >> the hood when the 'Enable Kerberos Server' button is pressed. > > +1 > >> Same thing for Extended Operation Handlers. >> >> At the moment, DNS, DHCP and NTP server configurations are excluded from the >> editor, given their current state in development and testing, as well as the >> value for our users to be able configure such servers (I'm not really they >> come to ApacheDS for this sets of features). > > +1 > > >> -> Overview Tab >> ---------------------- >> >> This tab is intended to allow a quick access to the most essential and >> useful settings. >> We'll have widgets to enable LDAP(S) or Kerberos Servers, as well as set >> their listening ports. >> We would also have a recap of the most important settings in the other tabs, >> with the ability to jump to advanced configuration in each section. > > Do you think this should be a read-only overview panel? Otherwise some > settings can be edited in two places, which might be confusing. That's a good question. I didn't think having these particular settings editable at multiple place could be a problem... But, you're might be right, maybe we can/should make the overview tab just a simple read-only tab. Do others think it might lead to some confusion? >> -> LDAP(S) Server >> ------------------------- >> >> This tab will be used to control the LDAP and LDAPS Servers settings. >> Users should be able to enable/disable LDAP and LDAPS independently, as well >> as specifying their ports. >> They should also be able to: >> - enable/disable access control, anonymous access > >> - choose the supported authentication mechanisms >> - set the SASL settings (host, principal, realms, etc) > Those are complicated settings, they depend on each other and other > settings. For example CRAM-MD5 or DIGEST-MD5 don't work when the > stored password is hashed (I don't know if that's a general limitation > or only applied to ApacheDS). Yeah, these are not very simple settings, but I think they need to appear in the editor. Would you prefer to hide them? Actually, it seems the specs indicates that password should be stored as plain text. I ran into this issue a few days ago when testing a CRAM-MD5 bind with the new Apache Directory LDAP API within Studio. Here's what Wikipedia indicates in the Protocol Weaknesses of the CRAM-MD5: "Need to secure server: The server needs access to the users' plain text passwords. Therefore it must take additional care to secure these passwords. Typically by using reversable cryptography." -> http://en.wikipedia.org/wiki/CRAM-MD5 > >> - set the limits (time limit, size limit, etc) >> - keystore, certificate (and when it's migrated to the configuration, the >> admin's credentials) > > Some additional widgets: > - enable/disable TLS > - enable/disable server-side password hashing and select hashing method I'm not sure we have configuration elements for these. But it would definitely be something to have... >> -> Kerberos Server >> ------------------------- >> >> This tab will be used to control the Kerbros Server settings. >> Users should be able to enable/disable Kerbros, as well as specifying its >> port. >> The following AT values will also need to be edited via the UI: >> - ads-krballowableclockskew >> - ads-krbbodychecksumverified >> - ads-krbemptyaddressesallowed >> - ads-krbencryptiontypes >> - ads-krbforwardableallowed >> - ads-krbkdcprincipal >> - ads-krbmaximumrenewablelifetime >> - ads-krbmaximumticketlifetime >> - ads-krbpaenctimestamprequired >> - ads-krbpostdatedallowed >> - ads-krbprimaryrealm >> - ads-krbproxiableallowed >> - ads-krbrenewableallowed >> - ads-searchbasedn >> >> I don't have a particular idea in mind yet on how these settings can be >> organized in the UI. >> If you do, please let me know. > > Me neither. > > Maybe we should have two sections: > - one containing the most important attributes > - enable/disable > - ports > - ads-krbkdcprincipal > - ads-krbprimaryrealm > - ads-searchbasedn > - ads-krbencryptiontypes > - another containing the advanced attributes Yeah, I had in mind something very similar. >> -> Partitions Tab >> ---------------------- >> >> This tab will reuse the existing Partitions Tab of previous editor versions. >> It allows the creation, edition and deletion of partitions with their >> specific properties (ID, Cache Size, Suffix, Optimizer Enablement, Syncho On >> Write Enablement and creation, edition and deletion of Indexed Attributes). >> An overview of the existing Partitions Tab can be seen at this URL: >> http://directory.apache.org/studio/static/users_guide/apacheds_configuration/configuration_editor_1.5.5_partitions.html > > Ok. > > For the index attributes it would be nice to show the attribute name > instead of the OID. Yeah, we could also do if we an access the schema, or use a default schema (in case we don't have access to the online schema). > Maybe that widget should be splitted: system > indexes (including objectClass and entryUUID) and user indexes At the moment, I think we cannot differentiate system and user indexes. I'm even wondering if the configuration shouldn't only contain user defined indexes, system indexes being created automatically by the 'system'. > And a new widget to define the context entry would be nice. And a > button to generate the context entry based on the suffix (dc, o, ou) Yeah, we had such a widget in previous versions of the editor, when the server configuration allowed it. +1 for the automatic generation button. Maybe, it could only just be a switch (true, false) and we can let the server generate it for us. >> -> Password Policy Tab >> -------------------------------- >> >> This will be used to define all settings related to the password policy >> sub-system. >> The user will be able to enable/disable it, and edit the following AT values >> via the UI: >> - ads-pwdattribute >> - ads-enabled: true >> - ads-pwdallowuserchange >> - ads-pwdcheckquality >> - ads-pwdexpirewarning >> - ads-pwdfailurecountinterval >> - ads-pwdgraceauthnlimit >> - ads-pwdinhistory >> - ads-pwdlockout >> - ads-pwdlockoutduration >> - ads-pwdmaxage >> - ads-pwdmaxfailure >> - ads-pwdminage >> - ads-pwdminlength >> - ads-pwdmustchange >> - ads-pwdsafemodify >> >> Again, I need to see how these things could be regrouped and organized. >> If you already have ideas. >> >> >> -> Replication Tab >> ------------------------- >> >> This tab will be used to define all settings related to the replication >> sub-system. >> I'm waiting on you guys to tell me what and how replication should be >> configured. >> I'm not even sure we have a working configuration for this already. >> >> >> -> Options Tab >> -------------------- >> >> This tab will be dedicated to more general and technical settings like: >> - denormalization of operational attributes >> - max PDU size >> - synchronization period >> - journal (location, filename, rotation) >> - changelog >> We could also put the configuration of the embedded HTTP server and webapps >> in there. > > Pretty much. > > > Some more ideas: > - Indicate when a restart of the server is required (always?) I think for most (all?) of these settings, a restart will be required. For configuration editor based on an LDAP Connection with a server, we could even add a button which restarts the server remotely (via an extended operation). But, it might not be trivial to do. > - Backup/Restore the configuration to/from an LDIF. You'd be able to save a configuration editor based on an LDAP Connection via the 'Save As...' menu item, but you're right a dedicated area in the editor for this is much better. Especially for the restore feature. +1. Thanks! Regards, Pierre-Arnaud > > > Thanks again. > > Kind Regards, > Stefan
