November 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 300763] Warn about services using old libraries
by fate_noreply＠suse.de 18 Nov '09

18 Nov '09

Feature changed by: Ján Kupec (jkupec) Feature #300763, revision 65 Title: Warn about services using old libraries openSUSE-10.2: Rejected by Edith Parzefall (emapedl) reject date: 2006-10-02 16:05:01 reject reason: Not enough time for 10.2, rejecting with TPM approval. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-31 12:35:05 reject reason: Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:55 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-08-01 18:25:29 reject reason: Cutting scope to match project schedule. Priority Requester: Important openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: Martin Vidner (mvidner) Description: Fou4s has a useful feature: after installing updates, it runs "lsof | grep RPMDELETE" to see processes that are accessing the old libraries and recommends to restart them. Our update stack should do this as well, and notify users of processes that need to be restarted. I see this as both a zypper feature and a PK-UI pop-up. Documentation Impact: Software management documentaiton needs to be updated. Discussion: #7: Sherry Arnold (sfarnold) (2007-07-31 22:06:27) (reply to #4) The Debian outdated-libraries script that runs at package update time (perhaps only for libc?) only shows program names to the admin at the end. #5: Stanislav Visnovsky (visnov) (2006-09-06 10:57:53) Edith, Jiri, feel free to postpone this for 10.3 if out of resources. #6: Edith Parzefall (emapedl) (2007-07-31 11:49:06) Sorry, we had no time to look into this. Please reject for 10.3. #8: Federico Lucifredi (flucifredi) (2008-06-12 20:52:41) I like this. Stano, Klaus, please sanity-check. #9: Jiri Srain (jsrain) (2008-07-07 09:03:59) Jiri, please, add the check into YaST online update (I must admit that the suggested command didn't work for me, thus some investigation may be needed). Duncan, please, assign the applets. #10: Jiří Suchomel (jsuchome) (2008-07-14 15:55:27) Uhm, what should be the output of "lsof | grep RPMDELETE" and what should actually YaST do with the result? Or, if we use the command from comment 4: what should YaST do with these results? #11: Martin Vidner (mvidner) (2008-07-16 09:52:28) When packages are updated, the effect of the update may not be yet realized because the system is still using the old files (they are unlinked but still in use). A well known case is the kernel which needs a reboot (or kexec or ksplice...). For the apps, we can ask (in zypp app layer?) about all open files which are already unlinked. Then we can say "Updates will not take effect until these processes are restarted: sshd (pid 42), apache2 (pid 31337). If you are unsure, rebooting will do the job.". There can be a Details button or a reference to "zypper checkdeleted" (TODO) to show the gory details. It seems that RPMDELETE no longer works, but there is a simple fix (http://archives.neohapsis.com/archives/linux/suse/2006-q1/0034.html) for that. This thread (http://lists.opensuse.org/opensuse/2002-09/msg00532.html) shows how fou4s presents the info. Marcus has good points in comment 4 but we can address them when we have a prototype working. #12: Jiří Suchomel (jsuchome) (2008-07-16 10:04:16) (reply to #11) IMHO such check belongs to zypp, YaST/zypper/applets should show the results. Duncan, is it possible to assign this to someone from the zypp team? #13: Duncan Mac-Vicar (dmacvicar) (2008-07-30 17:09:22) (reply to #12) yes, will be done as part of the commit refactoring. #21: Duncan Mac-Vicar (dmacvicar) (2009-06-02 14:52:10) This will be implemented as a chain in the commit refactoring, by calling a external binary that will look in /proc for binaries with deleted libraries opened. The RPMDELETE stuff does not work in reality like it is described. Also may be good to create a good set of callbacks so libzypp can present a summary of services to restart and also config files that were modified. #22: Michael Andres (mlandres) (2009-08-07 11:02:30) libzypp-6.13.1 provides class CheckAccessDeleted and an example command zypp-CheckAccessDeleted to check for running processes which access meanwhile deleted files or libraries. This class may be used after commit, trying to figure out which services need to be restated. tools/zypp-CheckAccessDeleted.cc shows how to use the class, it's pretty easy. $ zypp-CheckAccessDeleted PID PPID UID LOGIN COMMAND SERVICE FILES 1900 1 216 ma wish - /lib/libexpat.so.1 3844 1 0 root fetchmail fetchmail /var/run/nscd/dbOioVty ... It's currently not integrated into the commit workflow, because it is a standalone usable fetaure. For the application it's probably far easier to use CheckAccessDeleted directly, than trying to communicate via a callback. At least unless we want to strip down the functionality to siply return a list of service names from commit, without further context. For this I can offer an option to commit, that simply returns a list of service names. #23: Ján Kupec (jkupec) (2009-08-07 12:04:52) OK, i'll do this check in zypper after each commit and advise users to restart the services. #24: Ján Kupec (jkupec) (2009-08-07 14:57:04) Hm... after an upgrade of zlib one gets quite a number of hits :O) The filelist can also be huge (is this the list of all files used by the process?). I guess showing an abbreviated (or at least terse) list of processes would be appropriate, with a hint how to view the complete list with all of the affected files. What about a separate command, or write the complete list to a file in ~/.zypp and tell the user to view this file? #27: Michael Andres (mlandres) (2009-08-26 12:03:33) (reply to #24) * I'm going to fix the filelist containing duplicate entries. * The default search looks for deleted open or memory mapped files. I can add an option to focus on detecting libs only. This will reduce the number of processes found. * We should keep in mind that this search might be a long running operation, and as it has to stat a lot of files, it may even block. IMO we should not call it automatically after each commit. And we should not store this volatile information in some file. Maybe we should just ask/encourage the user to call (/usr/bin/)zypp- CheckAccessDeleted, or offer this check as a separate command in zypper (zypper CheckAccessDeleted). #29: Michael Andres (mlandres) (2009-08-26 16:01:56) (reply to #27) libzypp-6.13.2 provides no more duplicates and tries harder to report libs and executables only. #30: Ján Kupec (jkupec) (2009-09-03 19:52:36) (reply to #29) Works nicely now. I also changed zypper to show the list only if there were packages to upgrade/downgrade or remove in the summary. It's in git; will be in zypper 1.2.4. The only thing that might be improved is that the processes are shown after each commit from the moment the file has been deleted until the process gets restarted or destroyed. So, if you e.g. do a zlib upgrade, you'll get a big table each time you do zypper up or zypper rm until you restart the machine (or all the processes). This could be annoying... do we want to try to improve it? #26: Duncan Mac-Vicar (dmacvicar) (2009-08-21 18:40:40) This requires to use 11.2 libzypp on SP1. Backport is basically adding all the 11.2 refactorings to the 11.1/SLE11 code. #28: Michael Andres (mlandres) (2009-08-26 12:15:16) (reply to #26) No, you can backport just the new class CheckAccessDeleted. It requires just 'lsof' being installed. #31: Ján Kupec (jkupec) (2009-09-21 10:41:31) 'zypper ps' added to show the list. The check will still be done after each upgrade/removal/downgrade, but only notification will be shown, suggeting to use 'zypper ps' to see the list. Marking 'done' for 11.2. #32: Stefan Behlert (sbehlert) (2009-11-18 12:40:14) (reply to #31) Any update on this? Keep in mind that feature freeze is this Friday. + #33: Ján Kupec (jkupec) (2009-11-18 15:30:03) (reply to #32) + We're putting 11.2 packages to SP1, so this feature comes there for + free. Closing as done. -- openSUSE Feature: https://features.opensuse.org/300763

1 0

[openFATE 305885] Handle the metadata "dirty" bit when an ISW array contains the root file system
by fate_noreply＠suse.de 18 Nov '09

18 Nov '09

Feature changed by: Michal Marek (michal-m) Feature #305885, revision 16 Title: Handle the metadata "dirty" bit when an ISW array contains the root file system - openSUSE-11.2: Candidate + openSUSE-11.2: Rejected by (michal-m) + reject date: 2009-11-18 13:36:00 + reject reason: Not in time for 11.2 Priority Requester: Important Projectmanager: Important openSUSE-11.3: Done Priority Requester: Important Projectmanager: Important Requested by: Marc Ruehrschneck (macrue) Partner organization: openSUSE.org Description: Shutdown scripts need to wait until all the MDRAID arrays are marked clean: The dirty bit dictates whether an array needs to be resynced. The OS must block writes to the array until the dirty bit is set, and it should allow for the bit to be cleared as a part of the system shutdown process. For rootfs-raid the metadata handler will need to be started in the early userspace environment as even mounting the root- filesystem read-only may cause writes to be issued due to journal recovery. This involves including mdmon in the initrd and and using the "--switch-root" option to switch the monitor to the final rootfs environment. At shutdown the OS must allow for the metadata handler to stay running across the "mark root-filesystem readonly" event, i.e. it must be excluded from the general killall events. Once all filesystems are readonly a call to "mdadm --wait-clean --scan" will quiesce all writes and clear the metadata dirty bit. Business case (Partner benefit): openSUSE.org: Enable feature parity with the Windows IMSM stack for Linux customers Discussion: #4: Thorsten Kukuk (kukuk) (2009-10-07 10:04:05) Something for boot.md... #5: Michal Marek (michal-m) (2009-11-02 17:13:22) Done in Factory, please reject for 11.2 -- openSUSE Feature: https://features.opensuse.org/305885

1 0

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

18 Nov '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305657, revision 56 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'. #31: Wang Lance (lzwang) (2009-11-11 11:49:59) Hi Ludwig The version with shared connection is ready. These are 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… The policy added are org.freedesktop.network-manager-settings.user.*.apply- with-share. What should be mentioned is that the shared connection is only controlled by these. In other words org.freedesktop.network- manager-settings.user.*.apply do not control the shared connection. Thanks, Lance Wang - -- openSUSE Feature: https://features.opensuse.org/305657

1 0

[openFATE 300763] Warn about services using old libraries
by fate_noreply＠suse.de 18 Nov '09

18 Nov '09

Feature changed by: Stefan Behlert (sbehlert) Feature #300763, revision 64 Title: Warn about services using old libraries openSUSE-10.2: Rejected by Edith Parzefall (emapedl) reject date: 2006-10-02 16:05:01 reject reason: Not enough time for 10.2, rejecting with TPM approval. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-31 12:35:05 reject reason: Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:55 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-08-01 18:25:29 reject reason: Cutting scope to match project schedule. Priority Requester: Important openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: Martin Vidner (mvidner) Description: Fou4s has a useful feature: after installing updates, it runs "lsof | grep RPMDELETE" to see processes that are accessing the old libraries and recommends to restart them. Our update stack should do this as well, and notify users of processes that need to be restarted. I see this as both a zypper feature and a PK-UI pop-up. Documentation Impact: Software management documentaiton needs to be updated. Discussion: #7: Sherry Arnold (sfarnold) (2007-07-31 22:06:27) (reply to #4) The Debian outdated-libraries script that runs at package update time (perhaps only for libc?) only shows program names to the admin at the end. #5: Stanislav Visnovsky (visnov) (2006-09-06 10:57:53) Edith, Jiri, feel free to postpone this for 10.3 if out of resources. #6: Edith Parzefall (emapedl) (2007-07-31 11:49:06) Sorry, we had no time to look into this. Please reject for 10.3. #8: Federico Lucifredi (flucifredi) (2008-06-12 20:52:41) I like this. Stano, Klaus, please sanity-check. #9: Jiri Srain (jsrain) (2008-07-07 09:03:59) Jiri, please, add the check into YaST online update (I must admit that the suggested command didn't work for me, thus some investigation may be needed). Duncan, please, assign the applets. #10: Jiří Suchomel (jsuchome) (2008-07-14 15:55:27) Uhm, what should be the output of "lsof | grep RPMDELETE" and what should actually YaST do with the result? Or, if we use the command from comment 4: what should YaST do with these results? #11: Martin Vidner (mvidner) (2008-07-16 09:52:28) When packages are updated, the effect of the update may not be yet realized because the system is still using the old files (they are unlinked but still in use). A well known case is the kernel which needs a reboot (or kexec or ksplice...). For the apps, we can ask (in zypp app layer?) about all open files which are already unlinked. Then we can say "Updates will not take effect until these processes are restarted: sshd (pid 42), apache2 (pid 31337). If you are unsure, rebooting will do the job.". There can be a Details button or a reference to "zypper checkdeleted" (TODO) to show the gory details. It seems that RPMDELETE no longer works, but there is a simple fix (http://archives.neohapsis.com/archives/linux/suse/2006-q1/0034.html) for that. This thread (http://lists.opensuse.org/opensuse/2002-09/msg00532.html) shows how fou4s presents the info. Marcus has good points in comment 4 but we can address them when we have a prototype working. #12: Jiří Suchomel (jsuchome) (2008-07-16 10:04:16) (reply to #11) IMHO such check belongs to zypp, YaST/zypper/applets should show the results. Duncan, is it possible to assign this to someone from the zypp team? #13: Duncan Mac-Vicar (dmacvicar) (2008-07-30 17:09:22) (reply to #12) yes, will be done as part of the commit refactoring. #21: Duncan Mac-Vicar (dmacvicar) (2009-06-02 14:52:10) This will be implemented as a chain in the commit refactoring, by calling a external binary that will look in /proc for binaries with deleted libraries opened. The RPMDELETE stuff does not work in reality like it is described. Also may be good to create a good set of callbacks so libzypp can present a summary of services to restart and also config files that were modified. #22: Michael Andres (mlandres) (2009-08-07 11:02:30) libzypp-6.13.1 provides class CheckAccessDeleted and an example command zypp-CheckAccessDeleted to check for running processes which access meanwhile deleted files or libraries. This class may be used after commit, trying to figure out which services need to be restated. tools/zypp-CheckAccessDeleted.cc shows how to use the class, it's pretty easy. $ zypp-CheckAccessDeleted PID PPID UID LOGIN COMMAND SERVICE FILES 1900 1 216 ma wish - /lib/libexpat.so.1 3844 1 0 root fetchmail fetchmail /var/run/nscd/dbOioVty ... It's currently not integrated into the commit workflow, because it is a standalone usable fetaure. For the application it's probably far easier to use CheckAccessDeleted directly, than trying to communicate via a callback. At least unless we want to strip down the functionality to siply return a list of service names from commit, without further context. For this I can offer an option to commit, that simply returns a list of service names. #23: Ján Kupec (jkupec) (2009-08-07 12:04:52) OK, i'll do this check in zypper after each commit and advise users to restart the services. #24: Ján Kupec (jkupec) (2009-08-07 14:57:04) Hm... after an upgrade of zlib one gets quite a number of hits :O) The filelist can also be huge (is this the list of all files used by the process?). I guess showing an abbreviated (or at least terse) list of processes would be appropriate, with a hint how to view the complete list with all of the affected files. What about a separate command, or write the complete list to a file in ~/.zypp and tell the user to view this file? #27: Michael Andres (mlandres) (2009-08-26 12:03:33) (reply to #24) * I'm going to fix the filelist containing duplicate entries. * The default search looks for deleted open or memory mapped files. I can add an option to focus on detecting libs only. This will reduce the number of processes found. * We should keep in mind that this search might be a long running operation, and as it has to stat a lot of files, it may even block. IMO we should not call it automatically after each commit. And we should not store this volatile information in some file. Maybe we should just ask/encourage the user to call (/usr/bin/)zypp- CheckAccessDeleted, or offer this check as a separate command in zypper (zypper CheckAccessDeleted). #29: Michael Andres (mlandres) (2009-08-26 16:01:56) (reply to #27) libzypp-6.13.2 provides no more duplicates and tries harder to report libs and executables only. #30: Ján Kupec (jkupec) (2009-09-03 19:52:36) (reply to #29) Works nicely now. I also changed zypper to show the list only if there were packages to upgrade/downgrade or remove in the summary. It's in git; will be in zypper 1.2.4. The only thing that might be improved is that the processes are shown after each commit from the moment the file has been deleted until the process gets restarted or destroyed. So, if you e.g. do a zlib upgrade, you'll get a big table each time you do zypper up or zypper rm until you restart the machine (or all the processes). This could be annoying... do we want to try to improve it? #26: Duncan Mac-Vicar (dmacvicar) (2009-08-21 18:40:40) This requires to use 11.2 libzypp on SP1. Backport is basically adding all the 11.2 refactorings to the 11.1/SLE11 code. #28: Michael Andres (mlandres) (2009-08-26 12:15:16) (reply to #26) No, you can backport just the new class CheckAccessDeleted. It requires just 'lsof' being installed. #31: Ján Kupec (jkupec) (2009-09-21 10:41:31) 'zypper ps' added to show the list. The check will still be done after each upgrade/removal/downgrade, but only notification will be shown, suggeting to use 'zypper ps' to see the list. Marking 'done' for 11.2. + #32: Stefan Behlert (sbehlert) (2009-11-18 12:40:14) (reply to #31) + Any update on this? + Keep in mind that feature freeze is this Friday. -- openSUSE Feature: https://features.opensuse.org/300763

1 0

[New: openFATE 308349] Option to select regional settings in the installer
by fate_noreply＠suse.de 17 Nov '09

17 Nov '09

Feature added by: Thomas Sundell (thsundel) Feature #308349, revision 1 Title: Option to select regional settings in the installer openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Thomas Sundell (thsundel) Description: I would like to see an option to select regional settings in the installer. Many use English as "desktop" language and this forces the regional settings to be us/en format in KDE and Gnome. Regional settings have to be manually changed after the installation so that for example the clock will display 24 hour format instead of 12PM/AM format for all users. -- openSUSE Feature: https://features.opensuse.org/308349

1 0

[New: openFATE 308345] Make notifications work even after evolution window is closed
by fate_noreply＠suse.de 17 Nov '09

17 Nov '09

Feature added by: Atri Bhattacharya (badshah400) Feature #308345, revision 1 Title: Make notifications work even after evolution window is closed openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Atri Bhattacharya (badshah400) Description: Evolution has a notification-plugin that currently is supposed to work only when the main window of evolution is running. After closing the evolution window one does not get notifications for new mail arriving, even though he/she might have selected the check for new mail every X min option. The feature request is to make the notifications in evolution work even when evolution is closed (Ctrl+W), so that the system tray icon shows up whenever evolution knows of arriving new mails despite the main application not running (evolution-data-server still running in the background). Thus, firstly evolution has to have knowledge of incoming new mails despite running only as a background service, and second, the notification-icon must show up whenever new mails are detected (as configured). This way users will get notifications for new mails without having to run the main app window all the time. This happens for alarms for events set up in evolution currently. -- openSUSE Feature: https://features.opensuse.org/308345

1 0

[openFATE 306967] KDE default
by fate_noreply＠suse.de 16 Nov '09

16 Nov '09

Feature added by: Frank Karlitschek (FrankKarlitschek) Feature #306967, revision 1 Title: KDE default openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Frank Karlitschek (frankkarlitschek) Description: I propose to make KDE the default desktop in openSUSE. - It is confusing for new Linux users if they have to decide between KDE and GNOME during the installation. New users don´t know either of them. So it is easier for beginners if there is a default. openSUSE has more KDE users than GNOME users so it is logical to make KDE the default. - Unique Selling Point. It is important for openSUSE to provide something that Ubuntu and Fedora don´t provide. It would be beneficial for openSUSE to be the only big KDE distribution. - This could attract more developers because KDE developers need a nice distribution to develop on. - This would increase the popularity of openSUSE in the KDE user community. The negative impact on the GNOME community is not that bad because Ubuntu is the most popular GNOME distribution. openSUSE should, of course, also ship and support GNOME. So experienced users can choose. But new users should have KDE as default. What do you think? -- openSUSE Feature: https://features.opensuse.org/306967

1 109

[New: openFATE 308336] Software Management Filter by Date
by fate_noreply＠suse.de 16 Nov '09

16 Nov '09

Feature added by: Carl Fletcher (caf4926) Feature #308336, revision 1 Title: Software Management Filter by Date openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Carl Fletcher (caf4926) Description: Would it be possible to have a filter column that lets us sort the packages by Date. Letting us see in particular the most recently installed Packages. This information is of course available at: /var/log/zypp/history Here is a image showing the feature idea: http://www.imagebam.com/image/940cbc56236842 -- openSUSE Feature: https://features.opensuse.org/308336

1 0

[openFATE 306413] Poulsbo (GMA500) graphics support
by fate_noreply＠suse.de 15 Nov '09

15 Nov '09

Feature added by: Justin Haygood (jhaygood) Feature #306413, revision 1, last change by Title: Poulsbo (GMA500) graphics support openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Justin Haygood (jhaygood) Description: openSUSE should support laptops with an Intel GMA500 (Poulsbo) graphics card. Currently, Ubuntu has a monopoly on such machines, such as the Dell Inspiron Mini 12 -- openSUSE Feature: https://features.opensuse.org/306413

1 3

[New: openFATE 308322] interactive mode for zypper
by fate_noreply＠suse.de 14 Nov '09

14 Nov '09

Feature added by: Rihards Olups (richlv) Feature #308322, revision 1 Title: interactive mode for zypper openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Rihards Olups (richlv) Description: this is a request for fully supported and functional interactive mode for zypper. currently zypper is mostly usable in non-interactive mode - user issues a command which is executed right away. while interactive mode is sort of working, it is not supported and breaks often (upgraded repositotires are not properly reloaded etc). package manager smart supports such an interactive mode, and it is very useful - user can enter this mode, search for packages without reloading repository data all the time and queue actions. Use Case: example session would be starting zypper, searching for some installed package, deciding to uninstall it, then adding a couple of packages for installation, searching for some more packages, deciding to install them as well, noticing that a couple of packages shoould be upgraded (and queuing that), then queuing some more packages to be removed. in the end 'commit' action is performed and zypper can be left for few hours to do its job. -- openSUSE Feature: https://features.opensuse.org/308322

1 2