September 2012 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308248] OBS Admin Setup Tool
by fate_noreply＠suse.de 10 Oct '12

10 Oct '12

Feature added by: Adrian Schröter (adrianSuSE) Feature #308248, revision 1 Title: OBS Admin Setup Tool Buildservice: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Adrian Schröter (adriansuse) Description: The OBS admins need a tool for initial setup and later configurations of operations, which can't be done via the API. This setup tool may be implemented as CLI or as (WEB) YaST module. The setup needs to setup the frontend and web part, and the backend part. The parts may run on different systems. Tasks which should be offered are: webclient/software: * Used api server * run services api (aka frontend) server: Basically the steps as documented in README.SETUP and README.UPDATE of the packages, this includes: * Database setup and initialisation * rails migration (also on update) * configure backend interfaces (may be announced via SLP) * Admin password settings * run services backend setup: * sign daemon setup (gpg key generation) * run services ( and show their state ) -- openSUSE Feature: https://features.opensuse.org/308248

1 3

[New: openFATE 312797] Allow to receive build checks separately
by fate_noreply＠suse.de 09 Oct '12

09 Oct '12

Feature added by: Lars Vogdt (lrupp) Feature #312797, revision 1 Title: Allow to receive build checks separately Buildservice: New Priority Requester: Important Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: During the review of packages, it is always a good idea to have a look at the different build checks that are running after a successful build. Currently, this means to download the whole buildlog, which is (in case of gcc) really huge and produces a lot of unneeded network traffic. osc already has the "-o offset" feature, which allow to limit the transfer but is not exact enough to get the correct lines during the first try. The WebUI lacks such a feature completely. I like to have a way to: * get just the rpmlint messages * get also other check output like the post-build-check results IMHO the api should offer some special request like "get _checklog" which might be divided via additional options to get just the result of special checks. "get _checklog/rpmlint" ; "get _checklog/02-check-gcc-output"; ... Business case (Partner benefit): openSUSE.org: Package review is a very time consuming task. Allowing the reviewer to get just the output he needs save time and allows either to review faster or to other things with the results. -- openSUSE Feature: https://features.opensuse.org/312797

1 1

[openFATE 307378] YaST2 Partitioner should detect external partition type changes and update fstab
by fate_noreply＠suse.de 09 Oct '12

09 Oct '12

Feature added by: Alexander shaduri (alex_sh) Feature #307378, revision 1 Title: YaST2 Partitioner should detect external partition type changes and update fstab openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Alexander shaduri (alex_sh) Description: If partition was changed from fat32 to ntfs externally, there's no way to specify that in YaST Partitioner. Initial partition layout: sda1: fat32 (empty), sda2: ext3 linux /, etc... The first thing I did was install openSUSE 11.1. YaST correctly identified fat32 partition and wrote the respective line to fstab. Then, I installed Vista on sda1. The problem with Vista is that it won't install to fat32, it needs ntfs. So, it converted sda1 to ntfs and installed ok. Now, the problem is that fstab in openSUSE still contained "vfat" as filesystem type. KDE4 wouldn't open in from Konqueror, etc... I tried to make YaST re-learn the type of sda1, so it would write the correct line to fstab, since I didn't remember what are the openSUSE-default options for ntfs-3g. Unfortunately, there doesn't seem to be a way to do this. I think this will affect lots of people who, for example, had XP and decided to switch to Vista. Also, since openSUSE doesn't allow formatting to ntfs, this will also affect all the people who install Linux on a clean disk (reserving a space for Windows with fat32 partition), and then install XP or Vista, converting the filesystem to ntfs in the process. Steps to Reproduce: 1. Install openSUSE on a clean disk, making the first partition fat32. 2. Convert the first partition to ntfs via third-party tool. 3. Try to use the drive from openSUSE as an average "joe the user". I filed it as a bug https://bugzilla.novell.com/show_bug.cgi?id=524784 and was told that this was a feature request - "The partitioner does assume that the enties in fstab are correct and does not try to fix them. Changing this behaviour requires a feature request." So, here it is. -- openSUSE Feature: https://features.opensuse.org/307378

1 8

[New: openFATE 309234] Make expert partitioner more intuitive
by fate_noreply＠suse.de 09 Oct '12

09 Oct '12

Feature added by: Marco Poletti (poletti_marco) Feature #309234, revision 1 Title: Make expert partitioner more intuitive openFATE: Unconfirmed Priority Requester: Important Requested by: Marco Poletti (poletti_marco) Description: I propose to restructure the expert partitioner, my suggestions are these: 1) I think the "Overview" and "Used devices" tabs associated with each drive are out of place, I think they should become the property window of the drive, that can be accessed by right-clicking the drive and selecting the new item "Properties" or by selecting it and clicking the new button "Properties" in the "Hard disk" view, or by right-clicking an empty space in the drive's own view and selecting Properties, or by clicking the new button "Drive properties" in the drive's own view. 2) About partitions, I'd completely remove them from the tree and move those informations to the partition's Properties window, accessible from right-clicking the partition and selecting the new item "Properties" or selecting the partition and clicking the new "Properties" button, both in the drive view and in the "Hard disks" view. 3) In computers with not too many HDs, say max 6, I'd show all the graphical bars in the "Hard disk" view. Test Case: Use Case: -- openSUSE Feature: https://features.opensuse.org/309234

1 5

[New: openFATE 308940] zypper: provide ways to show reason for install
by fate_noreply＠suse.de 07 Oct '12

07 Oct '12

Feature added by: Jan Engelhardt (jengelh) Feature #308940, revision 1 Title: zypper: provide ways to show reason for install openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Jan Engelhardt (jengelh) Partner organization: openSUSE.org Description: The smart package manager had a --explain option with which one could have the pm dump reasons for a package being installed. The same would be desirable to have for zypper, as there are sometimes strange updates. Use Case: # zypper up The following NEW packages are going to be installed: bundle-lang-gnome-ar glib2-lang gnome-keyring-lang gnome-vfs2-lang gtk2-lang With an --explain switch, there could be: glib2-lang (required by updated glib2-2.22.4-0.1.1) Business case (Partner benefit): openSUSE.org: https://bugzilla.novell.com/show_bug.cgi?id=576623 -- openSUSE Feature: https://features.opensuse.org/308940

1 1

[New: openFATE 314483] Automatically set secondary partitions as 'nofail' in /etc/fstab
by fate_noreply＠suse.de 29 Sep '12

29 Sep '12

Feature added by: Mircea Kitsune (MirceaKitsune) Feature #314483, revision 1 Title: Automatically set secondary partitions as 'nofail' in /etc/fstab openSUSE Distribution: Unconfirmed Priority Requester: Mandatory Requested by: Mircea Kitsune (mirceakitsune) Partner organization: openSUSE.org Description: I had a discussion yesterday about how partitions in fstab disappearing (such as unplugging an internal drive) will cause openSUSE to no longer boot and go to the emergency console, unless the 'nofail' parameter is set. For those who wish to see the full thread: http://forums.opensuse.org/english/get-technical-help-here/install-boot-log… Being a newbie myself, I found this difficult to solve and understand until someone explained me how fstab works. Until then I thought the system had been compromised beyond repair. Some users might remove drives or change partitions without knowing how fstab works. They would then find themselves stuck in an "emergency console" without any information as to why they are there, conclude the only solution is to reinstall the system, and go through a frustrating experience thinking Linux is too unsafe and unstable. My suggestion is defaulting the 'nofail' parameter for all drives except root and swap (possibly the /home partition if it can be detected) when openSUSE / Partitioner automatically add a drive to fstab. There's no point in failing the boot if a partition that's not needed to boot is missing. I have three NTFS partitions mounted in /windows/[letter]/ and immediately added this flag to them after being informed of it, to avoid potential issues in case one of them breaks or I temporarily disconnect it. Separately, I'm also proposing a message in the emergency console about what brought the user there. If possible, mentioning that in /etc/fstab there's a partition that's no longer accessible. The only information currently shown is "Welcome to the emergency console, please give your root password". If the user forgets what changes they made, they might never know what's broken and what to try fixing... at least if they're not experts and have a console command ready. Test Case: Make sure you have a partition on a secondary drive configured to auto-mount in /etc/fstab (for NTFS that should be /windows/[letter]/). Shut down your computer and unplug that drive. When booting into openSUSE, you will be taken to the recovery console before reaching the logon screen, without any information as to why. If you add the 'nofail' parameter to the missing partition in /etc/fstab, it will boot as normal and just ignore the missing drive. Business case (Partner benefit): openSUSE.org: Newbies might not know all the settings in fstab or edit them manually for drives auto-mounted by openSUSE. If a secondary drive breaks or is disconnected, they can be left with an irrecoverable system without even knowing why. Even an expert will need to boot using a Live-CD distro to edit /etc/fstab manually to get the system booting again without that drive. Automatically setting alternative drives as 'nofail' would prevent such risks, and also make most sense in my opinion. -- openSUSE Feature: https://features.opensuse.org/314483

1 2

[openFATE 305285] dictionary and DoS attack protection based using log scanning and dynamic firewall ban
by fate_noreply＠suse.de 27 Sep '12

27 Sep '12

Feature changed by: Marcus Meissner (msmeissn) Feature #305285, revision 27 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 + openSUSE-11.3: Rejected by Marcus Meissner (msmeissn) + reject reason: wasnt done for 11.3 Priority Requester: Important + openSUSE Distribution: Unconfirmed + Priority + Requester: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: Federico Lucifredi (flucifredi) 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 310044] Validating DNSSEC support
by fate_noreply＠suse.de 27 Sep '12

27 Sep '12

Feature added by: Tobias Burnus (burnus) Feature #310044, revision 1 Title: Validating DNSSEC support openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Tobias Burnus (burnus) Description: DNSSEC (http://en.wikipedia.org/wiki/DNSSEC) (Domain Name System Security) is mechanism which provides integrity and authenticity of DNS data. It became more important after new Kaminsky DNS poisoning attacks were found in early 2008. The domain-name organizations start to support them for regular usage. Especially: ROOT (.) (http://www.root-dnssec.org/) will be signed starting from July 15, 2010. ARPA is offers signing since 17 March 2010. And several country TLD already use or have test-bed DNSSEC implementations (e.g. .cz, .se, .ch, .de, .pm, .us, (soon:) .eu, .fr, etc.). It should be thus possible to enable a validating DNSSEC lookup (cf. also Fedora's DNSSEC implementation (http://fedoraproject.org/wiki/Features/DNSSEC) , which pre-dates the DNS-ROOT signing and thus is a bit arkward). As DNSSEC is not widely implemented and since issues like key rollover or lost interest occur, the checking should be easily dis-/enable - and probably not be enabled by default, yet. Another reason for not enabling it by default is that some internet home gateways have caching PROXI DNS servers which cannot handle UDP DNS for packages larger than 512 Bytes (cf. change from RFC 1035 to RFC 2671). -- openSUSE Feature: https://features.opensuse.org/310044

1 5

[New: openFATE 314462] Sync Contacts in Kontact to Google
by fate_noreply＠suse.de 26 Sep '12

26 Sep '12

Feature added by: Michael Doris (dorism) Feature #314462, revision 1 Title: Sync Contacts in Kontact to Google openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Michael Doris (dorism) Partner organization: openSUSE.org Description: I'd like to be able to sync my google contacts easily with Kontakt. -- openSUSE Feature: https://features.opensuse.org/314462

1 2

[New: openFATE 314466] memory hotplug of guest osï¼KVMï¼
by fate_noreply＠suse.de 25 Sep '12

25 Sep '12

Feature added by: yi li (liyicybertan123) Feature #314466, revision 1 Title: memory hotplug of guest osï¼KVMï¼ openSUSE.org: Unconfirmed Priority Requester: Important Requested by: yi li (liyicybertan123) Partner organization: openSUSE.org Description: memory hotplug of guest os, the hypervisor using the kvm -- openSUSE Feature: https://features.opensuse.org/314466

1 1