May 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 303873] Reducing pop ups during installation
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303873, revision 15 Title: Reducing pop ups during installation openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 11:01:26 reject reason: This can wait. Postponing. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Martin Schmidkunz (mschmidkunz) Description: Before installing the system the user is asked to confirm various licenses. Each license is presented via pop up. Depending on the selected packages the user might be forced to accept quite a lot of them. This is quite unusable and we should think about how to reduce these. One idea might be: http://en.opensuse.org/Image:Installation_nopopups.png Not for SLES: Furthermore after accepting all these licenses the user has to confirm the installation in an extra pop up. I do not see the necessity for that pop up as users made the experience with other operating systems who do not ask the user for comfirmation (Apple Mac OS, MS Windows, Ubuntu, Red Hat Enterprise Linux, Fedora) that installation means that something will happen to their hard drive. Discussion: #1: Matthias Eckermann (mge1512) (2008-05-15 12:10:27) I agree with and like: http://en.opensuse.org/Image:Installation_nopopups.png But the extra pop-up for "YES, I really want to wipe my harddisk" must remain, as it is a security and safetiness issue. Marking this part of the idea as "Not for SLES". Federico, what is your opinion here? #2: Michael Löffler (michl19) (2008-05-15 12:27:44) Ciaran can you give the view from a legal perspective? #3: Ciaran Farrell (babelworx) (2008-05-16 11:51:38) I like the setup described in the screenshot and believe that it certainly gives the person installing the opportunity to review every license individually. In fact, I'm going to suggest to Patrick Mc Bride that this could be a default license acceptance method as it is far better than what we currently have available (i.e. all or nothing system). I'll ask Christopher De Nicolo for his opinion (from a german legal perspective). #4: Federico Lucifredi (flucifredi) (2008-05-22 15:47:44) I just went through the 11.0 beta 3 workflow, and I am satisfied with the current state. the mock-up is ok, but consider this: while it is true that you get prompted 5 times to approve licenses, if there is something that users are trained to do, in all platforms, is precisely click accept :-) I would say we can proceed with it, but I don't consider it a major issue, and not a usability problem. by the way, the 11.0 install workflow rocks :-) -- openSUSE Feature: https://features.opensuse.org/303873

1 0

[openFATE 305285] dictionary and DoS attack protection based using log scanning and dynamic firewall ban
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305285, revision 15 Title: dictionary and DoS attack protection based using log scanning and dynamic firewall ban openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Description: Detailed Description For these attackss, usually the application/service will not allow the attacker to break in, however once a malicious password guess or DoS attack is done, baning the connection for some minutes and then an unban time of several minutes is usually enough to stop a network connection being flooded, as well as reducing the likelihood of a successful dictionary attack. The situation goes this way: - attacker starts a password guess - the system detects Y continuous failed attempts to login in the log file of the service - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again - attacker starts a DoS attack - the system detects Y continuous connections without login - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again Scope To provide an extra option in the firewall which allows to select which services to monitor (usually by looking at patterns in the log file ) and block the ip for a configurable interval once a dictionary attack or DoS is suspected. The option could be as well in the service module (or in both) or even in the specific service configuration module. Usually parameters to configure are the patterns and the actions. Also, YaST should tell the user to install the required packages if this option is enabled. To be defined in the scope is how much configurability is needed. If known services will be protected, or if a generic way to define protection for an arbitrary service is desired. Possible Implementation Fail2Ban provices right now most of the functionality. Provides a service that allows to define jails, a jail is a pattern and an action. A service can have more than one jail. For example the patterns for an ssh DoS attack is different than a dictionary attack on the same service, and the ban times may be different. Fail2Ban provides generic functionality not tied to any specific service and comes with predefined patterns and actions for various popular services as sshd, apache2 http authentication and others. http://en.wikipedia.org/wiki/Fail2ban http://www.fail2ban.org YaST would need to write the configuration about which patterns to use depending on the service to protect, or optionally define patterns for unknown services, same with actions, and start or stop the service depending on this functionality being enabled or not. Test Plan Doing serveral failed attempts on the ssh server should block the user for 3 minutes. Simple testcase. User Experience The functionality should be availabe in a clever location (which can be more than one, for example, firewall, services or the specific module), allowing to turn it on with sane defaults (hopefully provide the defaults fail2ban provides). The user can see the blocked attempts in the logs. Dependencies Using the fail2ban approach would require the fail2ban package, which in turns requires python, available in the openSUSE build service from a community user home project. (home:leonardocf) Contingency Plan None, as the functionality was not available before. Relations: - Preventing Brute Force Attacks With Fail2ban On OpenSUSE 10.3 (url: http://www.howtoforge.com/fail2ban_opensuse10.3) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:50:52) I don't know about the enteprise angle (I need to think), but for the community distro it seems quite a cool feature. + #3: Christoph Thiel (cthiel1) (2009-05-26 18:50:09) + We won't be able to implement this feature in 11.2 within the YaST + teams. Maybe still something for the community? -- openSUSE Feature: https://features.opensuse.org/305285

1 0

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

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305634, revision 114 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation 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: - Wiki page for implementation (url: http://en.opensuse.org/Upgrade/11.2) 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). -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 120053] Restrict Services By Interface in Inetd YaST module
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #120053, revision 35 Title: Restrict Services By Interface in Inetd YaST module openSUSE-10.3: Rejected by Thorsten Kukuk (kukuk) reject date: 2007-11-21 10:53:32 reject reason: Rewrite postponed to 11.1 Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2006-09-06 16:49:59 reject reason: Affected module will be rewritten for 10.3. Priority Requester: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-06-27 14:32:29 reject reason: Out of resources, postponing. Priority Requester: Desirable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-05-26 20:39:11 + reject reason: Out of resources for 11.2. Existing functionallity in + yast2 firewall should be sufficient. Priority Requester: Desirable Requested by: Martin Vidner (mvidner) Description: Restrict services by interface, e.g. write a generic tcpwrappers library for other yast modules. References: Bug 49800 (https://bugzilla.novell.com/show_bug.cgi?id=49800) Discussion: #1: Lukas Ocilka (locilka) (2006-07-21 08:52:01) This probably depends on feature #100110: Possible Merge With Inetd Editor #2: Jiri Srain (jsrain) (2006-09-06 16:49:22) (reply to #1) Yes, doesn't make much sense if the module(s) will be rewritten... #3: Lukas Ocilka (locilka) (2006-10-23 17:22:49) Martin, please, add more suggestions how to restrict these services if you have some idea. Thanks. #4: Martin Vidner (mvidner) (2006-10-23 17:33:54) Technically: man xinetd.conf: bind Allows a service to be bound to a specific interface on the machine. This means you can have a telnet server listening on a local, secured interface, and not on the external interface. Or one port on one interface can do something, while the same port on a different interface can do something completely different. Syntax: bind = (ip address of interface). -- openSUSE Feature: https://features.opensuse.org/120053

1 0

[openFATE 304429] Package cache handling in yast
by fate_noreply＠suse.de 23 May '09

23 May '09

Feature changed by: Rémy Marquis (Spyhawk) Feature #304429, revision 14 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 21:45:10 reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Done Priority Requester: Important Requested by: Ladislav Slezak (lslezak) Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 Test Case: * check if the installed version of yast2-packager is 2.18.0 or later, with following command: $ rpm -q yast2-packager * add a new Software Repository: open YaST2 -> Software -> Software Repositories -> Add * during adding the new Software Repositories flag "Keep Downloaded Packages" * install or update a package: # zypper install <package name> * check if the package rpm file was saved in local cache (default: /var/cache/zypp/packages/) Discussion: #2: Ladislav Slezak (lslezak) (2009-01-08 13:47:14) Implemented in yast SVN trunk (will be in yast2-packager-2.18.0) There is a new check box, similar to 'Enabled' and 'Autorefresh' check boxes. (bnc#402617) #3: Eduardo Sotomayor (easgs) (2009-05-21 01:01:51) Will it work when installing a package with Yast not zypper command? + #4: Rémy Marquis (spyhawk) (2009-05-23 08:36:50) (reply to #3) + Yes. it is working. As specified above, there is a new checkbox in the + UI for enabling cache handling. -- openSUSE Feature: https://features.opensuse.org/304429

1 0

[openFATE 304429] Package cache handling in yast
by fate_noreply＠suse.de 20 May '09

20 May '09

Feature changed by: Eduardo Sotomayor (Easgs) Feature #304429, revision 13 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 21:45:10 reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Done Priority Requester: Important Requested by: Ladislav Slezak (lslezak) Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 Test Case: * check if the installed version of yast2-packager is 2.18.0 or later, with following command: $ rpm -q yast2-packager * add a new Software Repository: open YaST2 -> Software -> Software Repositories -> Add * during adding the new Software Repositories flag "Keep Downloaded Packages" * install or update a package: # zypper install <package name> * check if the package rpm file was saved in local cache (default: /var/cache/zypp/packages/) Discussion: #2: Ladislav Slezak (lslezak) (2009-01-08 13:47:14) Implemented in yast SVN trunk (will be in yast2-packager-2.18.0) There is a new check box, similar to 'Enabled' and 'Autorefresh' check boxes. (bnc#402617) + #3: Eduardo Sotomayor (easgs) (2009-05-21 01:01:51) + Will it work when installing a package with Yast not zypper command? -- openSUSE Feature: https://features.opensuse.org/304429

1 0

[openFATE 306327] Add DB2 Express-C
by fate_noreply＠suse.de 20 May '09

20 May '09

Feature changed by: Pascal Bleser (pbleser) Feature #306327, revision 7 Title: Add DB2 Express-C openSUSE-11.2: New Priority Requester: Desirable Requested by: Robert Schweikert (rjschwei) Description: IBM is interested to providing an easy mechanism for users to install DB2 Express C, the free version of DB2. It would be nice if we could add DB2 Express C to the openSUSE non-oss repository. Discussion: #3: Glenn Doig (doiggl) (2009-04-24 06:16:56) http://www-01.ibm.com/software/data/db2/express/ http://www-01.ibm.com/software/data/db2/express/download.html + #4: Pascal Bleser (pbleser) (2009-05-20 22:00:05) + Why not, let's go for it. If IBM wants to see openSUSE as a vehicle to + drive the adoption of their products, even if not opensource, and as + long as it doesn't affect the license/EULA/redistribution of the + distribution itself, I don't see any reason not to support that + initiative. + IBM can choose to either have it in the non-OSS repository, or host it + in a repository of their own, with openSUSE builds. + What is involved on our side of things ? -- openSUSE Feature: https://features.opensuse.org/306327

1 0

[openFATE 306444] change parted to use Hardware suggested sectors per track
by fate_noreply＠suse.de 19 May '09

19 May '09

Feature added by: Dean Giles (dgiles) Feature #306444, revision 1, last change by Title: change parted to use Hardware suggested sectors per track openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dean Giles (dgiles) Description: parted creates partitions which are automatically assigned 63 sectors per track. Hardware, such as HP raid devices, advertise that they want 32 sectors per track. It advertises that through ioctl HDIO_GETGEO. fdisk can utilize the hardware reported sectors per track. parted needs to be changed to do the same. See bug # 501152. Dean -- openSUSE Feature: https://features.opensuse.org/306444

1 1

[openFATE 305588] kdump support for autoyast installation
by fate_noreply＠suse.de 18 May '09

18 May '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305588, revision 11 Title: kdump support for autoyast installation openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Stefan Fent (sfent) Description: In SLES11 it is possible to add an autoyast section for kdump to the autoyast.xml file. This does not work in openSUSE11.1. Please add support for this in openSUSE as well. See bug #456707 for reference. + Discussion: + #2: Jozef Uhliarik (juhliarik) (2009-05-18 16:54:53) + added kdump support for autoyast installation to trunk. changes only + for control file in installation. the feature will be available with + package yast2-installation 2.18.15. IMHO it is done -- openSUSE Feature: https://features.opensuse.org/305588

1 0

[openFATE 306397] Use VFS cache directly for reads in NSS
by fate_noreply＠suse.de 15 May '09

15 May '09

Feature changed by: Rémy Marquis (Spyhawk) Feature #306397, revision 2 Title: Use VFS cache directly for reads in NSS Requested by: Paul Taysom (taysom) Description: Greg Pachner suggested that we try to satisfy NSS read requests straight from the Linux cache without going into NSS. This means not getting the NSS spinlock to satisfy a read operation. Since almost 40% of the NetBench requests are reads (but not time), this looked like a good bet. I implemented this approach (it has some hacks and is not of the level of quality to be checked in). Results: 8 Processor, 32 bit NetBench went from 720 to 836 for the peak, a gain of 15% 2 Processor, 32 bit NetBench went from 559 to 578 for the peak, a gain of 3% This is a change we want to consider for OES-3. Way too risky for Sp2. NSS does not currently check and update all the page status bits to make this fully work, have to study interactions with zAPIs, and changes the semantics of NSS for pages being modified. You can now read a page while it is being modified. Both the Traditional File System and all Unix file systems have this attribute but it is a change for NSS. + Discussion: + #1: Rémy Marquis (spyhawk) (2009-05-15 17:34:36) + Duplicate of Feature #306398 -- openSUSE Feature: https://features.opensuse.org/306397

1 0