September 2013 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308958] Reduce size of the Minimal Install
by fate_noreply＠suse.de 22 Sep '13

22 Sep '13

Feature added by: Jan Engelhardt (jengelh) Feature #308958, revision 1 Title: Reduce size of the Minimal Install openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Jan Engelhardt (jengelh) Partner organization: openSUSE.org Description: IMHO, the text-mode minimal install without X and anything still comes with "too many" packages. I use the minimal selection whenever I need to set up a new, clean, system, as installing onto a Minimal is faster than cherry-picking every single package for deletion from a Medium or Maximum selection. This includes, but is not limited to: * documentation to magic things happening in the background: PolicyKit-doc, readline-doc * other documentation that I've probably read already; bash-doc, perl-doc * archaic systems: yp-tools ypbind yast2-nis-client * packages serving no purpose: perl-Business-ISBN (heck, not even yast needs that), perl-GD * things that make my command line slow: command-not-found scout * it so happens that eventually I can throw out the entire python stack, and the remaining Xorg libs * printing, sound, bootsplash I have here a dump file between the initial minimal install and a tailored system - some things have been removed that I would leave on the minimal install list however (e.g. yast2-sudo). So the raw contents of the diff file is [mh, FATE has no attachments - see https://bugzilla.novell.com/show_bug.cgi?id=577791 ] Business case (Partner benefit): openSUSE.org: Everytime a new system is bootstrapped, I have to (="want to") remove these first because they will never be needed -- if they will, I can reinstall them later, or pick a larger "non-minimal" text mode from yast. -- openSUSE Feature: https://features.opensuse.org/308958

1 3

[openFATE 313537] Get rid of SuSEconfig.glib2
by fate_noreply＠suse.de 19 Sep '13

19 Sep '13

Feature changed by: Scott Reeves (sreeves1) Feature #313537, revision 8 Title: Get rid of SuSEconfig.glib2 openSUSE Distribution: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). That code should be only run as a part of post-install of the packages. Discussion: #1: Frederic Crozat (fcrozat) (2013-07-02 17:38:30) SuSEconfig being dead for SLE12, we could mark this feature as Done, already), but let's follow the process + #2: Scott Reeves (sreeves1) (2013-09-18 18:56:35) + Validate when the first SLE12 image drops out of the chute. -- openSUSE Feature: https://features.opensuse.org/313537

1 0

[openFATE 313143] YaST LDAP client refactor/cleanup
by fate_noreply＠suse.de 18 Sep '13

18 Sep '13

Feature changed by: Milisav Radmanic (radmanic) Feature #313143, revision 22 Title: YaST LDAP client refactor/cleanup openSUSE Distribution: Evaluation by engineering manager Priority Requester: Mandatory Projectmanager: Important Requested by: Ralf Haferkamp (rhafer) Partner organization: openSUSE.org Description: Jiri (jsuchome) and I recently discussed some cleanup work we'd like to see in the YaST ldap-client module. This feature lists the main items we'd like to see reworked to improve the Module: Remove no longer needed UI elements Candidates are: * The TLS/SSL checkbox (sssd has a hard requirement for SSL/TLS) * The "LDAP Version 2" checkbox in the advanced settings. (there is AFAIK no LDAPv2-only Server implementation left) * The "Use LDAP but Disable Login" Radio Button Restrict the UI to handle only really LDAP client related things Currently the UI contains quite some settings which are not strictly related to LDAP client (nss/pam) setup. Over the year ldap-client became a bit of a disposal site for all kinds of LDAP related things, which made the UI a bit hard to understand. We should move some things to YaST modules where make a better fit. This is mostly about the settings currently available in the "Administration Settings" Tab (in "Advanced Configuration") * The Password Policies settings seem to fit better into the ldap- server module which already contains some of this functionality * Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. When a specific service still requires those configuration objects the YaST module for that service should be able to handle those objects it self (we could still offer utils API for that in yast2-ldap/ldap-client). E.g. the user management related object should be configured from inside the yast2-users module. yast2- ldap-server could offer to create default objects during the initial LDAP server setup. * The Home Directories on This Machine checkbox seems to be better suite in the Users module as well. * The rest of the values which go to /etc/sysconfig/ldap could be written by yast2-ldap-servers. We still need to figure out how to setup /etc/sysconfig/ldap on machines which to not run the LDAP Server but need access to those settings. (yast2-mail, -dns-server, -dhcp-server) * Adapt the API: move the LDAP* functions from ldap-client (impact on other modules!) Relations: - related feature (feature/id: 313142) Discussion: #1: Jiří Suchomel (jsuchome) (2012-01-19 10:15:11) 1. Removing TLS/SSL is based on assumption that we configure SSSD only, which is feature 313142. 2. About The "Use LDAP but Disable Login" Radio Button: did we agree on some replacement of it? I cannot remember... #2: Jiří Suchomel (jsuchome) (2012-01-23 16:25:33) Added attachment proposal for simplified first screen (ldap-client- redesign2.png) #3: Jiří Suchomel (jsuchome) (2012-02-21 09:26:08) yast2-ldap-client-2.22.3 only offers SSSD configuration in UI, and the option to turn off TLS/SSL was removed. #5: Jiří Suchomel (jsuchome) (2012-02-21 11:37:45) (reply to #3) yast2-ldap-client-2.22.4 has the password policy configuration removed. Some parts were moved to yast2-ldap-server code (just svn), some other parts need to be added there. I've created a bug report to track it, see bnc#748004. #4: Jiří Suchomel (jsuchome) (2012-02-21 10:26:39) Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. Ralf, do you have any idea where it could/should be removed? Who can decide it? #6: Jiří Suchomel (jsuchome) (2012-04-19 08:52:07) OK, I've made most of the required changes in yast2-ldap-client, yast2- users and yast2-ldap-server. Ralf, could you take a look at current (Factory) versions of these and comment what else should be done? I mean mostly UI-wise, that API transition was not done. #7: Lukas Ocilka (locilka) (2013-07-30 14:38:43) (reply to #6) Ralf: ping #8: Ralf Haferkamp (rhafer) (2013-08-05 10:43:08) (reply to #7) Peter, could you take a look a this. I don't have any time left for this currently. #9: Joachim Werner (joachimwerner) (2013-08-08 12:45:24) Moving this forward for SLE 12. But important-only. We have a clear policy to focus on the new installer for GA and only improve YaST modules when time permits. #10: Jiri Srain (jsrain) (2013-08-08 12:49:58) (reply to #9) Agreed. This is definitely worth to spend spare cycles on. #11: Lukas Ocilka (locilka) (2013-09-09 16:41:11) Back to PjM: We currently don't have any LDAP expert available in team. Peter or Ralf could possibly work on that if they had time but they are not in Yast team. #12: Jiri Srain (jsrain) (2013-09-10 15:05:18) (reply to #11) Mili, any chance Ralf or Peter could implement this feature? + #13: Milisav Radmanic (radmanic) (2013-09-18 11:14:25) + I think Peter Varkoly should be able to take care of this feature. -- openSUSE Feature: https://features.opensuse.org/313143

1 0

[openFATE 313535] Get rid of SuSEconfig.texlive
by fate_noreply＠suse.de 17 Sep '13

17 Sep '13

Feature changed by: Stefan Fent (sfent) Feature #313535, revision 9 Title: Get rid of SuSEconfig.texlive - openSUSE Distribution: Ready + openSUSE Distribution: Validation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). That code should be only run as a part of post-install of the texlive packages as only those are affected. Relations: - Remove SuSEconfig (feature/id: 100011) -- openSUSE Feature: https://features.opensuse.org/313535

1 0

[openFATE 313143] YaST LDAP client refactor/cleanup
by fate_noreply＠suse.de 12 Sep '13

12 Sep '13

Feature changed by: Jiri Srain (jsrain) Feature #313143, revision 21 Title: YaST LDAP client refactor/cleanup - openSUSE Distribution: Evaluation by project manager + openSUSE Distribution: Evaluation by engineering manager Priority Requester: Mandatory Projectmanager: Important Requested by: Ralf Haferkamp (rhafer) Partner organization: openSUSE.org Description: Jiri (jsuchome) and I recently discussed some cleanup work we'd like to see in the YaST ldap-client module. This feature lists the main items we'd like to see reworked to improve the Module: Remove no longer needed UI elements Candidates are: * The TLS/SSL checkbox (sssd has a hard requirement for SSL/TLS) * The "LDAP Version 2" checkbox in the advanced settings. (there is AFAIK no LDAPv2-only Server implementation left) * The "Use LDAP but Disable Login" Radio Button Restrict the UI to handle only really LDAP client related things Currently the UI contains quite some settings which are not strictly related to LDAP client (nss/pam) setup. Over the year ldap-client became a bit of a disposal site for all kinds of LDAP related things, which made the UI a bit hard to understand. We should move some things to YaST modules where make a better fit. This is mostly about the settings currently available in the "Administration Settings" Tab (in "Advanced Configuration") * The Password Policies settings seem to fit better into the ldap- server module which already contains some of this functionality * Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. When a specific service still requires those configuration objects the YaST module for that service should be able to handle those objects it self (we could still offer utils API for that in yast2-ldap/ldap-client). E.g. the user management related object should be configured from inside the yast2-users module. yast2- ldap-server could offer to create default objects during the initial LDAP server setup. * The Home Directories on This Machine checkbox seems to be better suite in the Users module as well. * The rest of the values which go to /etc/sysconfig/ldap could be written by yast2-ldap-servers. We still need to figure out how to setup /etc/sysconfig/ldap on machines which to not run the LDAP Server but need access to those settings. (yast2-mail, -dns-server, -dhcp-server) * Adapt the API: move the LDAP* functions from ldap-client (impact on other modules!) Relations: - related feature (feature/id: 313142) Discussion: #1: Jiří Suchomel (jsuchome) (2012-01-19 10:15:11) 1. Removing TLS/SSL is based on assumption that we configure SSSD only, which is feature 313142. 2. About The "Use LDAP but Disable Login" Radio Button: did we agree on some replacement of it? I cannot remember... #2: Jiří Suchomel (jsuchome) (2012-01-23 16:25:33) Added attachment proposal for simplified first screen (ldap-client- redesign2.png) #3: Jiří Suchomel (jsuchome) (2012-02-21 09:26:08) yast2-ldap-client-2.22.3 only offers SSSD configuration in UI, and the option to turn off TLS/SSL was removed. #5: Jiří Suchomel (jsuchome) (2012-02-21 11:37:45) (reply to #3) yast2-ldap-client-2.22.4 has the password policy configuration removed. Some parts were moved to yast2-ldap-server code (just svn), some other parts need to be added there. I've created a bug report to track it, see bnc#748004. #4: Jiří Suchomel (jsuchome) (2012-02-21 10:26:39) Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. Ralf, do you have any idea where it could/should be removed? Who can decide it? #6: Jiří Suchomel (jsuchome) (2012-04-19 08:52:07) OK, I've made most of the required changes in yast2-ldap-client, yast2- users and yast2-ldap-server. Ralf, could you take a look at current (Factory) versions of these and comment what else should be done? I mean mostly UI-wise, that API transition was not done. #7: Lukas Ocilka (locilka) (2013-07-30 14:38:43) (reply to #6) Ralf: ping #8: Ralf Haferkamp (rhafer) (2013-08-05 10:43:08) (reply to #7) Peter, could you take a look a this. I don't have any time left for this currently. #9: Joachim Werner (joachimwerner) (2013-08-08 12:45:24) Moving this forward for SLE 12. But important-only. We have a clear policy to focus on the new installer for GA and only improve YaST modules when time permits. #10: Jiri Srain (jsrain) (2013-08-08 12:49:58) (reply to #9) Agreed. This is definitely worth to spend spare cycles on. #11: Lukas Ocilka (locilka) (2013-09-09 16:41:11) Back to PjM: We currently don't have any LDAP expert available in team. Peter or Ralf could possibly work on that if they had time but they are not in Yast team. #12: Jiri Srain (jsrain) (2013-09-10 15:05:18) (reply to #11) Mili, any chance Ralf or Peter could implement this feature? -- openSUSE Feature: https://features.opensuse.org/313143

1 0

[New: openFATE 316528] allow build only for anonymous or for public auth
by fate_noreply＠suse.de 11 Sep '13

11 Sep '13

Feature added by: Dinar Valeev (k0da) Feature #316528, revision 1 Title: allow build only for anonymous or for public auth Buildservice: Unconfirmed Priority Requester: Important Requested by: Dinar Valeev (k0da) Partner organization: openSUSE.org Description: Would be nice to have OBS(build.opensuse.org instance) which allow anonymous builds. Or users authenticated by openID or Persona for example Use Case: Imagine there is a bug in openSUSE. For upstream to reproduce/fix the issue they need to have distro installed. Which is a rare case. with anonymous rights they could do just: osc co prj/pkg osc build ... osc chroot Business case (Partner benefit): openSUSE.org: see usecase -- openSUSE Feature: https://features.opensuse.org/316528

1 0

[openFATE 313143] YaST LDAP client refactor/cleanup
by fate_noreply＠suse.de 10 Sep '13

10 Sep '13

Feature changed by: Jiri Srain (jsrain) Feature #313143, revision 20 Title: YaST LDAP client refactor/cleanup openSUSE Distribution: Evaluation by project manager Priority Requester: Mandatory Projectmanager: Important Requested by: Ralf Haferkamp (rhafer) Partner organization: openSUSE.org Description: Jiri (jsuchome) and I recently discussed some cleanup work we'd like to see in the YaST ldap-client module. This feature lists the main items we'd like to see reworked to improve the Module: Remove no longer needed UI elements Candidates are: * The TLS/SSL checkbox (sssd has a hard requirement for SSL/TLS) * The "LDAP Version 2" checkbox in the advanced settings. (there is AFAIK no LDAPv2-only Server implementation left) * The "Use LDAP but Disable Login" Radio Button Restrict the UI to handle only really LDAP client related things Currently the UI contains quite some settings which are not strictly related to LDAP client (nss/pam) setup. Over the year ldap-client became a bit of a disposal site for all kinds of LDAP related things, which made the UI a bit hard to understand. We should move some things to YaST modules where make a better fit. This is mostly about the settings currently available in the "Administration Settings" Tab (in "Advanced Configuration") * The Password Policies settings seem to fit better into the ldap- server module which already contains some of this functionality * Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. When a specific service still requires those configuration objects the YaST module for that service should be able to handle those objects it self (we could still offer utils API for that in yast2-ldap/ldap-client). E.g. the user management related object should be configured from inside the yast2-users module. yast2- ldap-server could offer to create default objects during the initial LDAP server setup. * The Home Directories on This Machine checkbox seems to be better suite in the Users module as well. * The rest of the values which go to /etc/sysconfig/ldap could be written by yast2-ldap-servers. We still need to figure out how to setup /etc/sysconfig/ldap on machines which to not run the LDAP Server but need access to those settings. (yast2-mail, -dns-server, -dhcp-server) * Adapt the API: move the LDAP* functions from ldap-client (impact on other modules!) Relations: - related feature (feature/id: 313142) Discussion: #1: Jiří Suchomel (jsuchome) (2012-01-19 10:15:11) 1. Removing TLS/SSL is based on assumption that we configure SSSD only, which is feature 313142. 2. About The "Use LDAP but Disable Login" Radio Button: did we agree on some replacement of it? I cannot remember... #2: Jiří Suchomel (jsuchome) (2012-01-23 16:25:33) Added attachment proposal for simplified first screen (ldap-client- redesign2.png) #3: Jiří Suchomel (jsuchome) (2012-02-21 09:26:08) yast2-ldap-client-2.22.3 only offers SSSD configuration in UI, and the option to turn off TLS/SSL was removed. #5: Jiří Suchomel (jsuchome) (2012-02-21 11:37:45) (reply to #3) yast2-ldap-client-2.22.4 has the password policy configuration removed. Some parts were moved to yast2-ldap-server code (just svn), some other parts need to be added there. I've created a bug report to track it, see bnc#748004. #4: Jiří Suchomel (jsuchome) (2012-02-21 10:26:39) Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. Ralf, do you have any idea where it could/should be removed? Who can decide it? #6: Jiří Suchomel (jsuchome) (2012-04-19 08:52:07) OK, I've made most of the required changes in yast2-ldap-client, yast2- users and yast2-ldap-server. Ralf, could you take a look at current (Factory) versions of these and comment what else should be done? I mean mostly UI-wise, that API transition was not done. #7: Lukas Ocilka (locilka) (2013-07-30 14:38:43) (reply to #6) Ralf: ping #8: Ralf Haferkamp (rhafer) (2013-08-05 10:43:08) (reply to #7) Peter, could you take a look a this. I don't have any time left for this currently. #9: Joachim Werner (joachimwerner) (2013-08-08 12:45:24) Moving this forward for SLE 12. But important-only. We have a clear policy to focus on the new installer for GA and only improve YaST modules when time permits. #10: Jiri Srain (jsrain) (2013-08-08 12:49:58) (reply to #9) Agreed. This is definitely worth to spend spare cycles on. #11: Lukas Ocilka (locilka) (2013-09-09 16:41:11) Back to PjM: We currently don't have any LDAP expert available in team. Peter or Ralf could possibly work on that if they had time but they are not in Yast team. + #12: Jiri Srain (jsrain) (2013-09-10 15:05:18) (reply to #11) + Mili, any chance Ralf or Peter could implement this feature? -- openSUSE Feature: https://features.opensuse.org/313143

1 0

[openFATE 300688] Show virtual keyboard on TabletPC during installation
by fate_noreply＠suse.de 10 Sep '13

10 Sep '13

Feature changed by: Lukas Ocilka (locilka) Feature #300688, revision 61 Title: Show virtual keyboard on TabletPC during installation openSUSE-10.2: Rejected by Jiri Srain (jsrain) reject date: 2006-09-25 14:06:21 reject reason: Not enough resources. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Edith Parzefall (emapedl) reject date: 2007-07-24 14:21:32 reject reason: Sorry, not doable for 10.3. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Michael Löffler (michl19) reject date: 2008-01-11 16:39:04 reject reason: out of scope for openSUSE Priority Requester: Mandatory openSUSE-11.2: Rejected by Michael Löffler (michl19) reject date: 2009-04-16 12:27:27 reject reason: tablet PC not in scope for 11.2 Priority Requester: Mandatory Requested by: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: Tablet PCs are normally produced in two kinds of flavours: Convertibles, which have a keyboard, and Slates, which have none (only pens or touchscreens). If a user installs a Slate, he has to press e.g. buttons without having a keyboard to do it. Additionally he has no mouse device (except his pen) to press buttons. To do so, two ways are possible: Either using some kind of graffiti scribbling, which makes entering e. g. the password an adventure, or by providing a virtual keyboard where the user can select the characters. The second possibility is far superior and also used by Windows. It should be simply to blend xvkbd into the screen. Only possible problems: If a 800x600 resolution is used, the display is really small for both Yast and the keyboard. + References: + Qt virtual keyboard (http://www.qtcentre.org/threads/49181-virtual-keyboard-in-QT-Application?hi…) Discussion: #3: Edith Parzefall (emapedl) (2006-09-20 17:04:28) Jiri, do you see any chance to have it done in your team? Otherwise, I'd reject it. #6: Stephan Kulow (coolo) (2008-01-11 13:50:29) I would think that such devices are out of context for openSUSE 11.0, but asking Michl. How would this look like? Would the xvkbd always be visible and yast screen reduced accordingly? #7: Michael Löffler (michl19) (2008-01-11 16:38:08) As long as this is not required by SLED this is out of scope for openSUSE. #9: Michael Löffler (michl19) (2008-01-11 17:11:57) (reply to #8) Even vision and innovation need to be prioritized. Correct me if I'm wrong - but tablet PC still has a very minor market share. #10: Guy Lunardi (glunardi) (2008-01-18 17:34:09) Gartner projects 5% to 20% market penetration for Tablet PCs in the Healthcare. It is positioned as: "Tablet PCs meet all the criteria for a notebook PC and are equipped with a pen and an on-screen digitizer". "The tablet PC is solid and mature for vertical applications where it solves a specific problem. Of course there are 2 kinds of tablets, with physical keyboard and without (slab). I had to install openSUSE 10.3 on a slab myself and must admit that on-screen would have been nice. Is there an engineering effort estimate that could be looked at before we reject it for SLED11? #11: Stefan Behlert (sbehlert) (2008-05-21 21:39:58) (reply to #10) Duncan, any effort estimation? #13: Guy Lunardi (glunardi) (2008-06-23 11:44:51) (reply to #11) As we discussed, support for tablet is primarly critical at runtime. if we can add support for the install, that would be great even for accessibility reasons. I think we should focus our resources on making sure that tablets work well once the system is installed. #14: Duncan Mac-Vicar (dmacvicar) (2008-11-18 13:38:12) (reply to #13) Sure, but this was rejected because there are no resources to do it. So what did we had to drop in order to make it? Without reprioritization there is nothing we can do. I will provide an effort estimation for a next cycle. Estimating the effort here means basically prototyping it, and that just can't be done. #16: Matthias Nagorni (mnagorni) (2009-08-24 13:16:36) As long as it can be installed via USB keyboard this is no more than "nice to have". #17: Barry Nichols (barry_nichols) (2010-07-15 02:50:14) (reply to #16) Providing the user has a spare USB keyboard, or is willing to buy one simply to enable them to perform the installation process. I believe a user would be more likely to use another OS than to buy a keyboard. It might be worth considering for the next release, especially as tablet PCs are becoming more popular. -- openSUSE Feature: https://features.opensuse.org/300688

1 0

[openFATE 313143] YaST LDAP client refactor/cleanup
by fate_noreply＠suse.de 09 Sep '13

09 Sep '13

Feature changed by: Lukas Ocilka (locilka) Feature #313143, revision 19 Title: YaST LDAP client refactor/cleanup - openSUSE Distribution: Evaluation by engineering manager + openSUSE Distribution: Evaluation by project manager Priority Requester: Mandatory Projectmanager: Important Requested by: Ralf Haferkamp (rhafer) Partner organization: openSUSE.org Description: Jiri (jsuchome) and I recently discussed some cleanup work we'd like to see in the YaST ldap-client module. This feature lists the main items we'd like to see reworked to improve the Module: Remove no longer needed UI elements Candidates are: * The TLS/SSL checkbox (sssd has a hard requirement for SSL/TLS) * The "LDAP Version 2" checkbox in the advanced settings. (there is AFAIK no LDAPv2-only Server implementation left) * The "Use LDAP but Disable Login" Radio Button Restrict the UI to handle only really LDAP client related things Currently the UI contains quite some settings which are not strictly related to LDAP client (nss/pam) setup. Over the year ldap-client became a bit of a disposal site for all kinds of LDAP related things, which made the UI a bit hard to understand. We should move some things to YaST modules where make a better fit. This is mostly about the settings currently available in the "Administration Settings" Tab (in "Advanced Configuration") * The Password Policies settings seem to fit better into the ldap- server module which already contains some of this functionality * Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. When a specific service still requires those configuration objects the YaST module for that service should be able to handle those objects it self (we could still offer utils API for that in yast2-ldap/ldap-client). E.g. the user management related object should be configured from inside the yast2-users module. yast2- ldap-server could offer to create default objects during the initial LDAP server setup. * The Home Directories on This Machine checkbox seems to be better suite in the Users module as well. * The rest of the values which go to /etc/sysconfig/ldap could be written by yast2-ldap-servers. We still need to figure out how to setup /etc/sysconfig/ldap on machines which to not run the LDAP Server but need access to those settings. (yast2-mail, -dns-server, -dhcp-server) * Adapt the API: move the LDAP* functions from ldap-client (impact on other modules!) Relations: - related feature (feature/id: 313142) Discussion: #1: Jiří Suchomel (jsuchome) (2012-01-19 10:15:11) 1. Removing TLS/SSL is based on assumption that we configure SSSD only, which is feature 313142. 2. About The "Use LDAP but Disable Login" Radio Button: did we agree on some replacement of it? I cannot remember... #2: Jiří Suchomel (jsuchome) (2012-01-23 16:25:33) Added attachment proposal for simplified first screen (ldap-client- redesign2.png) #3: Jiří Suchomel (jsuchome) (2012-02-21 09:26:08) yast2-ldap-client-2.22.3 only offers SSSD configuration in UI, and the option to turn off TLS/SSL was removed. #5: Jiří Suchomel (jsuchome) (2012-02-21 11:37:45) (reply to #3) yast2-ldap-client-2.22.4 has the password policy configuration removed. Some parts were moved to yast2-ldap-server code (just svn), some other parts need to be added there. I've created a bug report to track it, see bnc#748004. #4: Jiří Suchomel (jsuchome) (2012-02-21 10:26:39) Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. Ralf, do you have any idea where it could/should be removed? Who can decide it? #6: Jiří Suchomel (jsuchome) (2012-04-19 08:52:07) OK, I've made most of the required changes in yast2-ldap-client, yast2- users and yast2-ldap-server. Ralf, could you take a look at current (Factory) versions of these and comment what else should be done? I mean mostly UI-wise, that API transition was not done. #7: Lukas Ocilka (locilka) (2013-07-30 14:38:43) (reply to #6) Ralf: ping #8: Ralf Haferkamp (rhafer) (2013-08-05 10:43:08) (reply to #7) Peter, could you take a look a this. I don't have any time left for this currently. #9: Joachim Werner (joachimwerner) (2013-08-08 12:45:24) Moving this forward for SLE 12. But important-only. We have a clear policy to focus on the new installer for GA and only improve YaST modules when time permits. #10: Jiri Srain (jsrain) (2013-08-08 12:49:58) (reply to #9) Agreed. This is definitely worth to spend spare cycles on. + #11: Lukas Ocilka (locilka) (2013-09-09 16:41:11) + Back to PjM: We currently don't have any LDAP expert available in team. + Peter or Ralf could possibly work on that if they had time but they are + not in Yast team. -- openSUSE Feature: https://features.opensuse.org/313143

1 0

[New: openFATE 316466] place default memory limit on processes within desktop session
by fate_noreply＠suse.de 05 Sep '13

05 Sep '13

Feature added by: Adam Spiers (aspiers) Feature #316466, revision 1 Title: place default memory limit on processes within desktop session Requested by: Adam Spiers (aspiers) Partner organization: openSUSE.org Description: It's currently possible for a memory leak in a userspace process to push a system far enough into swap that it basically results in the system being unusable for a significant amount of time. google-chrome, xfce4-panel, virt-manager, and nm-applet are a few recent examples which spring to mind. When kswapd is heavily stressed, logging in to the box to run top and kill some processes can take minutes or longer in the worst case. Maybe this could be argued to be a kernel bug, but ultimately I guess any kind of heavy swapping is going to kill performance. So instead of *solely* depending on the kernel to behave perfectly in low memory situations, it seems sensible to have some sort of preventative measure which would defend against buggy userspace processes. Therefore I suggest that desktop sessions should be tuned via cgroups to impose a default memory limit (RSS? VSS? I'm not sure which is best) of something like 80% of available RAM for any normal process, and then offer some kind of whitelist mechanism for processes which are expected to require a large amount of RAM. The ideal UX would be that if a desktop process hits the limit, a dialog box would pop up in the same session saying "This process is requesting more than $x RAM. This could be required for a genuine reason, or could be due to a memory leak. Deny / Allow / Always Allow". I'm not sure whether cgroups supports a mechanism for triggering userspace events like this, but if there's some way to achieve that, it would be great! Business case (Partner benefit): openSUSE.org: This would help promote openSUSE as a robust, reliable distribution, and the cgroups suggestion sounds like a pretty high reward to effort ratio which turns technical capability into practical advantage. (The dialog idea would probably take a lot more effort.) -- openSUSE Feature: https://features.opensuse.org/316466

1 1