November 2009 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308363] improve yast2 software installation tool
by fate_noreply＠suse.de 19 Nov '09

19 Nov '09

Feature added by: matthias propst (l1zard) Feature #308363, revision 1 Title: improve yast2 software installation tool openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: matthias propst (l1zard) Description: this idea came to me when i was updating some packages and did destrpoy some functionality of my system. so i came up with this: have the possibility to save the current rpm-file-list automaticly (i know you can create one by hand) and save the current rpms which will be updated before doing the update action. so if there is something wrong after updating a package a fallback is still possibe even though the rpm release of the version installed have been removed from repository. -- openSUSE Feature: https://features.opensuse.org/308363

1 0

[openFATE 303493] zypper: add separate messages for Required and Recommended packages
by fate_noreply＠suse.de 19 Nov '09

19 Nov '09

Feature changed by: Ján Kupec (jkupec) Feature #303493, revision 17 Title: zypper: add separate messages for Required and Recommended packages openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-03-27 13:50:16 reject reason: Not enough time to look into this. Priority Requester: Important - openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) - reject date: 2008-08-01 18:27:34 - reject reason: Cutting scope to match project schedule. + openSUSE-11.1: Done Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-04-16 13:39:02 reject reason: Out of agreed focus for 11.2 development Priority Requester: Important - openSUSE-11.3: New + openSUSE-11.3: Done Priority Requester: Important Requested by: Cristian Rodríguez (elvigia) Description: currenly when you install a package with zypper, you just get the packages that are going to be installed, regardless if the are required or Reccommended,.. will be nice if the messages can be arranged to be more explict about what the package manager is doing. "The following NEW [required|reccomended] package is going to be installed: foo" also an informative message about Suggested packages should be shown "The following package(s) is(are) suggested but are not going to be installed foo bar " unless user pass --install-suggested or use a boolean configuration directive on zypp.conf or something, suggested packages should not be installed by default ..currently it seems to be completely ignored and does nothing. + Discussion: + #4: Ján Kupec (jkupec) (2009-11-19 19:59:02) + done in git, will be in zypper 1.2.11 -- openSUSE Feature: https://features.opensuse.org/303493

1 0

[New: openFATE 308257] Partitioner: allow for adjusting layout when creatin raid10 (and maybe 5/6?)
by fate_noreply＠suse.de 19 Nov '09

19 Nov '09

Feature added by: Sinisa Bandin (siny) Feature #308257, revision 1 Title: Partitioner: allow for adjusting layout when creatin raid10 (and maybe 5/6?) openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Sinisa Bandin (siny) Description: Because using "far" layout makes BIG difference in speed of array. Also makes possible extra-safe arrays with number of copies greater than 2, up to total number of storage devices. Not sure about raid5/6, I am not using them. -- openSUSE Feature: https://features.opensuse.org/308257

1 2

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 19 Nov '09

19 Nov '09

Feature changed by: Ján Kupec (jkupec) Feature #305503, revision 37 Title: zypper: allow update by issues/bugs/advisories - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) Also, i noticed in 11.1 updates repository, that many bugs have a CVE, but it's only in the description, not in the 'reference' metadata. Only bugzilla is in 'reference'. Do we want to address this? #10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9) we are not emitting it yet. this also needs to be done :/ #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> #11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8) Please re-think about introducing another term ( fix ), we already have * update * upgrade * patch #12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11) What i try to achieve is to have a way to install the patches fixing the issues and a way to list them (issue number & patch name & (patch) description), search in them. The other alternatives i considered were: $ zypper patch [--bugzilla #] [--cve #] $ zypper list-patches --issues [string] The first command looks nice, but i don't know what to use to list/search the issues - the list-patches command does not seem right to me - looks more like it deserved a new command. $ zypper install [--bugzilla #] [--cve #] $ zypper search --issues [string] In this case, like in the 'list-patches --issues' case, the search command would either need to radically change its output, or user would need to call 'zypper patch-info the_found_patch' to get the patch description. Any other ideas? Why is having a new command a bad thing (esp. compared to having new options in the existing commands)? BTW: (We don't have 'upgrade' :O) #13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12) Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article? * http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ (http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/) * http://linux.die.net/man/8/yum-security (http://linux.die.net/man/8/yum-security) #14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13) 'zypper update' does not work with patches. 'zypper patch' looks to me like better candidate for new --bz or --cve options. yum does not make difference between these two. The yum plugin also adds a new command (list-sec), which was Klaus' objection. #15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14) Well, my objection is the new term 'fix' besides 'update' and 'patch' and will confuse people. It should be an option to "list" or "list-patches" imho #16: Ján Kupec (jkupec) (2009-07-07 16:16:12) (reply to #15) OK, so far the following looks like a candidate (taken yum into account as well): # to install a fix $ zypper patch [--bz #] [--cve #] [--any-other #] # to list available needed fixes (issue-number, patchname-version, category, description) # all $ zypper list-patches --issues # matching a substring ("CVE", number, or any) $ zypper list-patches --issues foo # only CVEs/bugzillas $ zypper list-patches [--cve] [--bz] #17: Ján Kupec (jkupec) (2009-07-15 09:24:34) Done in zypper. You can fetch zypper 1.2.2 from home:jkupec:Factory to try and let me know what you think. New options in lp and patch commands: $ zypper help lp -b, --bugzilla[=#] List needed patches for Bugzilla issues. --cve[=#] List needed patches for CVE issues. --issues[=string] Look for issues matching the specified string. -a, --all List all patches, not only the needed ones. $ zypper help patch patch [options] -b, --bugzilla # Install patch fixing the specified bugzilla issue. --cve # Install patch fixing the specified CVE issue. --bz works, too. Can this feature be closed, or we'll close it after the repo metadata have the CVE references? #18: Ján Kupec (jkupec) (2009-07-15 09:30:38) One more thing that crossed my mind when looking at the yum article http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ They seem to be able to associate issue numbers with spcecific packages. I'm not sure if this is because they just avoid issuing updates with plenty of packages in single <update> tags, like we often do? #19: Christoph Thiel (cthiel1) (2009-07-16 11:33:39) (reply to #18) Rudi, is autobuild planning to adding additional information to the metadata? #20: Ruediger Oertel (oertel) (2009-08-26 12:12:41) (reply to #19) Not as the driving element. But we usually implement these extensions when maintenance and zypp development request them. #21: Ján Kupec (jkupec) (2009-09-21 10:58:06) (reply to #20) Well, we would like CVEs in the patches :O) So i repeat my question: Can this feature be closed, or we'll close it after the repo metadata have the CVE references? #22: Ruediger Oertel (oertel) (2009-11-18 16:27:31) I just need the URL to enter as CVE reference to complete my side. #23: Ruediger Oertel (oertel) (2009-11-18 17:19:01) (reply to #22) got the url from dirk in bnc#556293. my side is implemented now. + #24: Ján Kupec (jkupec) (2009-11-19 12:58:35) (reply to #23) + So we have it in zypper, we have it in metadata. Done. -- openSUSE Feature: https://features.opensuse.org/305503

1 0

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

19 Nov '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305657, revision 58 Title: finer grained PolicyKit support for Networkmanager - openSUSE-11.2: Candidate + openSUSE-11.2: Rejected by (sbehlert) + reject date: 2009-11-19 12:53:01 + reject reason: not in release 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 305686] [beta1] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 19 Nov '09

19 Nov '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305686, revision 15 - Title: gnome-screensaver does not respond to an expired password + Title: [beta1] gnome-screensaver does not respond to an expired + password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. -- openSUSE Feature: https://features.opensuse.org/305686

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 18 Nov '09

18 Nov '09

Feature changed by: Ruediger Oertel (oertel) Feature #305503, revision 36 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) Also, i noticed in 11.1 updates repository, that many bugs have a CVE, but it's only in the description, not in the 'reference' metadata. Only bugzilla is in 'reference'. Do we want to address this? #10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9) we are not emitting it yet. this also needs to be done :/ #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> #11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8) Please re-think about introducing another term ( fix ), we already have * update * upgrade * patch #12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11) What i try to achieve is to have a way to install the patches fixing the issues and a way to list them (issue number & patch name & (patch) description), search in them. The other alternatives i considered were: $ zypper patch [--bugzilla #] [--cve #] $ zypper list-patches --issues [string] The first command looks nice, but i don't know what to use to list/search the issues - the list-patches command does not seem right to me - looks more like it deserved a new command. $ zypper install [--bugzilla #] [--cve #] $ zypper search --issues [string] In this case, like in the 'list-patches --issues' case, the search command would either need to radically change its output, or user would need to call 'zypper patch-info the_found_patch' to get the patch description. Any other ideas? Why is having a new command a bad thing (esp. compared to having new options in the existing commands)? BTW: (We don't have 'upgrade' :O) #13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12) Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article? * http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ (http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/) * http://linux.die.net/man/8/yum-security (http://linux.die.net/man/8/yum-security) #14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13) 'zypper update' does not work with patches. 'zypper patch' looks to me like better candidate for new --bz or --cve options. yum does not make difference between these two. The yum plugin also adds a new command (list-sec), which was Klaus' objection. #15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14) Well, my objection is the new term 'fix' besides 'update' and 'patch' and will confuse people. It should be an option to "list" or "list-patches" imho #16: Ján Kupec (jkupec) (2009-07-07 16:16:12) (reply to #15) OK, so far the following looks like a candidate (taken yum into account as well): # to install a fix $ zypper patch [--bz #] [--cve #] [--any-other #] # to list available needed fixes (issue-number, patchname-version, category, description) # all $ zypper list-patches --issues # matching a substring ("CVE", number, or any) $ zypper list-patches --issues foo # only CVEs/bugzillas $ zypper list-patches [--cve] [--bz] #17: Ján Kupec (jkupec) (2009-07-15 09:24:34) Done in zypper. You can fetch zypper 1.2.2 from home:jkupec:Factory to try and let me know what you think. New options in lp and patch commands: $ zypper help lp -b, --bugzilla[=#] List needed patches for Bugzilla issues. --cve[=#] List needed patches for CVE issues. --issues[=string] Look for issues matching the specified string. -a, --all List all patches, not only the needed ones. $ zypper help patch patch [options] -b, --bugzilla # Install patch fixing the specified bugzilla issue. --cve # Install patch fixing the specified CVE issue. --bz works, too. Can this feature be closed, or we'll close it after the repo metadata have the CVE references? #18: Ján Kupec (jkupec) (2009-07-15 09:30:38) One more thing that crossed my mind when looking at the yum article http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ They seem to be able to associate issue numbers with spcecific packages. I'm not sure if this is because they just avoid issuing updates with plenty of packages in single <update> tags, like we often do? #19: Christoph Thiel (cthiel1) (2009-07-16 11:33:39) (reply to #18) Rudi, is autobuild planning to adding additional information to the metadata? #20: Ruediger Oertel (oertel) (2009-08-26 12:12:41) (reply to #19) Not as the driving element. But we usually implement these extensions when maintenance and zypp development request them. #21: Ján Kupec (jkupec) (2009-09-21 10:58:06) (reply to #20) Well, we would like CVEs in the patches :O) So i repeat my question: Can this feature be closed, or we'll close it after the repo metadata have the CVE references? #22: Ruediger Oertel (oertel) (2009-11-18 16:27:31) I just need the URL to enter as CVE reference to complete my side. + #23: Ruediger Oertel (oertel) (2009-11-18 17:19:01) (reply to #22) + got the url from dirk in bnc#556293. my side is implemented now. -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 18 Nov '09

18 Nov '09

Feature changed by: Ruediger Oertel (oertel) Feature #305503, revision 35 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) Also, i noticed in 11.1 updates repository, that many bugs have a CVE, but it's only in the description, not in the 'reference' metadata. Only bugzilla is in 'reference'. Do we want to address this? #10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9) we are not emitting it yet. this also needs to be done :/ #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> #11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8) Please re-think about introducing another term ( fix ), we already have * update * upgrade * patch #12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11) What i try to achieve is to have a way to install the patches fixing the issues and a way to list them (issue number & patch name & (patch) description), search in them. The other alternatives i considered were: $ zypper patch [--bugzilla #] [--cve #] $ zypper list-patches --issues [string] The first command looks nice, but i don't know what to use to list/search the issues - the list-patches command does not seem right to me - looks more like it deserved a new command. $ zypper install [--bugzilla #] [--cve #] $ zypper search --issues [string] In this case, like in the 'list-patches --issues' case, the search command would either need to radically change its output, or user would need to call 'zypper patch-info the_found_patch' to get the patch description. Any other ideas? Why is having a new command a bad thing (esp. compared to having new options in the existing commands)? BTW: (We don't have 'upgrade' :O) #13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12) Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article? * http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ (http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/) * http://linux.die.net/man/8/yum-security (http://linux.die.net/man/8/yum-security) #14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13) 'zypper update' does not work with patches. 'zypper patch' looks to me like better candidate for new --bz or --cve options. yum does not make difference between these two. The yum plugin also adds a new command (list-sec), which was Klaus' objection. #15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14) Well, my objection is the new term 'fix' besides 'update' and 'patch' and will confuse people. It should be an option to "list" or "list-patches" imho #16: Ján Kupec (jkupec) (2009-07-07 16:16:12) (reply to #15) OK, so far the following looks like a candidate (taken yum into account as well): # to install a fix $ zypper patch [--bz #] [--cve #] [--any-other #] # to list available needed fixes (issue-number, patchname-version, category, description) # all $ zypper list-patches --issues # matching a substring ("CVE", number, or any) $ zypper list-patches --issues foo # only CVEs/bugzillas $ zypper list-patches [--cve] [--bz] #17: Ján Kupec (jkupec) (2009-07-15 09:24:34) Done in zypper. You can fetch zypper 1.2.2 from home:jkupec:Factory to try and let me know what you think. New options in lp and patch commands: $ zypper help lp -b, --bugzilla[=#] List needed patches for Bugzilla issues. --cve[=#] List needed patches for CVE issues. --issues[=string] Look for issues matching the specified string. -a, --all List all patches, not only the needed ones. $ zypper help patch patch [options] -b, --bugzilla # Install patch fixing the specified bugzilla issue. --cve # Install patch fixing the specified CVE issue. --bz works, too. Can this feature be closed, or we'll close it after the repo metadata have the CVE references? #18: Ján Kupec (jkupec) (2009-07-15 09:30:38) One more thing that crossed my mind when looking at the yum article http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ They seem to be able to associate issue numbers with spcecific packages. I'm not sure if this is because they just avoid issuing updates with plenty of packages in single <update> tags, like we often do? #19: Christoph Thiel (cthiel1) (2009-07-16 11:33:39) (reply to #18) Rudi, is autobuild planning to adding additional information to the metadata? #20: Ruediger Oertel (oertel) (2009-08-26 12:12:41) (reply to #19) Not as the driving element. But we usually implement these extensions when maintenance and zypp development request them. #21: Ján Kupec (jkupec) (2009-09-21 10:58:06) (reply to #20) Well, we would like CVEs in the patches :O) So i repeat my question: Can this feature be closed, or we'll close it after the repo metadata have the CVE references? + #22: Ruediger Oertel (oertel) (2009-11-18 16:27:31) + I just need the URL to enter as CVE reference to complete my side. -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 18 Nov '09

18 Nov '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 35 Title: zypper: dist upgrade could error out if more than one repository with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) #16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14) Rudi, please look at c#14 and 15 #17: Ján Kupec (jkupec) (2009-07-29 19:04:40) Current status: * TODO: put CPE IDs to content/prodcuts.xml metadata (still nobody assigned to do this!) * TODO: satsolver will need to parse the above (or is this ready already?) * PROBLEM: we need to figure out which repos don't go together for dup. I proposed to compare CPEs of 'base' or 'platform' repos, but we have no 'isBase' flag in product or repo metadata. Simply checking for different CPEs is not enough (think of one base product and one addon - two different CPEs, but 'dup' is OK with them). * PROBLEM: even if we'll have the 'isBase' flag, we'll be stuck in case of two different, but compatible bases, like e.g. SLES and SLED could be used standalone or with SLED as an add-on to SLES in the past. Do we still allow this? Any ideas? #18: Ruediger Oertel (oertel) (2009-07-30 17:20:05) adding more data (like the CPE-ids) is not a big issue. the problem for me is rather how to obtain a CPE-id #19: Marcus Meissner (msmeissn) (2009-08-04 17:55:08) CPE ids can be defined by the vendor as I udnerstand ;) I mailed Jan and Rudi. my suggestions would be: cpe:/o:opensuse:opensuse:11.1 cpe:/o:novell:suse_linux_enterprise:11:ga:server cpe:/o:novell: suse_linux_enterprise:10:sp2:desktop #20: Ralph Ulrich (ulenrich) (2009-08-05 13:25:05) (beginners question) Why products at all. Debian/Ubuntu do have so called meta-packages , which are normal package that pull in stuff: minimal, standard ...etc Without products you would loose an additional level of complication? #21: Ján Kupec (jkupec) (2009-08-05 15:02:36) (reply to #20) Using metapackages for puling stuff does not exlude using of CPE ID. It's just means to uniquely identify a product and can be used by Debian's metapackages as well. Other than that, your question is not related to this FATE, and is more appropriate for opensuse-softwaremgmt(a)opensuse.org mailing list. But you might find the answer also here http://en.opensuse.org/Product_Management #22: Ján Kupec (jkupec) (2009-08-19 17:25:34) We still need to do the TODOs and resolve the issues from c#17 here. If you have an idea, please speak up. #23: Klaus Kämpf (kwk) (2009-08-25 09:36:05) I believe the request title is wrong and should be adapted. Indeed 'distribution upgrade' is special, as it considers one repo to be 'authorative' and thus dictating package versions, which might result in a version downgrade. 'zypper dup' should provide support for this and, in case of multiple 'product' (resp. base) repositories request a decision from the user. There are two things to be solved from my pov * Detection of a 'base' vs. 'addon' repo. Could be done by looking at a 'product' resolvable. * Specifying the 'authorative' repo in case of dist upgrade. ie. passing a '--product foo' or '-to repo' to zypper. + #24: Ján Kupec (jkupec) (2009-11-18 15:59:55) (reply to #23) + Detection of base vs. addon is what we currently lack. The + authoritative repo can now be selected using --from option. 'zypper dup + --from repo-oss'. -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 18 Nov '09

18 Nov '09

Feature changed by: Ján Kupec (jkupec) Feature #302159, revision 61 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important - openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) - reject date: 2008-07-11 22:23:41 - reject reason: Postponing. + openSUSE-11.1: Done Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Done Priority Requester: Desirable Projectmanager: Important Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 and #305624 Test Case: * Run zypper with: zypper install --download-only [package] * Subsequent "zypper install [package]" (without --download-only) should not download the package again, just install it. * This should work with install, update, dist-upgrade, patch, and verify commands Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) Broadband is actually a pretty broad term, and so the survey item probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. #14: Elmar Stellnberger ATK (estellnb) (2009-03-26 13:04:40) One advantage will be that packages can be inspected by a prog. such as mc in advance to installation or to manually take them apart by rpm2cpio. Sometimes it is necessary to add special rpm-installation options as --excludepath or --excludedocs to install several versions of a single package for downward compatibility. Furthermore in combination with an upcoming --arch switch it may enable to download packages on a server to be installed on another system/machine. f.i. the ati repo can not be browsed via http so that it is necessary to download packages from it via zypper rather than a web browser. #17: Michael Andres (mlandres) (2009-07-21 12:30:27) libzypp-6.11.0 allows to set different download policies in ZYppCommitPolicy (DownloadOnly, DownloadInAdvance, DownloadInHeaps, DownloadAsNeeded). #19: Ralph Ulrich (ulenrich) (2009-08-12 13:02:52) (reply to #17) As in factory zypper is 1.2.2 as of now: I searched how to handle ZYppCommitPolicy - I didn't find any documentation about. Shouldn't there? #20: Ján Kupec (jkupec) (2009-08-12 13:35:58) (reply to #19) Please read more thoroughly. Comment #17 does not mention zypper, but libzypp. It was an information for developers using libzypp. As for zypper, the only thing that has been added in regard of commit policy so far, is the --download-only option, but in 1.2.3, not 1.2.2! It will be documented in zypper's man page, and its help texts (e.g. zypper help install). #23: Martin Vidner (mvidner) (2009-08-27 16:09:51) (reply to #20) I have bumped the version to zypper-1.2.3 (in home:mvidner, SRI 19048 to zypp:Head). It implements --download-only. #18: Ján Kupec (jkupec) (2009-07-27 15:22:59) Done also in zypper (--download-only/-d added to several commands). To be in zypper 1.2.3 #22: Ralph Ulrich (ulenrich) (2009-08-26 13:26:52) (reply to #18) zypper version halted at 1.2.2 ever since? I would really like this feature in openSUSE-11.2 And status is done for openSUSE-11.2 -- openSUSE Feature: https://features.opensuse.org/302159

1 0