October 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 30 Oct '09

30 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305634, revision 164 Title: Debian-like dist-upgrade live system full version upgrade - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Relations: - Fedora Upgrade Instructions (feature/id: http://fedoraproject.org/wiki/YumUpgradeFaq) - Wiki page for implementation (url: http://en.opensuse.org/Upgrade/11.2) - Debian Upgrade How-to (url: http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.ht…) Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #30: Peter Poeml (poeml) (2009-03-10 15:31:10) (reply to #25) Interesting discussion about that particular issue, but simple to solve. What works is keeping devs.rpm, and/or simply rpm -e --justdb it. (It's enough to do so later.) The more complicated issues in the past where a case where the kernel changed its major version, and some networking applications could not start with the (still running) old kernel. Didn't prevent an online upgrade over the network though, and applications could keep running. When skipping several openSUSE versions, and differences have accumulated, in can happen that an upgrade in one step is not possible. It's not possible to upgrade from 9.0 to 10.1 without first updating to 9.1, due to the kernel. These issues are quickly found by experimentation though. Other than that, the most hurting issue during remote upgrades is the difficulty to ensure persistent device naming for NICs, because that is reimplemented / changed with each openSUSE version, the upgrade procedure is not well documented, and funny surprises are the rule, and it often simply doesn't work. Other small hurdles are the increasing modularization of kernel, which can lead to lack of support for chipsets and storage in the initrd, package split-offs (mingetty) that lead to lack of essential components after the upgrade. It pays to make sure that all packages are installed which are in the "minimal" patter of that openSUSE version. And the required but disappeared PAM module locked us out once also... A word to all the non-believers who think that upgrades don't work: I have upgraded dozens of systems remotely during the last decade. All my productive systems are repeatedly upgraded that way since day one. Unfortunately, the tools we have didn't help with this. Apart from using rpm, I started doing this with yum a few years ago (if it works, metadata is available, falling back to rpm if needed). Last year I documented some steps: http://poeml.de/~poeml/10.1-11.0-update/update-11.0.howto. With today's conveniency of virtualization at hand, I actually did an upgrade by experiment with a VM first, to minimize the risk, and documented all the steps. Since I had to upgrade several 10.1 machines, this seemed like a good idea to reduce the risk and save brain energy. The notes from it are a good outcome, too. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to #20) this is very helpful, we should look at the bumps that Debian hits while doing this. On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL 5.3, and it went without a hitch. There may be something to be gathered from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. #28: Javier Llorente (javierllorente) (2009-03-10 14:08:21) Just a few comments... A few weeks ago, I upgraded one server from 11.0 to 11.1 via ssh using zypper dup. zypper and its related libraries have to be upgraded first in order to avoid problems, especially if the upgrade process is interrupted. Another issue besides the order of the upgrade, would be restarting daemons and dealing with new .conf. Maybe we could check if it has been edited, if not, then automerge it. Some stuff could malfunction due to old config files. We could also have a manual merge option. Another thing... wouldn't it be better to download all the packages at once and install them afterwards instead of downloading/installing package by package? On a side note, I want to say that my upgrade went smoothly (rcpbind wasn't installed but I consider that a small issue). zypper has been improved a lot. It would be great if zypper dup was officially supported as another upgrade method. #29: Peter Poeml (poeml) (2009-03-10 14:35:19) (reply to #28) Regarding config merge on update, I have played with two things. First, the yum plugin called yum-merge-conf, which allows for interactive merging of config files during the upgrade. Works and gets the job done, and could be done in zypper as well, however from my own experience I have to say that it protracts the update more than I sometimes like, and I typically want to do this job in a separate step (after the packages are updated). not protract the update for merging all files. So I rather use another approach, which is a script called rpmresolve (https://build.opensuse.org/package/view_file?file=rpmresolve&package=server… 3Apoeml), which works in a similar way, based on presence of rpmsave/rpmnew files. It opens vim in diff mode, lets you merge and asks you which version you want to keep. Works well for me since years, it just might require refinement of some things of the implementation in a more generic way (e.g. calling $EDITOR with different option than - d). #31: andrea florio (anubisg1) (2009-07-10 00:11:07) i think that we miss something like that: https://help.ubuntu.com/community/JauntyUpgrades it's so easy to upgrade an ubuntu version that also my 5 years old student was able to do it.. #32: Ralph Ulrich (ulenrich) (2009-08-04 16:14:39) I just did a distribution upgrade from 11.1 to 11.2 factory using "zypper dup". I did uninstall a lot before to have less problems. After upgrade there were some repository problems, like I was not able to see opera any more. I remove all of /var/cache/zypp/raw/* after which I could install opera. Seems to be some work left on zypper to be able to dist-upgrade .... #39: Greg Freemyer (gregfreemyer) (2009-08-17 16:23:56) (reply to #32) I think repository management is not getting enough attention in this discussion. Per http://en.opensuse.org/Upgrade/11.2#Command_line it is step one, but I don't see any tool / script etc. shown for assisting the user in doing this. At a minimum a simple script should be created and rolled via updates that allows a user to review the current repositories and disable the 11.1 ones and create the 11.2 ones. Complicating this is all the OBS / packman / other repositories that many users now have in a standard setup. I think the tool needs to somehow address these. Even if only to say. "Automated replacement of this repository is not supported. Disabled for distribution upgrade process. Please seperately add a 11.2 repository for these functions if needed after the upgrade." FYI: does this specific feature deserve its own fate entry? #40: Ján Kupec (jkupec) (2009-08-17 18:46:01) (reply to #39) Not a bad idea, but the thing is that we can only do this reliably for the main repo (containing the openSUSE-11.1 product definition) and its update repo. Plus we can search for common OBS path components like openSUSE_Factory and tell the user that s/he needs to change these into openSUSE_11.2 where available (or do that automatically if the user agrees). Yeah, might be worth doing. Should do something like this (with user interaction added, and corrected of course :O) zypper lr -e my11.1repos.repo # backup your list of repos zypper mr -da #disable all repos zypper rr $(get-the-official-11.1-repos) # remove the official main/non-oss/update repos zypper ar http://download.opensuse.org/distribution/11.2/repo/oss/ main zypper ar http://download.opensuse.org/distribution/11.2/repo/non-oss/ nonoss zypper ar http://download.opensuse.org/update/11.2 updates # and optionally for url in $(zypper lr -u | grep -E 'openSUSE_(Factory|11.1|11.0)' | extract-the-URL); do zypper rr $url newurl=$(echo $url | sed -r -e 's/openSUSE_(Factory|11.1|11.0) /openSUSE_11.2/') curl ...something... $newurl # check if the new url is available if $?; then zypper ar $newurl $well-we-should-use-the-old-alias-here fi done remove-all-disabled-repos-with-user-approval # and optionally zypper ref zypper mr -kt zypper up zypper libzypp zypper dup --download-only zypper dup I'm not sure if this needs a separate fate request. Looks like this can be done quickly in bash or perl, i hope i'm right. I'm not sure about rolling this as an 11.1 update, though. Would need to be part of some package. Isn't having it available from a link at the update instruction enough? #41: Greg Freemyer (gregfreemyer) (2009-08-20 05:30:56) (reply to #40) The instructions at http://en.opensuse.org/Upgrade/11.2#Command_line call for having the latest zypper package. (ie. zypper in zypper) If you take the script you wrote and call it "zypper-dup" or similar and add it to the zypper package, then tell everyone that an upgrade is accomplished via zypped-dup most people won't need instructions. Currently most of the email posts say something like "I upgraded via zypper -dup and ....". It gives the casual reader the false impression that they just need to call zypper -dup. So my vote is have a single script that manages the full upgrade, including any necessary notes and warnings, and we don't require users in general to have to go find a website to read the update instructions. #42: Ralph Ulrich (ulenrich) (2009-08-21 16:35:09) (reply to #40) With the last 3 commands I migrated successfully from 11.1 to 11.2 ten days ago (some manual work of above done before). As command "dup" is defined "distribution upgrade" , a command "zypper dup" should automatically: zypper up zypper libzypp; respawn zypper dup --download-before #49: Greg Freemyer (gregfreemyer) (2009-09-18 15:24:18) (reply to #40) I just happened to look at the current generic Upgrade instructions. - The handling of previous repos there seems pretty drastic to me: mv /etc/zypp/repos.d /etc/zypp/repos.d-backup See: http://en.opensuse.org/Upgrade#Removing_old_repositories (http://en.opensuse.org/Upgrade#Removing_old_repositories) - Seems to me with the community repos, one click installs, etc. this does not even come close to addressing the issues at hand. The good part is it may allow the zypper dup to run cleanly. I have never used the above process to try a zypper dup upgrade, so maybe my concerns are overblown. #33: Ralph Ulrich (ulenrich) (2009-08-08 13:38:58) At the moment in the forums you can notice various problems upgrading to Kde-4.3 due to changed naming convention (drop of kde4- prefix). A proper packaging system should be able to handle that without problems. Debian style to solve this problem is to use meta/transitional-packages: empty packages which pull in the needed packages #34: Stephan Binner (beineri) (2009-08-08 14:17:53) (reply to #33) zypper dup handles those renames just fine. #35: Ralph Ulrich (ulenrich) (2009-08-08 15:02:58) (reply to #34) ; ) Are these problems people discuss only about problematic one-klick upgrades .... #43: andrea florio (anubisg1) (2009-08-24 15:49:43) (reply to #34) the problem here is the packager, any package that change name must provides and obsoletes the onld name in spec file. #36: Karl Eichwalder (keichwa) (2009-08-11 13:53:11) Docs department speaking ;) From the documentation POV this is a prio 1 feature. This means we must know ASAP, what's the status of this feature and what do you intend to do about it until your deadline. Please, summarize the status otherwise it is difficult to provide useful documentation. For example, we must know what are the pre-requisites the user is required to perform. Some of these are mentioned above (close all applications, add a catalog XYZ, update to version 11.1 + all online updates first, etc.). Developers, please take the time to provide the wanted info. Project/Product Mangers, please clarify open issues. #37: Jean-Daniel Dodin (jdd_sysop) (2009-08-17 08:37:57) Youi have to manage the case where an application is not anymore part of the distro. For example dovecot was and is no more (and have no replacement). This is much difficult to handle. Could it be possible to have a "diagnostic tool", zypper -dup-diag (?) that could scan the system and report the work to do? - list the non compatible applications or running daemons - list the new conf file that will have to be setup... jdd #38: Cristian Rodríguez (elvigia) (2009-08-17 14:17:08) (reply to #37) dovecot11 Obsoletes dovecot, that is the easier case to handle. #44: andrea florio (anubisg1) (2009-08-24 15:50:53) Are there any news here? this topic looks to be dead #47: Karl Eichwalder (keichwa) (2009-09-10 06:54:02) Please, take the time to summarize the implementation--see comment #36. If you do not, I take it for granted that it works as outlined in the description (modulo gesunder menschenverstand/human sense). We are quickly approaching the documentation deadlines for openSUSE 11.2. #48: Stephan Kulow (coolo) (2009-09-16 14:32:48) (reply to #47) there is no "implementation" per se. It just works and if it does not work, we need to fix bugs in the packages. #50: andrea florio (anubisg1) (2009-10-19 13:18:43) (reply to #48) in other words... how can i move from 11.2 to 11.3? there will be any GUI? (something like that? https://help.ubuntu.com/community/JauntyUpgrades?action=AttachFile&do=get&t… ) - #51: John Beranek (johnberanek) (2009-10-28 18:41:52) (reply to #50) Even Fedora manage something like this (although it's not an online upgrade). ;) - -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[New: openFATE 308267] Please have the languages completely translated for openSUSE 11.2/3 LiveCDs
by fate_noreply＠suse.de 30 Oct '09

30 Oct '09

Feature added by: Praveen Kunjapur (stilo_vingyou) Feature #308267, revision 1 Title: Please have the languages completely translated for openSUSE 11.2/3 LiveCDs openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Praveen Kunjapur (stilo_vingyou) Description: "The most spoken language in the world is Chinese then English in second place. In terms of most spoken native languages of people it is Chinese, Hindi and Spanish then English in fourth place." - it says from here: http://gu.wikipedia.org/wiki/%E0%AA%85%E0%AA%82%E0%AA%97%E0%AB%8D%E0%AA%B0%… (http://gu.wikipedia.org/wiki/%E0%AA%85%E0%AA%82%E0%AA%97%E0%AB%8D%E0%AA%B0%…) IMHO, the above languages should be made available on openSUSE 11.2/3 LiveCDs completely translated as majority of users can get started with openSUSE quickly. -- openSUSE Feature: https://features.opensuse.org/308267

1 1

[New: openFATE 308264] xorg.conf editor
by fate_noreply＠suse.de 29 Oct '09

29 Oct '09

Feature added by: William Sanjaya (swilliam87) Feature #308264, revision 1 Title: xorg.conf editor openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: William Sanjaya (swilliam87) Description: Wouldn't it be cool to have auto-completion, typo detection, and even 'proposed configuration' or templates for these configuration files integrated to one of those default text editors, say, Kwrite? For the unenlightened like me. -- openSUSE Feature: https://features.opensuse.org/308264

1 1

[openFATE 306656] Quick hack for anonymous read-only access to build service
by fate_noreply＠suse.de 29 Oct '09

29 Oct '09

Feature added by: Juergen Weigert (jnweiger) Feature #306656, revision 1 Title: Quick hack for anonymous read-only access to build service Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Juergen Weigert (jnweiger) Description: Currently iChains is in front of build.opensuse.org, thus a read-only mode without login is not possible. As a quickfix hack: Let us implement a Guest User, who can login to iChains with one mouseclick. The Guest User shall have no write permissions, but shall have a login button, which allows user to change to their own login later. -- openSUSE Feature: https://features.opensuse.org/306656

1 5

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 29 Oct '09

29 Oct '09

Feature changed by: Reinhard Max (rmax) Feature #120340, revision 118 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) This is how it works for quite some time. Repositories providing patches also provide the packages so that they can be installed directly from the update repositories (provided they contain newer version). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #20: Jörn Knie-von Allmen (phisiker) (2009-08-05 12:12:29) (reply to #16) Please do not reject. With a downloadprotocol this should be solvable. The Installtask can poll an that protocol (or be informed by a Signal when a download has ended. This is better then polling. Or if prefering an IPC-Framework: D-BUS. Never mind!). Such problems I had some times often to solve (but in Java) and generally, it isn't so dificult. #21: Ralph Ulrich (ulenrich) (2009-08-05 13:03:25) (reply to #20) Please reject forever: As operating system are sort of highly integrated databases there should be a commit like funcutionality: First download then install (like debian). Otherwise repositories representing a rolling release (factory) will potentially break an updating system. #22: Reinhard Max (rmax) (2009-08-06 16:18:54) (reply to #21) Yes, there are situations where this (optional) feature should better not be used, but that does not mean it should not be implemented, because there are many situations where it can be very useful. BTW, how would "download then install" give you anything near commit- like functionality? Factory could still change on the server while you are downloading and packages could still fail during installation, leaving you with an inconsistent installation. #24: Ralph Ulrich (ulenrich) (2009-08-11 23:42:59) (reply to #22) Yes, "still fail during installation": there is no commit-like functionality But in case of a changed Factory repository there would be an error: zypper dup --download-then-install || ( zypper ref && zypper dup) || ... In this more often case there would be a commit-like functionality #25: Reinhard Max (rmax) (2009-08-12 11:22:08) (reply to #24) I think the most common case is end users installing from mostly static repositories such as the original release and the official updates. That's what I had in mind when I first suggested this feature many many years ago when there was no openSUSE or Factory. So, please don't insist in this feature being rejected just because you don't have a usecase for it yourself. Nobody will force you to use it if you don't want to. #23: Reinhard Max (rmax) (2009-08-06 16:20:58) (reply to #16) As I've explained in comment #9, the different modes of operation would have been possible with a single implementation and different runtime parameters. I think this would actually be easier than implementing the different modes separately, so why hasn't it been considered? #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) Guys, as Duncan wrote in c#16, we are already developing the "download all, install all" mode (currently we only have "download one, install one, ..."), and yes, users will be able to choose one of these. This particular feature would be an improvement of the current mode: "download one, install one while downloading others, ...". I hope this clarifies the current status a bit. #26: Eduard Avetisyan (dich) (2009-09-15 09:16:15) (reply to #19) Sorry Jan, I think both "download one, install one, download next, install next..." and " download all, install all" are both MUCH slower than " download one, install one, download next in parallel ". Come on guys, you focused on two SLOW modes and left the only fast one for future, and that's since 5 versions! Why not reserve a couple of hundred MB (customizable) of diskspace and cache the downloads there while installing in the meantime. Hope it's not too late to think of it for os11.2... #27: Michael Kromer (mkromer) (2009-10-23 01:11:45) (reply to #26) Absolutely: I agree with you Eduard. The optimized way is to run a download process while rpm -{i,U} is running in the background, as all resources (Disk I/O, CPU, Net) can get used parallel. The only trick is to keep the installation of following packages on hold, if there is some kind of package which takes longer (like kernel-{default,source}; to keep --requires safe; example: kmp's which rely on the specific kernel version to be installed first, however even this could be developed in an optimized way, as package lists and therefore also package requirements are available at time of download). I think there would even be real great customization options possible like an option such as --download-threads. So if the installation/upgrade can keep up with the downloadspeed you will get *significant* performance. And even if not -> it could never get slower. #28: Reza Davoudi (rd1381) (2009-10-27 14:35:07) plz make it so that it be an option in GUI not just command line i am sick of going through cmdline flags and options #29: John Bester (johnbester) (2009-10-29 07:13:05) I think the proposed sulotion will help, but to me this is not the real important issue. The most frustrating issue around installing a small package using YaST is the repository upgrade that must complete before you can do anything. (Unfortunately we do not all have the internet speeds as are the norm in Europe and US). The worst is actually when you have your laptop somewhere where you do not have internet access and have to wait for connection timeouts before you can do an installation. It happened a few times that I just wanted to install a small tool which slipped my mind when I did a clean install (such as midnight commander) quickly so that I can continue with what I am doing. At this point I am not fussed about having the absolute latest security fix - I just need to get going. In any case, I would propose that when you open the package manager, it should kick off a thread to download repository updates into a temp folder. The next time you start the package manader, it can simply replace those repositories for which there are updates available in the temp folder. My reasoning is: If I opened the package manager yesterday and I open it again today (and maybe again later today), why should I always wait a few minutes before I can start selecting packages? Switching off the refresh feature in "Software repostories" is not an option, because it takes too long and you typically do not want it switched off. + #30: Reinhard Max (rmax) (2009-10-29 09:59:10) (reply to #29) + Please open a new feature request for your proposal, as it is unrelated + to the feature that is being discussed here. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 305018] Get bugowner ID from buildservice without login
by fate_noreply＠suse.de 29 Oct '09

29 Oct '09

Feature changed by: Adrian Schröter (adrianSuSE) Feature #305018, revision 8 Title: Get bugowner ID from buildservice without login Buildservice: Evaluation Priority Requester: Desirable + Projectmanager: Mandatory Requested by: Jan Blunck (janblunck) Description: For automatic crash reporting it is useful to get information about the buildservice project the package is coming from. If the bugowner is set by the project the report can be assigned to him. If the bugowner is not set the crash report can be skipped. I need a way to get the bugowner id or email adress without forcing the user to have a buildservice login. + Discussion: + #1: Adrian Schröter (adriansuse) (2009-10-29 08:43:26) + part of our anonymous access project... -- openSUSE Feature: https://features.opensuse.org/305018

1 0

[openFATE 307907] packages.?? i18n file generation from .po files
by fate_noreply＠suse.de 29 Oct '09

29 Oct '09

Feature added by: Adrian Schröter (adrianSuSE) Feature #307907, revision 1 Title: packages.?? i18n file generation from .po files Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Adrian Schröter (adriansuse) Description: We have currently no translations in suse tags meta data for the packages due to the switch from PDB to svn. This is a regression, so coolo is in favour to get this back for 11.2. We need to provide the translations via a package and adapt create_package_descr to read data from there instead from PDB files. Lars, do you think this is doable for 11.2 ? We may or may not need to adapt the inst-source plugin of kiwi for this. -- openSUSE Feature: https://features.opensuse.org/307907

1 1

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 29 Oct '09

29 Oct '09

Feature changed by: John Bester (johnbester) Feature #120340, revision 117 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) This is how it works for quite some time. Repositories providing patches also provide the packages so that they can be installed directly from the update repositories (provided they contain newer version). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #20: Jörn Knie-von Allmen (phisiker) (2009-08-05 12:12:29) (reply to #16) Please do not reject. With a downloadprotocol this should be solvable. The Installtask can poll an that protocol (or be informed by a Signal when a download has ended. This is better then polling. Or if prefering an IPC-Framework: D-BUS. Never mind!). Such problems I had some times often to solve (but in Java) and generally, it isn't so dificult. #21: Ralph Ulrich (ulenrich) (2009-08-05 13:03:25) (reply to #20) Please reject forever: As operating system are sort of highly integrated databases there should be a commit like funcutionality: First download then install (like debian). Otherwise repositories representing a rolling release (factory) will potentially break an updating system. #22: Reinhard Max (rmax) (2009-08-06 16:18:54) (reply to #21) Yes, there are situations where this (optional) feature should better not be used, but that does not mean it should not be implemented, because there are many situations where it can be very useful. BTW, how would "download then install" give you anything near commit- like functionality? Factory could still change on the server while you are downloading and packages could still fail during installation, leaving you with an inconsistent installation. #24: Ralph Ulrich (ulenrich) (2009-08-11 23:42:59) (reply to #22) Yes, "still fail during installation": there is no commit-like functionality But in case of a changed Factory repository there would be an error: zypper dup --download-then-install || ( zypper ref && zypper dup) || ... In this more often case there would be a commit-like functionality #25: Reinhard Max (rmax) (2009-08-12 11:22:08) (reply to #24) I think the most common case is end users installing from mostly static repositories such as the original release and the official updates. That's what I had in mind when I first suggested this feature many many years ago when there was no openSUSE or Factory. So, please don't insist in this feature being rejected just because you don't have a usecase for it yourself. Nobody will force you to use it if you don't want to. #23: Reinhard Max (rmax) (2009-08-06 16:20:58) (reply to #16) As I've explained in comment #9, the different modes of operation would have been possible with a single implementation and different runtime parameters. I think this would actually be easier than implementing the different modes separately, so why hasn't it been considered? #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) Guys, as Duncan wrote in c#16, we are already developing the "download all, install all" mode (currently we only have "download one, install one, ..."), and yes, users will be able to choose one of these. This particular feature would be an improvement of the current mode: "download one, install one while downloading others, ...". I hope this clarifies the current status a bit. #26: Eduard Avetisyan (dich) (2009-09-15 09:16:15) (reply to #19) Sorry Jan, I think both "download one, install one, download next, install next..." and " download all, install all" are both MUCH slower than " download one, install one, download next in parallel ". Come on guys, you focused on two SLOW modes and left the only fast one for future, and that's since 5 versions! Why not reserve a couple of hundred MB (customizable) of diskspace and cache the downloads there while installing in the meantime. Hope it's not too late to think of it for os11.2... #27: Michael Kromer (mkromer) (2009-10-23 01:11:45) (reply to #26) Absolutely: I agree with you Eduard. The optimized way is to run a download process while rpm -{i,U} is running in the background, as all resources (Disk I/O, CPU, Net) can get used parallel. The only trick is to keep the installation of following packages on hold, if there is some kind of package which takes longer (like kernel-{default,source}; to keep --requires safe; example: kmp's which rely on the specific kernel version to be installed first, however even this could be developed in an optimized way, as package lists and therefore also package requirements are available at time of download). I think there would even be real great customization options possible like an option such as --download-threads. So if the installation/upgrade can keep up with the downloadspeed you will get *significant* performance. And even if not -> it could never get slower. #28: Reza Davoudi (rd1381) (2009-10-27 14:35:07) plz make it so that it be an option in GUI not just command line i am sick of going through cmdline flags and options + #29: John Bester (johnbester) (2009-10-29 07:13:05) + I think the proposed sulotion will help, but to me this is not the real + important issue. The most frustrating issue around installing a small + package using YaST is the repository upgrade that must complete before + you can do anything. (Unfortunately we do not all have the internet + speeds as are the norm in Europe and US). The worst is actually when + you have your laptop somewhere where you do not have internet access + and have to wait for connection timeouts before you can do an + installation. It happened a few times that I just wanted to install a + small tool which slipped my mind when I did a clean install (such as + midnight commander) quickly so that I can continue with what I am + doing. At this point I am not fussed about having the absolute latest + security fix - I just need to get going. + In any case, I would propose that when you open the package manager, it + should kick off a thread to download repository updates into a temp + folder. The next time you start the package manader, it can simply + replace those repositories for which there are updates available in the + temp folder. My reasoning is: If I opened the package manager yesterday + and I open it again today (and maybe again later today), why should I + always wait a few minutes before I can start selecting packages? + Switching off the refresh feature in "Software repostories" is not an + option, because it takes too long and you typically do not want it + switched off. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 28 Oct '09

28 Oct '09

Feature changed by: John Beranek (johnberanek) Feature #305634, revision 163 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Relations: - Fedora Upgrade Instructions (feature/id: http://fedoraproject.org/wiki/YumUpgradeFaq) - Wiki page for implementation (url: http://en.opensuse.org/Upgrade/11.2) - Debian Upgrade How-to (url: http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.ht…) Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #30: Peter Poeml (poeml) (2009-03-10 15:31:10) (reply to #25) Interesting discussion about that particular issue, but simple to solve. What works is keeping devs.rpm, and/or simply rpm -e --justdb it. (It's enough to do so later.) The more complicated issues in the past where a case where the kernel changed its major version, and some networking applications could not start with the (still running) old kernel. Didn't prevent an online upgrade over the network though, and applications could keep running. When skipping several openSUSE versions, and differences have accumulated, in can happen that an upgrade in one step is not possible. It's not possible to upgrade from 9.0 to 10.1 without first updating to 9.1, due to the kernel. These issues are quickly found by experimentation though. Other than that, the most hurting issue during remote upgrades is the difficulty to ensure persistent device naming for NICs, because that is reimplemented / changed with each openSUSE version, the upgrade procedure is not well documented, and funny surprises are the rule, and it often simply doesn't work. Other small hurdles are the increasing modularization of kernel, which can lead to lack of support for chipsets and storage in the initrd, package split-offs (mingetty) that lead to lack of essential components after the upgrade. It pays to make sure that all packages are installed which are in the "minimal" patter of that openSUSE version. And the required but disappeared PAM module locked us out once also... A word to all the non-believers who think that upgrades don't work: I have upgraded dozens of systems remotely during the last decade. All my productive systems are repeatedly upgraded that way since day one. Unfortunately, the tools we have didn't help with this. Apart from using rpm, I started doing this with yum a few years ago (if it works, metadata is available, falling back to rpm if needed). Last year I documented some steps: http://poeml.de/~poeml/10.1-11.0-update/update-11.0.howto. With today's conveniency of virtualization at hand, I actually did an upgrade by experiment with a VM first, to minimize the risk, and documented all the steps. Since I had to upgrade several 10.1 machines, this seemed like a good idea to reduce the risk and save brain energy. The notes from it are a good outcome, too. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to #20) this is very helpful, we should look at the bumps that Debian hits while doing this. On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL 5.3, and it went without a hitch. There may be something to be gathered from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. #28: Javier Llorente (javierllorente) (2009-03-10 14:08:21) Just a few comments... A few weeks ago, I upgraded one server from 11.0 to 11.1 via ssh using zypper dup. zypper and its related libraries have to be upgraded first in order to avoid problems, especially if the upgrade process is interrupted. Another issue besides the order of the upgrade, would be restarting daemons and dealing with new .conf. Maybe we could check if it has been edited, if not, then automerge it. Some stuff could malfunction due to old config files. We could also have a manual merge option. Another thing... wouldn't it be better to download all the packages at once and install them afterwards instead of downloading/installing package by package? On a side note, I want to say that my upgrade went smoothly (rcpbind wasn't installed but I consider that a small issue). zypper has been improved a lot. It would be great if zypper dup was officially supported as another upgrade method. #29: Peter Poeml (poeml) (2009-03-10 14:35:19) (reply to #28) Regarding config merge on update, I have played with two things. First, the yum plugin called yum-merge-conf, which allows for interactive merging of config files during the upgrade. Works and gets the job done, and could be done in zypper as well, however from my own experience I have to say that it protracts the update more than I sometimes like, and I typically want to do this job in a separate step (after the packages are updated). not protract the update for merging all files. So I rather use another approach, which is a script called rpmresolve (https://build.opensuse.org/package/view_file?file=rpmresolve&package=server… 3Apoeml), which works in a similar way, based on presence of rpmsave/rpmnew files. It opens vim in diff mode, lets you merge and asks you which version you want to keep. Works well for me since years, it just might require refinement of some things of the implementation in a more generic way (e.g. calling $EDITOR with different option than - d). #31: andrea florio (anubisg1) (2009-07-10 00:11:07) i think that we miss something like that: https://help.ubuntu.com/community/JauntyUpgrades it's so easy to upgrade an ubuntu version that also my 5 years old student was able to do it.. #32: Ralph Ulrich (ulenrich) (2009-08-04 16:14:39) I just did a distribution upgrade from 11.1 to 11.2 factory using "zypper dup". I did uninstall a lot before to have less problems. After upgrade there were some repository problems, like I was not able to see opera any more. I remove all of /var/cache/zypp/raw/* after which I could install opera. Seems to be some work left on zypper to be able to dist-upgrade .... #39: Greg Freemyer (gregfreemyer) (2009-08-17 16:23:56) (reply to #32) I think repository management is not getting enough attention in this discussion. Per http://en.opensuse.org/Upgrade/11.2#Command_line it is step one, but I don't see any tool / script etc. shown for assisting the user in doing this. At a minimum a simple script should be created and rolled via updates that allows a user to review the current repositories and disable the 11.1 ones and create the 11.2 ones. Complicating this is all the OBS / packman / other repositories that many users now have in a standard setup. I think the tool needs to somehow address these. Even if only to say. "Automated replacement of this repository is not supported. Disabled for distribution upgrade process. Please seperately add a 11.2 repository for these functions if needed after the upgrade." FYI: does this specific feature deserve its own fate entry? #40: Ján Kupec (jkupec) (2009-08-17 18:46:01) (reply to #39) Not a bad idea, but the thing is that we can only do this reliably for the main repo (containing the openSUSE-11.1 product definition) and its update repo. Plus we can search for common OBS path components like openSUSE_Factory and tell the user that s/he needs to change these into openSUSE_11.2 where available (or do that automatically if the user agrees). Yeah, might be worth doing. Should do something like this (with user interaction added, and corrected of course :O) zypper lr -e my11.1repos.repo # backup your list of repos zypper mr -da #disable all repos zypper rr $(get-the-official-11.1-repos) # remove the official main/non-oss/update repos zypper ar http://download.opensuse.org/distribution/11.2/repo/oss/ main zypper ar http://download.opensuse.org/distribution/11.2/repo/non-oss/ nonoss zypper ar http://download.opensuse.org/update/11.2 updates # and optionally for url in $(zypper lr -u | grep -E 'openSUSE_(Factory|11.1|11.0)' | extract-the-URL); do zypper rr $url newurl=$(echo $url | sed -r -e 's/openSUSE_(Factory|11.1|11.0) /openSUSE_11.2/') curl ...something... $newurl # check if the new url is available if $?; then zypper ar $newurl $well-we-should-use-the-old-alias-here fi done remove-all-disabled-repos-with-user-approval # and optionally zypper ref zypper mr -kt zypper up zypper libzypp zypper dup --download-only zypper dup I'm not sure if this needs a separate fate request. Looks like this can be done quickly in bash or perl, i hope i'm right. I'm not sure about rolling this as an 11.1 update, though. Would need to be part of some package. Isn't having it available from a link at the update instruction enough? #41: Greg Freemyer (gregfreemyer) (2009-08-20 05:30:56) (reply to #40) The instructions at http://en.opensuse.org/Upgrade/11.2#Command_line call for having the latest zypper package. (ie. zypper in zypper) If you take the script you wrote and call it "zypper-dup" or similar and add it to the zypper package, then tell everyone that an upgrade is accomplished via zypped-dup most people won't need instructions. Currently most of the email posts say something like "I upgraded via zypper -dup and ....". It gives the casual reader the false impression that they just need to call zypper -dup. So my vote is have a single script that manages the full upgrade, including any necessary notes and warnings, and we don't require users in general to have to go find a website to read the update instructions. #42: Ralph Ulrich (ulenrich) (2009-08-21 16:35:09) (reply to #40) With the last 3 commands I migrated successfully from 11.1 to 11.2 ten days ago (some manual work of above done before). As command "dup" is defined "distribution upgrade" , a command "zypper dup" should automatically: zypper up zypper libzypp; respawn zypper dup --download-before #49: Greg Freemyer (gregfreemyer) (2009-09-18 15:24:18) (reply to #40) I just happened to look at the current generic Upgrade instructions. The handling of previous repos there seems pretty drastic to me: mv /etc/zypp/repos.d /etc/zypp/repos.d-backup See: http://en.opensuse.org/Upgrade#Removing_old_repositories (http://en.opensuse.org/Upgrade#Removing_old_repositories) Seems to me with the community repos, one click installs, etc. this does not even come close to addressing the issues at hand. The good part is it may allow the zypper dup to run cleanly. I have never used the above process to try a zypper dup upgrade, so maybe my concerns are overblown. #33: Ralph Ulrich (ulenrich) (2009-08-08 13:38:58) At the moment in the forums you can notice various problems upgrading to Kde-4.3 due to changed naming convention (drop of kde4- prefix). A proper packaging system should be able to handle that without problems. Debian style to solve this problem is to use meta/transitional-packages: empty packages which pull in the needed packages #34: Stephan Binner (beineri) (2009-08-08 14:17:53) (reply to #33) zypper dup handles those renames just fine. #35: Ralph Ulrich (ulenrich) (2009-08-08 15:02:58) (reply to #34) ; ) Are these problems people discuss only about problematic one-klick upgrades .... #43: andrea florio (anubisg1) (2009-08-24 15:49:43) (reply to #34) the problem here is the packager, any package that change name must provides and obsoletes the onld name in spec file. #36: Karl Eichwalder (keichwa) (2009-08-11 13:53:11) Docs department speaking ;) From the documentation POV this is a prio 1 feature. This means we must know ASAP, what's the status of this feature and what do you intend to do about it until your deadline. Please, summarize the status otherwise it is difficult to provide useful documentation. For example, we must know what are the pre-requisites the user is required to perform. Some of these are mentioned above (close all applications, add a catalog XYZ, update to version 11.1 + all online updates first, etc.). Developers, please take the time to provide the wanted info. Project/Product Mangers, please clarify open issues. #37: Jean-Daniel Dodin (jdd_sysop) (2009-08-17 08:37:57) Youi have to manage the case where an application is not anymore part of the distro. For example dovecot was and is no more (and have no replacement). This is much difficult to handle. Could it be possible to have a "diagnostic tool", zypper -dup-diag (?) that could scan the system and report the work to do? - list the non compatible applications or running daemons - list the new conf file that will have to be setup... jdd #38: Cristian Rodríguez (elvigia) (2009-08-17 14:17:08) (reply to #37) dovecot11 Obsoletes dovecot, that is the easier case to handle. #44: andrea florio (anubisg1) (2009-08-24 15:50:53) Are there any news here? this topic looks to be dead #47: Karl Eichwalder (keichwa) (2009-09-10 06:54:02) Please, take the time to summarize the implementation--see comment #36. If you do not, I take it for granted that it works as outlined in the description (modulo gesunder menschenverstand/human sense). We are quickly approaching the documentation deadlines for openSUSE 11.2. #48: Stephan Kulow (coolo) (2009-09-16 14:32:48) (reply to #47) there is no "implementation" per se. It just works and if it does not work, we need to fix bugs in the packages. #50: andrea florio (anubisg1) (2009-10-19 13:18:43) (reply to #48) in other words... how can i move from 11.2 to 11.3? there will be any GUI? (something like that? https://help.ubuntu.com/community/JauntyUpgrades?action=AttachFile&do=get&t… ) + #51: John Beranek (johnberanek) (2009-10-28 18:41:52) (reply to #50) + Even Fedora manage something like this (although it's not an online + upgrade). ;) + -- openSUSE Feature: https://features.opensuse.org/305634

1 0

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

28 Oct '09

Feature changed by: Wang Lance (lzwang) Feature #305657, revision 49 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. -- openSUSE Feature: https://features.opensuse.org/305657

1 0