November 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306315] Improve PK/zypper/YaST Big Lock
by fate_noreply＠suse.de 07 Nov '09

07 Nov '09

Feature changed by: Ralph Ulrich (ulenrich) Feature #306315, revision 7 Title: Improve PK/zypper/YaST Big Lock openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:45:36 reject reason: no resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Currently, execution of any action by one of the package management tools blocks all others, in a "big lock" fashion". This is entirely acceptable when I am doing something with YaST, or running the PK applet, but it is very fastidious when it is due to background activity. Running zypper and seeing that lock message when nothing is being run by the user is very annoying (and is really the same for Yum on RHEL - but it still sucks :-) Can we improve the way PK refreshing causes everything else to lock up? I must say I expect upstream to be doing something about this... References: http://lists.opensuse.org/zypp-devel/2008-03/msg00075.html https://bugzilla.novell.com/show_bug.cgi?id=551761 Business case (Partner benefit): openSUSE.org: The lock interferes with Administrator activity at random moments, and is very aggravating. It would be a competitive detail over RHEL, as well as a customer satisfaction item. Discussion: #1: Federico Lucifredi (flucifredi) (2009-03-30 21:13:47) I am somewhat reluctant to give this an M, as I do not know if something can actually be done to improve this. It would certainly warrant an M if a good solution can be devised, as this is really annoying on both SLES and RHEL, and it would make us look good in the comparison. #2: Ján Kupec (jkupec) (2009-11-06 10:30:50) Even if one zypp app is running, one should still be able to use the other in read-only mode (searching, reporting needed updates from current metadata, etc.). + #3: Ralph Ulrich (ulenrich) (2009-11-07 01:01:08) + This would be really cheap a read only zypper: + rypper: only read only action enabled + Benefit: I can do some working tasks with zypper and while this works I + am able to inform myself using: + rypper se -s something -- openSUSE Feature: https://features.opensuse.org/306315

1 0

[openFATE 305657] finer grained PolicyKit support for Networkmanager
by fate_noreply＠suse.de 06 Nov '09

06 Nov '09

Feature changed by: Ludwig Nussel (lnussel) Feature #305657, revision 54 Title: finer grained PolicyKit support for Networkmanager openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Desirable Requested by: Ludwig Nussel (lnussel) Description: NetworkManager currently only supports one PolicyKit privilege. That is whether a user is allowed to modify administrator defined connections or not. There is no way to disallow users to define their own network configurations. NetworkManager should at least support one additional PolicyKit privilege that defines whether or not users are allowed to bring their own network configuration or whether they mere are allowed to use administrator defined ones. Use Case: - disallow workers on centrally administered machines to configure different network settings - protect home users that only ever connect to a few well known nets from accidently changing their setup Discussion: #1: Matthias Nagorni (mnagorni) (2009-08-21 14:26:22) If this can be done with little effort I would be even tempted to rate it Mandatory. #2: Stefan Behlert (sbehlert) (2009-08-25 16:37:57) Alex, is there soemone on your team who could look at that? MAybe with some support form Tambet? #3: Li Bin (binli) (2009-08-26 05:58:01) I and lance wang would like to take care of it. We still don't know the requirement clearly. 1. disallow workers on centrally administered machines to configure different network settings The workers mean the users in administered machines? Does it right that when workers configure network settings it prompt they are no permission? If so I thought we could change the PolicyKit's configuration file to complete it. 2. protect home users that only ever connect to a few well known nets from accidently changing their setup How to distinguish home users from workers? Does it mean don't allow the user to configure the other users connections? #4: Ludwig Nussel (lnussel) (2009-08-26 08:40:53) (reply to #3) Currently there's only org.freedesktop.network-manager-settings.system. modify, introduce something like org.freedesktop.network-manager- settings.user.modify so NM can determine whether it should accept user settings. #16: Wang Lance (lzwang) (2009-09-25 11:26:20) (reply to #4) Hi Ludwig Nussel I have added the following policy action: org.freedesktop.network-manager-settings.user.wired.apply org.freedesktop.network-manager-settings.user.wireless.apply org.freedesktop.network-manager-settings.user.mobile.apply org.freedesktop.network-manager-settings.user.vpn.apply org.freedesktop.network-manager-settings.user.dsl.apply . NM now can determine whether it should apply the user settings to devices by type. Does the implementation meet your request? I need your feedback to determine what should to do next step. Thanks, Lance Wang #17: Ludwig Nussel (lnussel) (2009-09-25 11:58:50) (reply to #16) Sure, that's even more than I had wished for. Would it be possible to also have a separate privilege for the connection sharing thingy? In contrast to the other configurations that one also messes with iptables and starts a DHCP daemon. #5: JP Rosevear (jproseve) (2009-08-26 17:06:51) (reply to #3) My suggestion would be to look at something like the following: org. freedesktop.network-manager-settings.system.modify org.freedesktop. network-manager-settings.system.add org.freedesktop.network-manager- settings.system.delete and the same for .user - you may even want to specifically allow or disallow adding for specific network types like wired, wireless, etc. You probably also want to have the ability to enable/disable wireless in general and enable/disable networking covered. You can default all of these to the current settings, but adding these would allow more lockdown opportunities. #6: Li Bin (binli) (2009-08-31 11:22:12) Well, We'll works on this feature in this week, know about the PolicyKit and NetworkManager, write the patch if time is okay. Tambet, Do you have any idea about this feature? #7: Luis Medinas (lmedinas) (2009-08-31 18:40:51) (reply to #6) Might worth looking at NM 0.8 (git master), it supports the latest polkit-1 and it should be released before 11.2. Maybe some of this features were introduced. #8: Tambet Ingo (tambet) (2009-09-01 09:40:05) (reply to #7) NM 0.8 will not be out before 11.2, it'll be out for the next Fedora release which will happen after 11.2. Also, current git master does not have any work for this feature, it's just been converted to use the newer, incompatible polkit API. #9: Tambet Ingo (tambet) (2009-09-01 09:43:56) (reply to #6) The upstream has been planning on having similar feature for a while now, but no work has been done on it yet. I strongly suggest to have a discussion with the upstream maintainer before any work gets done, otherwise our effort might end up thrown away as soon as upstream implements it. #10: Li Bin (binli) (2009-09-01 09:14:24) Yes, I talk with the upstream today, just wait for response. You can follow it from below link. Thanks! http://mail.gnome.org/archives/networkmanager-list/2009-September/date.html #11: Stephan Kulow (coolo) (2009-09-07 13:39:17) (reply to #10) didn't see a lot of replies. #12: Li Bin (binli) (2009-09-10 05:24:05) The upstream maintainer Dan already reply this issue, and it's no user case for seperating add, modify and delete permission, and the others was agreed. Lanc wang with me work the sled11 and upstream now, we'll provide a patch in this week. #13: Wang Lance (lzwang) (2009-09-15 08:10:43) Hi I add five policy like the following : org.freedesktop.network-manager- settings.system.wired.modify org.freedesktop.network-manager-settings. system.wireless.modify org.freedesktop.network-manager-settings.system. mobile.modify org.freedesktop.network-manager-settings.system.vpn. modify org.freedesktop.network-manager-settings.system.dsl.modify. As you know there will be one policy one type. I make a patch which works. But I feel a little confused on the user settings. As the user settings are saved in the gconf, so adding someting like manager- settings.user.*.modify make no sense. As far as I know user can always edit their gconf settings. I think what should be done may be the policy that determine if the users can apply their settings to the system devices throught dbus. Given we do it like that, should the nm-applet display the user setting in the menu, when a normal user can not apply his or her settings to system devices? I think it is better that nm-applet show both system settings and user settings, and it will show error dialog if a user try to apply user settings when the user does not have the right do that. Hi Tambet, what do you think? #14: Li Bin (binli) (2009-09-17 11:18:37) (reply to #13) Tambet reply in the mailinglist, we just lock the /system/networking path in gconf and the settings can't be changed. #15: Michael Meeks (michael_meeks) (2009-09-23 16:55:40) We should also add the case mentioned in bug #522742 - to allow disabling the "Create new wireless network" functionality. This is of particular concern to the security team, and I'd like to see it addressed as part of the same work if possible. Otherwise, this looks great - thanks Li Bin :-) #18: Li Bin (binli) (2009-09-25 12:03:28) (reply to #15) Michael, I've viewed the bug#522742, it talk more about sharing, and we don't need to disable "Create new wireless network", user can add it, but when they wanna to apply it by click the connection, check org. freedesktop.network-manager-settings.user.wireless.apply permission like the Lance describe in #16. Does it okay? #19: Michael Meeks (michael_meeks) (2009-09-28 10:10:26) (reply to #18) No - connecting to a new wireless network is -very- different from sharing all your existing connections over your current wireless network; I can see why people would want to allow one and not allow the other. We should (ideally) have a different policy setting for this - if possible. Thanks #25: Wang Lance (lzwang) (2009-10-28 11:49:58) (reply to #15) Hi Michael I have read bnc #522742. And it is about sharing network. I wonder that why only the "Create new wireless network" need a policy, since all kinds type connection can be shared. As far as I know in nm-applet 7.0 the "Create new wireless network" is only for adhoc wireless connection. Did you mean that sharing adhoc wireless connection have security problem? And other type connections do not ? Thanks, Lance Wang. #20: Tanja Roth (ta-ro) (2009-10-05 15:01:26) Can you please confirm what the final policy names (identifiers) are going to be for 11.2 and what can be influenced with them? (a short description as available from the Description field in polkit-gnome- authorization would be sufficient). I would like to mention this in the 11.2 docs about NetworkManager, but so far, I only found the one policy that relates to modifying administrator defined connections (org.freedesktop.network-manager- settings.system.modify). From your comments above I'm not sure if the names mentioned in #16 are the final ones for the newly added policies (and if the list is complete). Please advise asap as the translation deadline for this chapter is approaching. Thanks! #22: (binli) (2009-10-12 11:27:53) (reply to #20) Tanja, Just come back from holiday, sorry for late. Now this feature is still not in the upstream, I'm still working on it. I prepare to seperate the permission into more fined like, org.freedesktop.network-manager-settings.system.wireless.modify - Modify system wired connections org.freedesktop.network-manager-settings.system.wired.modify - Modify system wireless connections the description follow the policy. The #16 is now for the SLED 11-SP1 for temporary resolving usercase, I'm not sure if it could be received by upstream which is used for 11.2. So what's your translation deadline? I'll inform you when I confirm it with upstream. #23: (ta-ro) (2009-10-12 12:25:30) (reply to #22) Lin Bi, thanks very much for clarifying! :) Our localization deadline is Oct 15th but as the files have to go through language proofreading before, I have to finish the chapter today, I'm afraid. But don't worry, to be on the safe side (whatever the upstream decision may be), we can handle it as follows: for now, I'll only mention that there *are* policies for NetworkManager and where to find them in PolicyKit. We can then add more details for the next release of the docs (presumably SLE 11 SP1). #24: (ta-ro) (2009-10-12 13:18:21) (reply to #23) Removing the needinfo status. #26: Wang Lance (lzwang) (2009-11-02 08:51:11) Hi Ludwig Nussel Could you test this new functions in SLED11. I made the packages with the function. These are the URLs https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… I implemented the following policy: "org.freedesktop.network-manager-settings.system.wired.modify" "org. freedesktop.network-manager-settings.system.wireless.modify" "org. freedesktop.network-manager-settings.system.mobile.modify" "org. freedesktop.network-manager-settings.system.vpn.modify" "org. freedesktop.network-manager-settings.system.dsl.modify" "org.freedesktop.network-manager-settings.user.wired.apply" "org. freedesktop.network-manager-settings.user.wireless.apply" "org. freedesktop.network-manager-settings.user.mobile.apply" "org. freedesktop.network-manager-settings.user.vpn.apply" "org.freedesktop. network-manager-settings.user.dsl.apply" . And *.modify are the policy for the editing adding and deleting of the system connections. And *.apply are the policy for applying the user connection to activate the devices. You can see the default settings in /usr/share/PolicyKit/policy/org. freedesktop.network-manager-settings.system.policy, which make the NM behave like the one without those policy. Thanks, Lance Wang #27: Ludwig Nussel (lnussel) (2009-11-03 16:17:45) (reply to #26) I've tried it on openSUSE 11.1 now. Works great AFAICT. However I think the usability could be enhanced by creating system connections by default, at least when user connections are restricted. That way the user would not need to authenticate each time he wants to connect. wrt separate policy for shared connections, I think that should be doable by checking another condition in is_user_request_connection_type_authorized(), right? #28: Wang Lance (lzwang) (2009-11-06 10:52:31) (reply to #27) Hi Ludwig I have a look at the request "creating system connections by default". I think it could not be done like that. 1. Connections created by the users include personal secrets which should not be saved in system scope without the permission of the owner. Because in the NetworkManager the password in system connection is saved without encrypted. 2. Saving a connection as a system one means another authentication which control by org.freedesktop.network-manager- settings.system.*.modify. 3. In the NetworkManager 0.7 activation of a system connection will not ask the console user about any kind secrets settings. That will make user confused if he types the wrong password first time. 4. Maybe it can be implemented in the way that after the user connection is successfully applied, the nm-applet change the user connection to a system connection. But the way is very ugly I think. And there is a way the user would not need to authenticate each time he wants to connect if he have the privilege of modifying system connection. He can change a connection scope from user to system in nm- connection-editor. 1. If the computer is a personal one, the user who is the administrator can set all the policy settings to default. That NetworkManager can apply any kind connection. 2. If the computer is centrally controlled, the administrator is responsible for settings the default system connections for all users. 3. If there is specific user should be given some privileges, the administrator can set them in the polkit. wrt separate policy for shared connections, yes they are doable. I think the policy should be like these org. freedesktop.network-manager-settings.user.*.share . And how do you think the default settings of these policy ? #29: Wang Lance (lzwang) (2009-11-06 11:02:46) (reply to #27) (sorry. repeat reply for missing format) Hi Ludwig I have a look at the request "creating system connections by default". I think it could not be done like that. 1) Connections created by the users include personal secrets which should not be saved in system scope without the permission of the owner. Because in the NetworkManager the password in system connection is saved without encrypted. 2) Saving a connection as a system one means another authentication which control by org.freedesktop.network-manager-settings.system.*. modify. 3) In the NetworkManager 0.7 activation of a system connection will not ask the console user about any kind secrets settings. That will make user confused if he types the wrong password first time. 4) Maybe it can be implemented in the way that after the user connection is successfully applied, the nm-applet change the user connection to a system connection. But the way is very ugly I think. And there is a way the user would not need to authenticate each time he wants to connect if he has the privilege of modifying system connection. He can change a connection scope from user to system in nm- connection-editor. 1) If the computer is a personal one, the user who is the administrator can set all the policy settings to default. That NetworkManager can apply any kind connection. 2) If the computer is centrally controlled, the administrator is responsible for settings the default system connections for all users. 3) If there is specific user should be given some privileges, the administrator can set them in the polkit. wrt separate policy for shared connections, yes they are doable. I think the policy should be like these org.freedesktop.network-manager-settings.user.*.share . And how do you think the default settings of these policy ? + #30: Ludwig Nussel (lnussel) (2009-11-06 11:09:33) (reply to #29) + Ok. I already suspected that the system setting thing is hard to do + with NM's architecture. + Wrt share settings I'd set them to auth_admin_keep_always by default. + However, the settings you add to the package get overwritten by polkit- + default-privs anyways to be able to use different settings for + 'standard' and 'restrictive'. -- openSUSE Feature: https://features.opensuse.org/305657

1 0

[openFATE 305657] finer grained PolicyKit support for Networkmanager
by fate_noreply＠suse.de 06 Nov '09

06 Nov '09

Feature changed by: Wang Lance (lzwang) Feature #305657, revision 53 Title: finer grained PolicyKit support for Networkmanager openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Desirable Requested by: Ludwig Nussel (lnussel) Description: NetworkManager currently only supports one PolicyKit privilege. That is whether a user is allowed to modify administrator defined connections or not. There is no way to disallow users to define their own network configurations. NetworkManager should at least support one additional PolicyKit privilege that defines whether or not users are allowed to bring their own network configuration or whether they mere are allowed to use administrator defined ones. Use Case: - disallow workers on centrally administered machines to configure different network settings - protect home users that only ever connect to a few well known nets from accidently changing their setup Discussion: #1: Matthias Nagorni (mnagorni) (2009-08-21 14:26:22) If this can be done with little effort I would be even tempted to rate it Mandatory. #2: Stefan Behlert (sbehlert) (2009-08-25 16:37:57) Alex, is there soemone on your team who could look at that? MAybe with some support form Tambet? #3: Li Bin (binli) (2009-08-26 05:58:01) I and lance wang would like to take care of it. We still don't know the requirement clearly. 1. disallow workers on centrally administered machines to configure different network settings The workers mean the users in administered machines? Does it right that when workers configure network settings it prompt they are no permission? If so I thought we could change the PolicyKit's configuration file to complete it. 2. protect home users that only ever connect to a few well known nets from accidently changing their setup How to distinguish home users from workers? Does it mean don't allow the user to configure the other users connections? #4: Ludwig Nussel (lnussel) (2009-08-26 08:40:53) (reply to #3) Currently there's only org.freedesktop.network-manager-settings.system. modify, introduce something like org.freedesktop.network-manager- settings.user.modify so NM can determine whether it should accept user settings. #16: Wang Lance (lzwang) (2009-09-25 11:26:20) (reply to #4) Hi Ludwig Nussel I have added the following policy action: org.freedesktop.network-manager-settings.user.wired.apply org.freedesktop.network-manager-settings.user.wireless.apply org.freedesktop.network-manager-settings.user.mobile.apply org.freedesktop.network-manager-settings.user.vpn.apply org.freedesktop.network-manager-settings.user.dsl.apply . NM now can determine whether it should apply the user settings to devices by type. Does the implementation meet your request? I need your feedback to determine what should to do next step. Thanks, Lance Wang #17: Ludwig Nussel (lnussel) (2009-09-25 11:58:50) (reply to #16) Sure, that's even more than I had wished for. Would it be possible to also have a separate privilege for the connection sharing thingy? In contrast to the other configurations that one also messes with iptables and starts a DHCP daemon. #5: JP Rosevear (jproseve) (2009-08-26 17:06:51) (reply to #3) My suggestion would be to look at something like the following: org. freedesktop.network-manager-settings.system.modify org.freedesktop. network-manager-settings.system.add org.freedesktop.network-manager- settings.system.delete and the same for .user - you may even want to specifically allow or disallow adding for specific network types like wired, wireless, etc. You probably also want to have the ability to enable/disable wireless in general and enable/disable networking covered. You can default all of these to the current settings, but adding these would allow more lockdown opportunities. #6: Li Bin (binli) (2009-08-31 11:22:12) Well, We'll works on this feature in this week, know about the PolicyKit and NetworkManager, write the patch if time is okay. Tambet, Do you have any idea about this feature? #7: Luis Medinas (lmedinas) (2009-08-31 18:40:51) (reply to #6) Might worth looking at NM 0.8 (git master), it supports the latest polkit-1 and it should be released before 11.2. Maybe some of this features were introduced. #8: Tambet Ingo (tambet) (2009-09-01 09:40:05) (reply to #7) NM 0.8 will not be out before 11.2, it'll be out for the next Fedora release which will happen after 11.2. Also, current git master does not have any work for this feature, it's just been converted to use the newer, incompatible polkit API. #9: Tambet Ingo (tambet) (2009-09-01 09:43:56) (reply to #6) The upstream has been planning on having similar feature for a while now, but no work has been done on it yet. I strongly suggest to have a discussion with the upstream maintainer before any work gets done, otherwise our effort might end up thrown away as soon as upstream implements it. #10: Li Bin (binli) (2009-09-01 09:14:24) Yes, I talk with the upstream today, just wait for response. You can follow it from below link. Thanks! http://mail.gnome.org/archives/networkmanager-list/2009-September/date.html #11: Stephan Kulow (coolo) (2009-09-07 13:39:17) (reply to #10) didn't see a lot of replies. #12: Li Bin (binli) (2009-09-10 05:24:05) The upstream maintainer Dan already reply this issue, and it's no user case for seperating add, modify and delete permission, and the others was agreed. Lanc wang with me work the sled11 and upstream now, we'll provide a patch in this week. #13: Wang Lance (lzwang) (2009-09-15 08:10:43) Hi I add five policy like the following : org.freedesktop.network-manager- settings.system.wired.modify org.freedesktop.network-manager-settings. system.wireless.modify org.freedesktop.network-manager-settings.system. mobile.modify org.freedesktop.network-manager-settings.system.vpn. modify org.freedesktop.network-manager-settings.system.dsl.modify. As you know there will be one policy one type. I make a patch which works. But I feel a little confused on the user settings. As the user settings are saved in the gconf, so adding someting like manager- settings.user.*.modify make no sense. As far as I know user can always edit their gconf settings. I think what should be done may be the policy that determine if the users can apply their settings to the system devices throught dbus. Given we do it like that, should the nm-applet display the user setting in the menu, when a normal user can not apply his or her settings to system devices? I think it is better that nm-applet show both system settings and user settings, and it will show error dialog if a user try to apply user settings when the user does not have the right do that. Hi Tambet, what do you think? #14: Li Bin (binli) (2009-09-17 11:18:37) (reply to #13) Tambet reply in the mailinglist, we just lock the /system/networking path in gconf and the settings can't be changed. #15: Michael Meeks (michael_meeks) (2009-09-23 16:55:40) We should also add the case mentioned in bug #522742 - to allow disabling the "Create new wireless network" functionality. This is of particular concern to the security team, and I'd like to see it addressed as part of the same work if possible. Otherwise, this looks great - thanks Li Bin :-) #18: Li Bin (binli) (2009-09-25 12:03:28) (reply to #15) Michael, I've viewed the bug#522742, it talk more about sharing, and we don't need to disable "Create new wireless network", user can add it, but when they wanna to apply it by click the connection, check org. freedesktop.network-manager-settings.user.wireless.apply permission like the Lance describe in #16. Does it okay? #19: Michael Meeks (michael_meeks) (2009-09-28 10:10:26) (reply to #18) No - connecting to a new wireless network is -very- different from sharing all your existing connections over your current wireless network; I can see why people would want to allow one and not allow the other. We should (ideally) have a different policy setting for this - if possible. Thanks #25: Wang Lance (lzwang) (2009-10-28 11:49:58) (reply to #15) Hi Michael I have read bnc #522742. And it is about sharing network. I wonder that why only the "Create new wireless network" need a policy, since all kinds type connection can be shared. As far as I know in nm-applet 7.0 the "Create new wireless network" is only for adhoc wireless connection. Did you mean that sharing adhoc wireless connection have security problem? And other type connections do not ? Thanks, Lance Wang. #20: Tanja Roth (ta-ro) (2009-10-05 15:01:26) Can you please confirm what the final policy names (identifiers) are going to be for 11.2 and what can be influenced with them? (a short description as available from the Description field in polkit-gnome- authorization would be sufficient). I would like to mention this in the 11.2 docs about NetworkManager, but so far, I only found the one policy that relates to modifying administrator defined connections (org.freedesktop.network-manager- settings.system.modify). From your comments above I'm not sure if the names mentioned in #16 are the final ones for the newly added policies (and if the list is complete). Please advise asap as the translation deadline for this chapter is approaching. Thanks! #22: (binli) (2009-10-12 11:27:53) (reply to #20) Tanja, Just come back from holiday, sorry for late. Now this feature is still not in the upstream, I'm still working on it. I prepare to seperate the permission into more fined like, org.freedesktop.network-manager-settings.system.wireless.modify - Modify system wired connections org.freedesktop.network-manager-settings.system.wired.modify - Modify system wireless connections the description follow the policy. The #16 is now for the SLED 11-SP1 for temporary resolving usercase, I'm not sure if it could be received by upstream which is used for 11.2. So what's your translation deadline? I'll inform you when I confirm it with upstream. #23: (ta-ro) (2009-10-12 12:25:30) (reply to #22) Lin Bi, thanks very much for clarifying! :) Our localization deadline is Oct 15th but as the files have to go through language proofreading before, I have to finish the chapter today, I'm afraid. But don't worry, to be on the safe side (whatever the upstream decision may be), we can handle it as follows: for now, I'll only mention that there *are* policies for NetworkManager and where to find them in PolicyKit. We can then add more details for the next release of the docs (presumably SLE 11 SP1). #24: (ta-ro) (2009-10-12 13:18:21) (reply to #23) Removing the needinfo status. #26: Wang Lance (lzwang) (2009-11-02 08:51:11) Hi Ludwig Nussel Could you test this new functions in SLED11. I made the packages with the function. These are the URLs https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… I implemented the following policy: "org.freedesktop.network-manager-settings.system.wired.modify" "org. freedesktop.network-manager-settings.system.wireless.modify" "org. freedesktop.network-manager-settings.system.mobile.modify" "org. freedesktop.network-manager-settings.system.vpn.modify" "org. freedesktop.network-manager-settings.system.dsl.modify" "org.freedesktop.network-manager-settings.user.wired.apply" "org. freedesktop.network-manager-settings.user.wireless.apply" "org. freedesktop.network-manager-settings.user.mobile.apply" "org. freedesktop.network-manager-settings.user.vpn.apply" "org.freedesktop. network-manager-settings.user.dsl.apply" . And *.modify are the policy for the editing adding and deleting of the system connections. And *.apply are the policy for applying the user connection to activate the devices. You can see the default settings in /usr/share/PolicyKit/policy/org. freedesktop.network-manager-settings.system.policy, which make the NM behave like the one without those policy. Thanks, Lance Wang #27: Ludwig Nussel (lnussel) (2009-11-03 16:17:45) (reply to #26) I've tried it on openSUSE 11.1 now. Works great AFAICT. However I think the usability could be enhanced by creating system connections by default, at least when user connections are restricted. That way the user would not need to authenticate each time he wants to connect. wrt separate policy for shared connections, I think that should be doable by checking another condition in is_user_request_connection_type_authorized(), right? #28: Wang Lance (lzwang) (2009-11-06 10:52:31) (reply to #27) Hi Ludwig I have a look at the request "creating system connections by default". I think it could not be done like that. 1. Connections created by the users include personal secrets which should not be saved in system scope without the permission of the owner. Because in the NetworkManager the password in system connection is saved without encrypted. 2. Saving a connection as a system one means another authentication which control by org.freedesktop.network-manager- settings.system.*.modify. 3. In the NetworkManager 0.7 activation of a system connection will not ask the console user about any kind secrets settings. That will make user confused if he types the wrong password first time. 4. Maybe it can be implemented in the way that after the user connection is successfully applied, the nm-applet change the user connection to a system connection. But the way is very ugly I think. And there is a way the user would not need to authenticate each time he wants to connect if he have the privilege of modifying system connection. He can change a connection scope from user to system in nm- connection-editor. 1. If the computer is a personal one, the user who is the administrator can set all the policy settings to default. That NetworkManager can apply any kind connection. 2. If the computer is centrally controlled, the administrator is responsible for settings the default system connections for all users. 3. If there is specific user should be given some privileges, the administrator can set them in the polkit. wrt separate policy for shared connections, yes they are doable. I think the policy should be like these org. freedesktop.network-manager-settings.user.*.share . And how do you think the default settings of these policy ? + #29: Wang Lance (lzwang) (2009-11-06 11:02:46) (reply to #27) + (sorry. repeat reply for missing format) + Hi Ludwig + I have a look at the request "creating system connections by default". + I think it could not be done like that. + 1) Connections created by the users include personal secrets which + should not be saved in system scope without the permission of the + owner. Because in the NetworkManager the password in system connection + is saved without encrypted. + 2) Saving a connection as a system one means another authentication + which control by org.freedesktop.network-manager-settings.system.*. + modify. + 3) In the NetworkManager 0.7 activation of a system connection will not + ask the console user about any kind secrets settings. That will make + user confused if he types the wrong password first time. + 4) Maybe it can be implemented in the way that after the user + connection is successfully applied, the nm-applet change the user + connection to a system connection. But the way is very ugly I think. + And there is a way the user would not need to authenticate each time he + wants to connect if he has the privilege of modifying system + connection. He can change a connection scope from user to system in nm- + connection-editor. + 1) If the computer is a personal one, the user who is the administrator + can set all the policy settings to default. That NetworkManager can + apply any kind connection. + 2) If the computer is centrally controlled, the administrator is + responsible for settings the default system connections for all + users. + 3) If there is specific user should be given some privileges, the + administrator can set them in the polkit. + wrt separate policy for shared connections, yes they are doable. I + think the policy should be like these + org.freedesktop.network-manager-settings.user.*.share + . + And how do you think the default settings of these policy ? -- openSUSE Feature: https://features.opensuse.org/305657

1 0

[openFATE 305657] finer grained PolicyKit support for Networkmanager
by fate_noreply＠suse.de 06 Nov '09

06 Nov '09

Feature changed by: Wang Lance (lzwang) Feature #305657, revision 52 Title: finer grained PolicyKit support for Networkmanager openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Desirable Requested by: Ludwig Nussel (lnussel) Description: NetworkManager currently only supports one PolicyKit privilege. That is whether a user is allowed to modify administrator defined connections or not. There is no way to disallow users to define their own network configurations. NetworkManager should at least support one additional PolicyKit privilege that defines whether or not users are allowed to bring their own network configuration or whether they mere are allowed to use administrator defined ones. Use Case: - disallow workers on centrally administered machines to configure different network settings - protect home users that only ever connect to a few well known nets from accidently changing their setup Discussion: #1: Matthias Nagorni (mnagorni) (2009-08-21 14:26:22) If this can be done with little effort I would be even tempted to rate it Mandatory. #2: Stefan Behlert (sbehlert) (2009-08-25 16:37:57) Alex, is there soemone on your team who could look at that? MAybe with some support form Tambet? #3: Li Bin (binli) (2009-08-26 05:58:01) I and lance wang would like to take care of it. We still don't know the requirement clearly. 1. disallow workers on centrally administered machines to configure different network settings The workers mean the users in administered machines? Does it right that when workers configure network settings it prompt they are no permission? If so I thought we could change the PolicyKit's configuration file to complete it. 2. protect home users that only ever connect to a few well known nets from accidently changing their setup How to distinguish home users from workers? Does it mean don't allow the user to configure the other users connections? #4: Ludwig Nussel (lnussel) (2009-08-26 08:40:53) (reply to #3) Currently there's only org.freedesktop.network-manager-settings.system. modify, introduce something like org.freedesktop.network-manager- settings.user.modify so NM can determine whether it should accept user settings. #16: Wang Lance (lzwang) (2009-09-25 11:26:20) (reply to #4) Hi Ludwig Nussel I have added the following policy action: org.freedesktop.network-manager-settings.user.wired.apply org.freedesktop.network-manager-settings.user.wireless.apply org.freedesktop.network-manager-settings.user.mobile.apply org.freedesktop.network-manager-settings.user.vpn.apply org.freedesktop.network-manager-settings.user.dsl.apply . NM now can determine whether it should apply the user settings to devices by type. Does the implementation meet your request? I need your feedback to determine what should to do next step. Thanks, Lance Wang #17: Ludwig Nussel (lnussel) (2009-09-25 11:58:50) (reply to #16) Sure, that's even more than I had wished for. Would it be possible to also have a separate privilege for the connection sharing thingy? In contrast to the other configurations that one also messes with iptables and starts a DHCP daemon. #5: JP Rosevear (jproseve) (2009-08-26 17:06:51) (reply to #3) My suggestion would be to look at something like the following: org. freedesktop.network-manager-settings.system.modify org.freedesktop. network-manager-settings.system.add org.freedesktop.network-manager- settings.system.delete and the same for .user - you may even want to specifically allow or disallow adding for specific network types like wired, wireless, etc. You probably also want to have the ability to enable/disable wireless in general and enable/disable networking covered. You can default all of these to the current settings, but adding these would allow more lockdown opportunities. #6: Li Bin (binli) (2009-08-31 11:22:12) Well, We'll works on this feature in this week, know about the PolicyKit and NetworkManager, write the patch if time is okay. Tambet, Do you have any idea about this feature? #7: Luis Medinas (lmedinas) (2009-08-31 18:40:51) (reply to #6) Might worth looking at NM 0.8 (git master), it supports the latest polkit-1 and it should be released before 11.2. Maybe some of this features were introduced. #8: Tambet Ingo (tambet) (2009-09-01 09:40:05) (reply to #7) NM 0.8 will not be out before 11.2, it'll be out for the next Fedora release which will happen after 11.2. Also, current git master does not have any work for this feature, it's just been converted to use the newer, incompatible polkit API. #9: Tambet Ingo (tambet) (2009-09-01 09:43:56) (reply to #6) The upstream has been planning on having similar feature for a while now, but no work has been done on it yet. I strongly suggest to have a discussion with the upstream maintainer before any work gets done, otherwise our effort might end up thrown away as soon as upstream implements it. #10: Li Bin (binli) (2009-09-01 09:14:24) Yes, I talk with the upstream today, just wait for response. You can follow it from below link. Thanks! http://mail.gnome.org/archives/networkmanager-list/2009-September/date.html #11: Stephan Kulow (coolo) (2009-09-07 13:39:17) (reply to #10) didn't see a lot of replies. #12: Li Bin (binli) (2009-09-10 05:24:05) The upstream maintainer Dan already reply this issue, and it's no user case for seperating add, modify and delete permission, and the others was agreed. Lanc wang with me work the sled11 and upstream now, we'll provide a patch in this week. #13: Wang Lance (lzwang) (2009-09-15 08:10:43) Hi I add five policy like the following : org.freedesktop.network-manager- settings.system.wired.modify org.freedesktop.network-manager-settings. system.wireless.modify org.freedesktop.network-manager-settings.system. mobile.modify org.freedesktop.network-manager-settings.system.vpn. modify org.freedesktop.network-manager-settings.system.dsl.modify. As you know there will be one policy one type. I make a patch which works. But I feel a little confused on the user settings. As the user settings are saved in the gconf, so adding someting like manager- settings.user.*.modify make no sense. As far as I know user can always edit their gconf settings. I think what should be done may be the policy that determine if the users can apply their settings to the system devices throught dbus. Given we do it like that, should the nm-applet display the user setting in the menu, when a normal user can not apply his or her settings to system devices? I think it is better that nm-applet show both system settings and user settings, and it will show error dialog if a user try to apply user settings when the user does not have the right do that. Hi Tambet, what do you think? #14: Li Bin (binli) (2009-09-17 11:18:37) (reply to #13) Tambet reply in the mailinglist, we just lock the /system/networking path in gconf and the settings can't be changed. #15: Michael Meeks (michael_meeks) (2009-09-23 16:55:40) We should also add the case mentioned in bug #522742 - to allow disabling the "Create new wireless network" functionality. This is of particular concern to the security team, and I'd like to see it addressed as part of the same work if possible. Otherwise, this looks great - thanks Li Bin :-) #18: Li Bin (binli) (2009-09-25 12:03:28) (reply to #15) Michael, I've viewed the bug#522742, it talk more about sharing, and we don't need to disable "Create new wireless network", user can add it, but when they wanna to apply it by click the connection, check org. freedesktop.network-manager-settings.user.wireless.apply permission like the Lance describe in #16. Does it okay? #19: Michael Meeks (michael_meeks) (2009-09-28 10:10:26) (reply to #18) No - connecting to a new wireless network is -very- different from sharing all your existing connections over your current wireless network; I can see why people would want to allow one and not allow the other. We should (ideally) have a different policy setting for this - if possible. Thanks #25: Wang Lance (lzwang) (2009-10-28 11:49:58) (reply to #15) Hi Michael I have read bnc #522742. And it is about sharing network. I wonder that why only the "Create new wireless network" need a policy, since all kinds type connection can be shared. As far as I know in nm-applet 7.0 the "Create new wireless network" is only for adhoc wireless connection. Did you mean that sharing adhoc wireless connection have security problem? And other type connections do not ? Thanks, Lance Wang. #20: Tanja Roth (ta-ro) (2009-10-05 15:01:26) Can you please confirm what the final policy names (identifiers) are going to be for 11.2 and what can be influenced with them? (a short description as available from the Description field in polkit-gnome- authorization would be sufficient). I would like to mention this in the 11.2 docs about NetworkManager, but so far, I only found the one policy that relates to modifying administrator defined connections (org.freedesktop.network-manager- settings.system.modify). From your comments above I'm not sure if the names mentioned in #16 are the final ones for the newly added policies (and if the list is complete). Please advise asap as the translation deadline for this chapter is approaching. Thanks! #22: (binli) (2009-10-12 11:27:53) (reply to #20) Tanja, Just come back from holiday, sorry for late. Now this feature is still not in the upstream, I'm still working on it. I prepare to seperate the permission into more fined like, org.freedesktop.network-manager-settings.system.wireless.modify - Modify system wired connections org.freedesktop.network-manager-settings.system.wired.modify - Modify system wireless connections the description follow the policy. The #16 is now for the SLED 11-SP1 for temporary resolving usercase, I'm not sure if it could be received by upstream which is used for 11.2. So what's your translation deadline? I'll inform you when I confirm it with upstream. #23: (ta-ro) (2009-10-12 12:25:30) (reply to #22) Lin Bi, thanks very much for clarifying! :) Our localization deadline is Oct 15th but as the files have to go through language proofreading before, I have to finish the chapter today, I'm afraid. But don't worry, to be on the safe side (whatever the upstream decision may be), we can handle it as follows: for now, I'll only mention that there *are* policies for NetworkManager and where to find them in PolicyKit. We can then add more details for the next release of the docs (presumably SLE 11 SP1). #24: (ta-ro) (2009-10-12 13:18:21) (reply to #23) Removing the needinfo status. #26: Wang Lance (lzwang) (2009-11-02 08:51:11) Hi Ludwig Nussel Could you test this new functions in SLED11. I made the packages with the function. These are the URLs https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… I implemented the following policy: "org.freedesktop.network-manager-settings.system.wired.modify" "org. freedesktop.network-manager-settings.system.wireless.modify" "org. freedesktop.network-manager-settings.system.mobile.modify" "org. freedesktop.network-manager-settings.system.vpn.modify" "org. freedesktop.network-manager-settings.system.dsl.modify" "org.freedesktop.network-manager-settings.user.wired.apply" "org. freedesktop.network-manager-settings.user.wireless.apply" "org. freedesktop.network-manager-settings.user.mobile.apply" "org. freedesktop.network-manager-settings.user.vpn.apply" "org.freedesktop. network-manager-settings.user.dsl.apply" . And *.modify are the policy for the editing adding and deleting of the system connections. And *.apply are the policy for applying the user connection to activate the devices. You can see the default settings in /usr/share/PolicyKit/policy/org. freedesktop.network-manager-settings.system.policy, which make the NM behave like the one without those policy. Thanks, Lance Wang #27: Ludwig Nussel (lnussel) (2009-11-03 16:17:45) (reply to #26) I've tried it on openSUSE 11.1 now. Works great AFAICT. However I think the usability could be enhanced by creating system connections by default, at least when user connections are restricted. That way the user would not need to authenticate each time he wants to connect. wrt separate policy for shared connections, I think that should be doable by checking another condition in is_user_request_connection_type_authorized(), right? + #28: Wang Lance (lzwang) (2009-11-06 10:52:31) (reply to #27) + Hi Ludwig I have a look at the request "creating system connections by + default". I think it could not be done like that. 1. Connections + created by the users include personal secrets which should not be saved + in system scope without the permission of the owner. Because in the + NetworkManager the password in system connection is saved without + encrypted. 2. Saving a connection as a system one means another + authentication which control by org.freedesktop.network-manager- + settings.system.*.modify. 3. In the NetworkManager 0.7 activation of + a system connection will not ask the console user about any kind + secrets settings. That will make user confused if he types the wrong + password first time. 4. Maybe it can be implemented in the way that + after the user connection is successfully applied, the nm-applet change + the user connection to a system connection. But the way is very ugly I + think. And there is a way the user would not need to authenticate each + time he wants to connect if he have the privilege of modifying system + connection. He can change a connection scope from user to system in nm- + connection-editor. 1. If the computer is a personal one, the user + who is the administrator can set all the policy settings to default. + That NetworkManager can apply any kind connection. 2. If the + computer is centrally controlled, the administrator is responsible for + settings the default system connections for all users. 3. If there + is specific user should be given some privileges, the administrator can + set them in the polkit. wrt separate policy for shared connections, yes + they are doable. I think the policy should be like these org. + freedesktop.network-manager-settings.user.*.share . + And how do you think the default settings of these policy ? -- openSUSE Feature: https://features.opensuse.org/305657

1 0

[openFATE 306315] Improve PK/zypper/YaST Big Lock
by fate_noreply＠suse.de 06 Nov '09

06 Nov '09

Feature changed by: Ján Kupec (jkupec) Feature #306315, revision 6 Title: Improve PK/zypper/YaST Big Lock openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:45:36 reject reason: no resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Currently, execution of any action by one of the package management tools blocks all others, in a "big lock" fashion". This is entirely acceptable when I am doing something with YaST, or running the PK applet, but it is very fastidious when it is due to background activity. Running zypper and seeing that lock message when nothing is being run by the user is very annoying (and is really the same for Yum on RHEL - but it still sucks :-) Can we improve the way PK refreshing causes everything else to lock up? I must say I expect upstream to be doing something about this... + References: + http://lists.opensuse.org/zypp-devel/2008-03/msg00075.html + https://bugzilla.novell.com/show_bug.cgi?id=551761 Business case (Partner benefit): openSUSE.org: The lock interferes with Administrator activity at random moments, and is very aggravating. It would be a competitive detail over RHEL, as well as a customer satisfaction item. Discussion: #1: Federico Lucifredi (flucifredi) (2009-03-30 21:13:47) I am somewhat reluctant to give this an M, as I do not know if something can actually be done to improve this. It would certainly warrant an M if a good solution can be devised, as this is really annoying on both SLES and RHEL, and it would make us look good in the comparison. + #2: Ján Kupec (jkupec) (2009-11-06 10:30:50) + Even if one zypp app is running, one should still be able to use the + other in read-only mode (searching, reporting needed updates from + current metadata, etc.). -- openSUSE Feature: https://features.opensuse.org/306315

1 0

[New: openFATE 308284] Ship openSUSE 11.2
by fate_noreply＠suse.de 05 Nov '09

05 Nov '09

Feature added by: Stephan Kulow (coolo) Feature #308284, revision 1 Title: Ship openSUSE 11.2 openSUSE-11.3: New Priority Requester: Mandatory Requested by: Stephan Kulow (coolo) Description: I consider Build 347 good enough to be GM. We should ship it! Of course there are plenty of bugs left unfixed, but IMO no-one that will cause major head ache to (most of) our users. Please consider! (filed for 11.3 as 11.2 is closed for features) -- openSUSE Feature: https://features.opensuse.org/308284

1 49

[openFATE 303809] Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1
by fate_noreply＠suse.de 05 Nov '09

05 Nov '09

Feature changed by: Katarina Machalkova (kmachalkova) Feature #303809, revision 28 Title: Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 openSUSE-11.1: Rejected by Matthias Eckermann (mge1512) reject date: 2008-07-30 16:50:50 reject reason: Moving to SLE 11 SP 1 / openSUSE 11.2 Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:23:34 reject reason: no resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Matthias Eckermann (mge1512) Description: Proposal is to offer an option in YaST to clone a disk layout for RAID use and probably jump into the RAID-creation-mode directly Below the original request from C. Boltz / openSUSE community: ----------------------------------------------------------------------------------------------------- It would be good to have an easier way to setup a raid 1 (mirroring). Currently you have to: * create partitions on first disk * create partitions on the second disk (usually using the same layout). * put the corresponding partitions (sda1+sdb1, sda2+sdb2, ...) into a raid array. The easier way would be * [x] I want to create a raid 1 * define the partitioning once for both disks YaST should then partition both disks as requested and create the raid volumes This would save the user/admin some time. However, the traditional method should still be available in case someone wants to have a different layout for some partitions for whatever reason. Relations: - Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 (novell/bugzilla/id: 387373) https://bugzilla.novell.com/show_bug.cgi?id=387373 Discussion: #2: Matthias Eckermann (mge1512) (2008-05-06 20:10:22) Thanks for the proposal. I am happy that there are more people out there sharing my problems:-) Yet, looking at the current "model" we have in mind for partitioner enhancements, I wonder, if we could probably make that more "generic" by adding something like a "clone disk partitioning scheme" button: You would partition hd0 first and then say: please clone this to hd1, hd2, ... and be able to adjust settings on hd1, ... later. Would that fit? so long - MgE #3: Christian Boltz (cboltz) (2008-05-08 05:07:14) Cloning the disk layout sounds like a good idea and would help. To make it more useful for RAID creation, add "clone to md*", maybe combined with a selection dialog to choose the disks to use. #4: Matthias Eckermann (mge1512) (2008-05-08 05:26:16) Well, you know, we indeed are planning to have such a dialog for creation of raids in the future, ...:-) I changed the "title" according to our discussion, and will 1transfer the request into our internal Feature tracking system soon. Thanks! so long - MgE #6: Martin Schmidkunz (mschmidkunz) (2008-05-15 11:37:58) AFAIK it is currently possible to create one partition after the other. So it does not make sense for me to have a "Clone this partition for future use" at the end. Instead I thought of: http://en.opensuse.org/Image:Idea_303809_1.png When the user presses "Add" in the "partitioning" tab he can choose whether to create one new partition or to use the whole partition scheme from another physical harddisk. Does that make sense? #7: Matthias Eckermann (mge1512) (2008-05-15 12:05:53) (reply to #6) Well, no:-( We are not asking for _partition_ cloning, but _disk_ cloning, i.e. if you have several harddisks, and you want to copy the partitioning from sda to sdb or the like. #8: Martin Schmidkunz (mschmidkunz) (2008-05-16 10:01:41) As discussed live with mge we agree on my proposal. #9: Arvin Schnell (aschnell) (2008-05-16 10:33:01) (reply to #8) That approach has some problems: 1) Hiding "Cloning" behind "Add Partition" is incomprehensible. Cloning affect the whole disk, adding a partition not really. 2) The step to select the partition type is omitted if only one type of partition can be selected. 3) The complete workflow of adding a partition is omitted when no partitions can be created. We (mge, mschmidkunz and aschnell) now agreed upon adding an entry to the "expert" menubutton in the partition overview. #16: Arvin Schnell (aschnell) (2009-02-04 11:08:08) Summarising the request: Add a entry "Close disk layout" to the "Expert" button in the disk view. This opens a dialog showing all disks that are suitable for being a clone (constraints: new disks must have equal or larger size). Several disks can be selected. On the selected disks: Delete everything (including RAIDs and LVMs somehow using that disk), create new partition table (if different from existing) and create partitions with same start and sizes (in cylinders as libstorage calculates internally) and partition IDs. Other parameters, e.g. filesystem, are not copied. + #18: Katarina Machalkova (kmachalkova) (2009-11-05 14:37:47) + ... and done :) -- openSUSE Feature: https://features.opensuse.org/303809

1 0

[openFATE 305783] Integrate latest stable KDE4 release
by fate_noreply＠suse.de 05 Nov '09

05 Nov '09

Feature added by: Stephan Binner (Beineri) Feature #305783, revision 1, last change by Title: Integrate latest stable KDE4 release openSUSE-11.2: New Priority Requester: Mandatory Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: Depending on what the openSUSE 11.2 schedule allows, the next release has to contain either the latest KDE 4.2.x or KDE 4.3.x packages including usual nifties (see external link) and integration with the distribution. In any case it should be tested and run with Qt 4.5 and KDE applications should be used in KDE4 versions as far as possible. Relations: - Ideas what to achieve with KDE on 11.2 (url: http://en.opensuse.org/KDE/Ideas/11.2) -- openSUSE Feature: https://features.opensuse.org/305783

1 17

[openFATE 305884] Support for creating partitions on ISW arrays
by fate_noreply＠suse.de 04 Nov '09

04 Nov '09

Feature changed by: Ihno Krumreich (ihno) Feature #305884, revision 16 Title: Support for creating partitions on ISW arrays - openSUSE-11.2: Rejected by (cthiel1) + openSUSE-11.2: Rejected by Santanu Bagchi (cthiel1) reject date: 2009-10-27 15:56:06 reject reason: SLES-only feature. Priority Requester: Important Projectmanager: Important Requested by: Marc Ruehrschneck (macrue) Partner organization: openSUSE.org Description: Boot and install support for partitioned devices for MD external format (ISW) for supported raid levels (0, 1, 10, 5, 6?). Enable yast-storage to create partitions on ISW arrays. Either enable yast-storage to understand mdp devices (partitionable md devices), or use kpartx to expose the individual array partitions Business case (Partner benefit): openSUSE.org: Enable feature parity with the Windows IMSM stack for Linux customers Discussion: #3: Michael Löffler (michl19) (2009-05-27 18:57:38) (reply to #2) I wonder here as well. If not in openSUSE where is the place for upstream devlopment. And I wonder if we can open up the feature to openFATE so the community can comment here as well. #4: Duncan Mac-Vicar (dmacvicar) (2009-08-27 10:31:28) Please reject, no resources in storage area. -- openSUSE Feature: https://features.opensuse.org/305884

1 0

[openFATE 305473] virt-manager: add option to set the keymap via UI for every VM
by fate_noreply＠suse.de 04 Nov '09

04 Nov '09

Feature changed by: Bernhard Wiedemann (bmwiedemann) Feature #305473, revision 17 Title: virt-manager: add option to set the keymap via UI for every VM openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2009-08-11 15:49:01 reject reason: too late for 11.2 Priority Requester: Important Projectmanager: Desirable Requested by: Michael Calmer (mcalmer) Description: If the default keyboard mapping does not work, it is difficult to set the keymap manual. A option in virt-manager to change the keymap setting via the UI for a single VM would be good to have. See also Bug #444632 Relations: - Wrong default keymap configured. Cannot enter important chars with vncviewer (novell/bugzilla/id: 444632) https://bugzilla.novell.com/show_bug.cgi?id=444632 Discussion: #1: Santanu Bagchi (sbagchi) (2009-08-21 11:36:02) Per bugzilla 444632, change has been submitted to SLES 11 line - should therefore reflect in sp1. But the UI enhancement is a key aspect for this change. We need to understand the efforts to add an API in libvirt before we can expose it through VIrt-man.... #2: Jason Douglas (bigvbguy) (2009-09-09 16:42:23) It probably makes sense to add this to vm-install (if it's not already there) so that the keymap can be selected at install time in the event that it differs from the system default. + #3: Bernhard Wiedemann (bmwiedemann) (2009-11-04 17:29:03) + For vncviewer to work, qemu needs to be informed (in this case via + libvirt/virtmanager) about the connecting host's keymap - which is IMHO + a somewhat broken approach. + Is a per-VM keymap-setting really the proper approach to this? + Maybe if you run VMs for access from different places with different + keymaps, but you do not seem to have this in mind. -- openSUSE Feature: https://features.opensuse.org/305473

1 0