February 2011 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 11 Feb '11

11 Feb '11

Feature changed by: Fahim Murshed (inverbrass) Feature #305394, revision 43 Title: Move KDE software updates notifications to upstream infrastructure openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:29:01 reject reason: out of resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Rejected by Sascha Peilicke (saschpe) reject reason: 11.3 is out for a while, wasn't done Priority Requester: Important openSUSE-11.4: Unconfirmed Priority Requester: Neutral Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Technical Contact: (Novell) Technical Contact: Stephan Binner (beineri) Partner organization: openSUSE.org Description: As kpackagekit matures, it may be the case that for 11.2 it is mature enough for replacing kupdateapplet. It already implements various aspects of kupdateapplet: * notifications (knotify) using a kded service (which takes care of refreshing too) * single update selection (kpackagekit gui) * uses a upstream client library for communication with PackageKit, which are better than our PackageKit communication code. Scope kpackagekit is meant here only to replace kupdateapplet. There is not relation with YaST here. Open Issues: * tray notification: may require implementing a plasma tray icon * SUSE specific code (smolt, registration, hardware search) * Requires some research how to introduce those extensions in kpackagekit, or move SUSE specific parts out, like another kded service. User experience Should stay the same Dependencies * PackageKit * libpackagekit-qt Contingency Plan In the case kpackagekit is not yet mature enough, the same resources invested now in kupdateapplet can be invested in improving kpackagekit. Otherwise, we can stay with kupdateapplet as a fallback. Relations: - kpackagekit author interview (url: http://polishlinux.org/kde/kpackagekit-interview/) - kpackagekit screenshot (url: http://www.packagekit.org/img/kpk-update.png) Test Case: * new patches should be notified by knotify * user should be able to see update availability * user should be able to see detailed update information, as well as selecting individual updates * user should get informed if the update repositories configuration has a problem * user should be informed of (available) drivers for plugged hardware Business case (Partner benefit): openSUSE.org: Right now software notifications are done using the kupdateapplet, which comes from the opensuse-updater code,(renamed in a non sucessful attept to upstream it). This applet come from a summer of code project, originally done as a zmd client, then evoluted to a zypper client, and now working as a PackageKit client. Sadly, during 10.3 cycle this applet got the feature to select updates individually and other small stuff which turned it into a very complicated piece of code, and started to became a package manager on its own. Later it became the favorite place to plug any kind of notifications, like registration needed, smolt participation, etc, and right now the code is much more complex that it should be (thus taking more maintenance and testing than it should require). This feature has the objective of cleaning up this situation to free resources in this area. With the progress of packagekit and recently, kpackagekit, this should be possible. kpackagekit already implements various of the needed aspects, and therefore it would mean getting rid of in house code for upstream code. Additionally, it would result in a much more consistant user experience as the tools would be similar across distributions. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:24:20) Looks like Duncan is in favor of this. Stano? If you guys are comfortable with the change, I am all for it. But remember, priority #1 is dist-upgrade. #5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 18:00:54) I will evaluate this feature later, we don't know the status of KPackageKit, we have the package and Thomas contributed patches, so only the decision to switch or not to switch is important. Feedback from the KDE team about upstream KDE 4.3 would also be useful. #8: Lubos Lunak (llunak) (2010-03-12 11:40:52) Is it written down somewhere what are the requirements for a KUpdateApplet replacement? What is listed here as 'Testcase' looks incomplete to me. I'd personally prefer if KDE stayed away from this strange PackageKit experiment (in my experience most KUpdateApplet problems are in fact PackageKit problems), and in fact there are some plans upstream to have a KDE wrapper API for packaging (basically like PackageKit, but without the overdesigning and sucking). That would also solve the problem of switching to upstream infrastructure, and that's why I'd like to know the openSUSE requirements. The expected timeframe is KDE SC 4.4 or 4.5, i.e. too late for 11.3. #9: Martin Seidler (pistazienfresser) (2010-06-22 22:31:15) Is the proposal not just like the status with Gnome (in 11.2)? If so I would not recomend that (way of) change: I use the PackageKit Software in Gnome now only for notiforcation and not for making updates as I (and seems so - also many other users in the forums) had often problems that seems to be related to that applet (or simply the use of different applets for updating software). #10: Federico Lucifredi (flucifredi) (2010-06-22 22:50:50) (reply to #9) Bugs on the Gnome PK applet should be fixed -- lets make sure they are reported. -- The proposal here, as I understand it, was to bring about coherence with upstream in the KDE space. That is a valid objective, and quality is something that would be addressed as part of any change. No one is rushing. #11: Martin Seidler (pistazienfresser) (2010-06-28 23:29:07) (reply to #10) Sorry if my first comment seems to be so contra. I have only voted neutral and am not sure. If this proposted way would really work it seems to me desirable (if I could understand it at all ;-) ). If it would lead to a stable and easy way to update (without the possibility to add completely new programms) it may be also make sence to give a normal user access to that update tool (again?). But the developers may also look at possible complications or unreported bugs (just seach for "update" and "applet" or something like this in the forums - maybe that indicates more to replacing kupdateapplet than against?): for example (some of the first results of "update" and "applet" - some of 300): http://forums.opensuse.org/get-help-here/applications/441112-updater-applet… http://forums.opensuse.org/get-help-here/applications/440994-kupdater-apple… http://forums.opensuse.org/get-help-here/applications/440391-problem-updati… http://forums.opensuse.org/get-help-here/applications/440082-opensuse-updat… ... #12: Petar Petrov (siminin) (2010-07-02 09:23:55) (reply to #11) I also have problems with kpackagekit. That's why i uninstall packagekit and install kupdateapplet-zypp and the notification works like a charm. That's why i dislike this proposal and vote it down. #13: Sascha Peilicke (saschpe) (2010-12-17 09:20:10) Seems like this is done for 11.4 + #14: Fahim Murshed (inverbrass) (2011-02-11 19:28:25) + Nice -- openSUSE Feature: https://features.opensuse.org/305394

1 0

[openFATE 305285] dictionary and DoS attack protection based using log scanning and dynamic firewall ban
by fate_noreply＠suse.de 10 Feb '11

10 Feb '11

Feature changed by: Hans de Raad (hcderaad) Feature #305285, revision 25 Title: dictionary and DoS attack protection based using log scanning and dynamic firewall ban openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 11:12:41 reject reason: no volunteer - 14 votes are about the limit not to reject it for all, so I open 11.3 Priority Requester: Important Projectmanager: Desirable openSUSE-11.3: Evaluation by project manager Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org 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? #5: P Linnell (mrdocs) (2010-01-09 19:20:12) Denyhosts is a python module running as a daemon available in network: utilities with similar functionality.I've used it with good success on several SLES servers and desktops. + #6: Hans de Raad (hcderaad) (2011-02-10 23:20:07) + The package fail2ban seems to be included in the distro nowadays + (11.3), and some rudimentary configuration can be done thru yasts' + sysconfig-editor. It would be nice though to have more configurability + added to the security & users -> firewall Yast module for this very + handy package, or some similar package. -- openSUSE Feature: https://features.opensuse.org/305285

1 0

[New: openFATE 311080] Simplify KDM login configuration
by fate_noreply＠suse.de 10 Feb '11

10 Feb '11

Feature added by: Alvise Z (alvise_cav) Feature #311080, revision 1 Title: Simplify KDM login configuration openSUSE.org: Unconfirmed Priority Requester: Desirable Requested by: Alvise Z (alvise_cav) Partner organization: openSUSE.org Description: KDE comes with a tool for configuring the KDM login window. However the settings here are not taken into account. From what I have understood, openSuse has different configuration files for the login screen that are accessible through Yast > /etc/SysConfigEditor. In order to avoid confusion, openSuse should: - either remove the KDM configuration tool from KDE's system settings and add a full configuration tool into Yast - or use only KDE's tool (or synchronise both yast and KDE tools) -- openSUSE Feature: https://features.opensuse.org/311080

1 1

[New: openFATE 311067] UPEK support in Yast Fingerprint
by fate_noreply＠suse.de 10 Feb '11

10 Feb '11

Feature added by: Quentin Denis (queden) Feature #311067, revision 1 Title: UPEK support in Yast Fingerprint openSUSE.org: Unconfirmed Priority Requester: Important Requested by: Quentin Denis (queden) Partner organization: openSUSE.org Description: Hello, some Lenovo laptops use the UPEK driver for fingerprint. Using the latest version of fingerprint-gui (which also ships the UPEK drivers) gives me a perfect functionality of my device. However, Yast does still not recognize my device. Could it be easily implemented? -- openSUSE Feature: https://features.opensuse.org/311067

1 3

[New: openFATE 311131] build ppc oem images with KIWI
by fate_noreply＠suse.de 10 Feb '11

10 Feb '11

Feature added by: Dinar Valeev (k0da) Feature #311131, revision 1 Title: build ppc oem images with KIWI Hackweek VI: Unconfirmed Priority Requester: Important Requested by: Dinar Valeev (k0da) Partner organization: openSUSE.org Description: PowerVM provides great and flexible virtualization technologies. With KIWI possibility to build ppc OEM images, it is possible to reduce deployment time on Power and provide ready to use, preconfigured ppc appliances Test Case: 1)Build appliance 2)deploy it here is several options available dd it directly to disk burn CD/DVD use vopt (virtual optical device) 3)Start LPAR Use Case: In addition to common appliance advantages, this feature bring possibility to offer appliances for ppc Business case (Partner benefit): openSUSE.org: More different platform for appliances -- openSUSE Feature: https://features.opensuse.org/311131

1 5

[New: openFATE 311094] Mozmill for Firefox on Suse Linux
by fate_noreply＠suse.de 09 Feb '11

09 Feb '11

Feature added by: Xi Jiang (xjiang) Feature #311094, revision 1 Title: Mozmill for Firefox on Suse Linux Hackweek VI: Unconfirmed Priority Requester: Important Requested by: Xi Jiang (xjiang) Partner organization: openSUSE.org Description: Mozmill is a open-source Automation test tools for firefox which developed by Mozilla, We want to introduce it into Suse linux test workflow on firefox. Not all of the test cases in Mozmill are suit for firefox version on Suse linux, So a certain of changes will be optimized and improved. -- openSUSE Feature: https://features.opensuse.org/311094

1 2

[openFATE 308150] how to enter expert/advanced partitioning during install unnecessarily obscure
by fate_noreply＠suse.de 07 Feb '11

07 Feb '11

Feature added by: Felix Miata (mrmazda) Feature #308150, revision 1 Title: how to enter expert/advanced partitioning during install unnecessarily obscure Buildservice: Unconfirmed Priority Requester: Important openFATE: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Felix Miata (mrmazda) Description: https://bugzilla.novell.com/show_bug.cgi?id=547703 has this bug's details. The current design is an nth iteration of a design that has been broken several years and needs to be fixed. Of all the major distros I've been installing over many years, openSUSE's has been the least intuitive advanced partitioner to get started. To convince people openSUSE is better than Ubuntu requires it actually be better. This is problematic for multibooters who get their existing partitiong corrupted because they didn't realize they weren't where they needed to be to get the partitioning job done properly. -- openSUSE Feature: https://features.opensuse.org/308150

1 2

[New: openFATE 311110] openSUSE Paste <-> openSUSE Connect connection
by fate_noreply＠suse.de 06 Feb '11

06 Feb '11

Feature added by: Michal Hrusecky (-miska-) Feature #311110, revision 1 Title: openSUSE Paste <-> openSUSE Connect connection Hackweek VI: Unconfirmed Priority Requester: Desirable Requested by: Michal Hrusecky (-miska-) Partner organization: openSUSE.org Description: Currently openSUSE Paste works totally independently to the rest of openSUSE infrastructure. It would be nice if it could authenticate itself against openSUSE Connect. That way registered users could have list of their pastes, delete them or create new ones (skip spam filtering and use users login). -- openSUSE Feature: https://features.opensuse.org/311110

1 2

[openFATE 311196] Include brcm80211 driver/firmware into openSUSE 11.4
by fate_noreply＠suse.de 05 Feb '11

05 Feb '11

Feature changed by: Szymon Kowalczyk (fazerxlo) Feature #311196, revision 2 - Title: Include brcm80211 driver into openSUSE 11.4 + Title: Include brcm80211 driver/firmware into openSUSE 11.4 openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Szymon Kowalczyk (fazerxlo) Partner organization: openSUSE.org Description: Broadcom has released opensource drivers for some of new Wireless cards That could be nice to get those cards working out of box in opensuse 11.4 for snupported bcm/b43 devices I read that this will be included into 2.6.37 but I cannot find it in milestone 6 For more info: http://forums.opensuse.org/english/get-technical-help-here/hardware/447485-… http://wireless.kernel.org/en/users/Drivers/brcm80211 -- openSUSE Feature: https://features.opensuse.org/311196

1 0

[New: openFATE 311078] Open Source Designers Workstation
by fate_noreply＠suse.de 05 Feb '11

05 Feb '11

Feature added by: Andy Fitzsimon (afitzsimon) Feature #311078, revision 1 Title: Open Source Designers Workstation Hackweek VI: Unconfirmed Priority Requester: Important Requested by: Andy Fitzsimon (afitzsimon) Partner organization: openSUSE.org Description: The aim of this project is to make an appliance with suse studio that caters to the majority needs of visual creative designers. it will look fantastic, contain only what is needed for most design tasks and be ready to use instantly for a wide variety of design tasks the project requires the following - building some packages (marked with * instead of â¢) - setting up overlay files - small documentation and walkthroughs - testing - a website + artwork Appliance Summary: Software â¢ Docky + theme â¢ Gnome-Do * gnome-globalmenu * Nautilus Elementary bzr branch lp:nautilus-elementary/2.28.4 * Gloobus: bzr branch lp:gloobus â¢ Inkscape â¢ Scribus â¢ pdfmod * Gimp (single window mode + custom config) http://lh5.ggpht.com/_V59uKesC_4c/TQDAnGesU4I/AAAAAAAABAs/2s6Z1NcXCsI/s800/… * darktable â¢ fontforge â¢ simplescan â¢ mypaint â¢ hugin â¢ blender â¢ vlc â¢ sparkleshare â¢ gedit plugins : filesearch, embedded terminal, colorpanes http://lh3.ggpht.com/_V59uKesC_4c/TITvZuhYZTI/AAAAAAAAA74/RnvCgcJs9JA/gedit… â¢ chromium, firefox â¢ transmission â¢ compiz + config â¢ openshot â¢ gtkrecordmydesktop â¢ Libre Office * gnome-font-manager http://code.google.com/p/font-manager/ * App style http://code.google.com/p/appstyle/ â¢ CUPS â¢ gwibber â¢ pidgin (with facebook plugin) OPTIONAL â¢ sparkleshare â¢ git, bzr, mecurial, svn â¢ boab NON FOSS SOFTWARE: skype, opera, adobe reader (evince should still have pdf viewer association through nautilus) Resources: â¢ palettes â¢ brushes â¢ templates â¢ Fonts + google fonts + more â¢ svg clipart Configs â¢ Plugins â¢ Theme â¢ Shortcuts â¢ Good defaults Documentation â¢ introduction â¢ screencast walkthrough â¢ tutorials Use Case: Desktop Publishing: Bill needs to make a billboard for an upcoming conference. He has a high quality DSLR camera to capture images. His photos will require quick sight-editing at time of download and possibly more advanced editing later. Bill will have to make and edit various illustrations in a vector format with colors based on a commonly used palette. Bill wants to use new typography from an easy to mange font library. He may also need to manually edit his chosen fonts for the job. Bill will then need to create an advanced PDF with custom print and cutting instructions for the billboard. He will manually specify spot colors for his printer to add to the final print run. Bill needs to share his experiences, chat to his stakeholders and friends via, aol,msn,yahoo etc bill would like to record a screencast of the whole process which he will edit and put online. Bill wants to do all of this for free Bill is a top bloke Business case (Partner benefit): openSUSE.org: Many designers are unaware that many open source tools can best meet their workflow needs as an integrated solution. Setting up a workstation and then configuring things is already hard enough for the initiated and impossibly time consuming for the curious. We need a designer friendly open source workstation with sane defaults and a useful setup -- openSUSE Feature: https://features.opensuse.org/311078

1 10