October 2009 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308251] LVM snapshot in clustered environment
by fate_noreply＠suse.de 28 Oct '09

28 Oct '09

Feature added by: Jan Kalcic (jkalcic) Feature #308251, revision 1 Title: LVM snapshot in clustered environment openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Jan Kalcic (jkalcic) Description: LVM snapshot in a XEN environment allows to "HOT" backup a Virtual Machine without shut it down. This would be a very interesting features which we all cluster administrators miss in the current HA/cLVM environment. -- openSUSE Feature: https://features.opensuse.org/308251

1 0

[openFATE 305500] User has no way to switch compiz on / off
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Juergen Weigert (jnweiger) Feature #305500, revision 17 Title: User has no way to switch compiz on / off openSUSE-11.2: Rejected by (cthiel1) reject date: 2009-10-27 15:59:58 reject reason: yast isn't used to configure X anymore. Priority Requester: Desirable Projectmanager: Desirable Requested by: Juergen Weigert (jnweiger) Description: I searched Yast, SAX, gnome-display-properties, and did a desktop search for 'compiz'. The switch is not well advertised, it is here: computer -> System: control-Center -> Look and Feel: Desktop Effects -> [ ] enable desktop effects. -> Close Command line: simple-ccsm, but not ccsm. I suggest to enhance yast to allow compiz switching, using the above information. And/or include package fusion-icon. Discussion: #4: Cameron Blackwood (drkorg) (2009-10-05 04:37:35) +1. It would be great to be able to turn off all eye candy (for remote/vnc hosts) or to crank it up to full (for desktops and laptops). A simple 'no candy' or 'full candy' yast setting would be great! + #5: Juergen Weigert (jnweiger) (2009-10-27 19:28:26) + I haven't seen any compiz artefacts in 11.2, configure desktop -> + desktop effects: shows everything disabled. + Looks like it is now disabled per default. That counts as resolved + fixed for me. Thanks. (The request was never meant to be yast specific. + Any 'fix' counts :-) ) -- openSUSE Feature: https://features.opensuse.org/305500

1 0

[openFATE 305301] Central Regulatory Domain Agent (for 802.11)
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305301, revision 36 Title: Central Regulatory Domain Agent (for 802.11) - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by (cthiel1) + reject date: 2009-10-27 16:08:49 + reject reason: not done for 11.2. Priority Requester: Important Projectmanager: Important Requested by: Vladimir Botka (vbotka) Description: The regulatroy domain handling for wireless cards was done by each driver seperately before mac80211/cfg80211. cfg80211 is used to unify the handling of regulatory domains for wireless devices. However cfg80211 depends on the user space configuring the regulatory domain. A user space daemon is currently developed (see [1]). It basically provides the allowed channels for all known regulatory domains. Additionally it would be nice to allow the configuration of the regulatory domain from the Yast network module. [1] http://wireless.kernel.org/en/developers/Regulatory/CRDA Partly based on bnc#392853 Relations: - wpa_supplicant in factory seems to ignore an country=DE setting in its config (novell/bugzilla/id: 537708) https://bugzilla.novell.com/show_bug.cgi?id=537708 Discussion: #1: Helmut Schaa (hschaa) (2009-02-03 12:04:57) I've already packaged crda and wireless-regdb in my buildservice project home:hschaa:CRDA. #2: Helmut Schaa (hschaa) (2009-02-09 11:37:20) What we additionally need for this feature is some integration with Yast or NetworkManager such that the user is able to set the regulatory domain (maybe based on the selected time zone). A command line tool for setting the domain is already available (iw) but needs to be updated. #3: Helmut Schaa (hschaa) (2009-02-09 16:09:28) (reply to #2) Just submitted an update for Factory. #4: Helmut Schaa (hschaa) (2009-02-10 10:59:40) (reply to #2) wpa_supplicant 0.6.7 already has support for setting the regulatory domain. We'll get that with the next version update. #5: Helmut Schaa (hschaa) (2009-02-10 13:40:25) (reply to #2) iw, crda and wireless-regdb are part of factory now #6: Kshitij Kulshreshtha (polyconvex) (2009-03-25 11:53:33) Sometimes on a short visit abroad a user might not bother to update their timezone information on their laptop but still want to use a wireless network. In this case setting the regulatory domain based on timezone is not the right thing to do. Why not let the networkmanager applet ask the user himself to provide the country as a part of the dialog to setup the network? (A map similar to the yast timezone selector built into KNetworkManager?) #7: Marius Tomaschewski (mtomaschewski) (2009-06-08 11:27:49) We've already another enhancement bugs for sysconfig/wireless... so let's just add it for 11.2. Helmut, let's speak in the next days about the requirements on the sysconfig side (I guess it is just one optional variable) and add this together with the another enhancements. Michal (yast2 network) requires the sysconfig support to implement it on the yast2 side. #11: Marius Tomaschewski (mtomaschewski) (2009-09-08 15:56:43) (reply to #9) Let's define the sysconfig ifcfg -file variable as: WIRELESS_REGULATORY_DOMAIN='00' The '00' value is the ISO / IEC 3166 alpha2 country code as used in the regdb / wpa_supplicant / iw tool. The _sysconfig_ default is '' , that is empty string. #12: Marius Tomaschewski (mtomaschewski) (2009-09-08 16:39:46) (reply to #11) Hmm... it looks like the reg domain is a global and not a per-interface setting, in iw: reg set <ISO/IEC 3166-1 alpha2> reg get this means it has to go to network/config and not into ifcfg file. Is this correct? #15: Jiri Benc (jbenc) (2009-09-09 13:23:09) (reply to #12) Yes, this is a system-wide setting. On purpose, you don't usually have you computer in two different regulatory zones ;-) I don't see what's the problem with using the timezone setting, though. Yes, it would require a translation table (to map e.g. Europe/Prague to CZ), but other than that, it should provide all the information we need: in what country we are located. #16: Marius Tomaschewski (mtomaschewski) (2009-09-09 13:53:06) (reply to #15) OK, thanks for verifying this! I don't have any problem when yast2 is setting the WIRELESS_REGULATORY_DOMAIN='CZ' value based on the TIMEZONE='Europe/Prague' setting by default / as preselection. But I need the correct, valid and final value for the utilities and don't want to provide any translation table and waste e.g. boot time in sysconfig. It also makes sense to check that the alpha-2 code is in the wireless-regdb and perhaps propose an another value if possible or reject & reset it -- in sysconfig it is too late to do this or ask the user what to do. The package implementing this is in Base:System/sysconfig project and goes to factory today. When iw reg set is used, the value is applied correctly to the crda/kernel. When it is set via wpa_supplicant config, there is no attempt to set it visible in udev -- seems to be a wpa_supplicant bug -> bugzilla. #17: Jiri Benc (jbenc) (2009-09-09 14:01:13) (reply to #16) Yes, all of that makes sense to me. #18: Vladimir Botka (vbotka) (2009-09-09 20:34:24) (reply to #16) Part of the project http://linuxwireless.org/en/developers/Documentation/nl80211 is also an wpa_supplicant with -Dnl80211 which will solves this problem. The yast module can set both the WIRELESS_REGULATORY_DOMAIN in sysconfig and country= in wpa_supplicant.conf. #20: Marius Tomaschewski (mtomaschewski) (2009-09-09 22:40:21) (reply to #18) Stop :-) sysconfg / ifup is not using /etc/.../wpa_supplicant.conf -- it generates one per interface from network/config and network/ifcfg* settings. So just set the WIRELESS_REGULATORY_DOMAIN, ifup-wireless will add the (expanded) "country=$WIRELESS_REGULATORY_DOMAIN" statement to the generated wpa_supplicant config. #19: Vladimir Botka (vbotka) (2009-09-09 21:34:26) (reply to #16) The new nl80211 extension is already available in Factory. # wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -i wlan0 -dd - Dnl80211 Initializing interface 'wlan0' conf '/etc/wpa_supplicant/wpa_supplicant.conf' driver 'nl80211' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant/wpa_supplicant.conf' -> '/etc/wpa_supplicant/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant/wpa_supplicant.conf' country='CZ' #21: Marius Tomaschewski (mtomaschewski) (2009-09-09 22:42:34) (reply to #19) Yes I know already about the new driver. Question is if we can switch to use this driver already. Let's continue with the driver details in bugzilla. #22: Marius Tomaschewski (mtomaschewski) (2009-10-02 08:52:57) FYI: The sysconfig-0.72.4 version in openSUSE:Factory / 11.2 implements this feature. It provides the WIRELESS_REGULATORY_DOMAIN variable and adds it to the per-interface wpa_supplicant.conf as well as sets it via iw command in case of old (iwconfig) setup. It does not change to the new nl80211 driver (or another one supporting it) by default, the user has to set WIRELESS_WPA_DRIVER="nl80211" per interface or wpa_supplicant will ignore it. -- openSUSE Feature: https://features.opensuse.org/305301

1 0

[openFATE 303859] simple network configuration in 1st stage
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303859, revision 34 Title: simple network configuration in 1st stage openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-09 10:04:08 reject reason: Postponing, out of resources. Priority Requester: Important Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: Jiří Suchomel (jsuchome) Description: The feature of "Automatic Configuration" has a nice effect of not asking users for accepting all the default settings. However, there's (at least) one setting that is default but still not widely accepted (I think so - at least I change it always): it's the firewall that is automatically running. Wouldn't it be good to have some simple client, only opened from installation proposal upon user's request (so not by default) where could be this option configured? Even better would be "Network" part in Installation summary, with the only setting "Firewall on", which would be a link which value changes on click. References: https://bugzilla.novell.com/show_bug.cgi?id=379149 https://bugzilla.novell.com/show_bug.cgi?id=303859 Discussion: #1: Matthias Eckermann (mge1512) (2008-06-09 23:49:49) An automatically running firewall is great - for the average user. And this even applies in enterprise. I strongly recomment to reject this feature for ALL products: SLES, SLED and openSUSE, but leave it to Federico. Guy, Federico, Michl, Marcus? #2: Jiří Suchomel (jsuchome) (2008-06-10 07:49:31) (reply to #1) Well, I'm not asking for not starting firewall by default. I agree it is good to have it automatically on. But we miss an option to change this during the installation workflow. #3: Michal Svec (msvec) (2008-06-10 11:24:41) (reply to #2) Right, the proposal was to have a simple way, ideally a hyperlink, to disable the firewall, either completely or just for some services (ssh) somewhere accessible during the installation workflow. We should certainly keep the current default of running firewall automatically. #4: Lukas Ocilka (locilka) (2008-06-10 14:51:08) (reply to #3) It's quite easy to add another firewall_proposal client to the fist stage but that one could only provide enable/disable functionality (the default value is set in control file already). On the other hand, opening a firewall for some services couldn't be done as these services are known after packages with service- definitions are installed (firewall services defined by packages). Using other words: In the installed system. This feature is more about specific configuration dialogs providing functionality to Open Firewall for XYZ Service - I think only configuration of users is affected now (samba-client, SLP broadcast reply, ...?). #5: Jiří Suchomel (jsuchome) (2008-06-10 15:03:08) (reply to #4) No, it isn't. This feature is about possibility to either shut down the firewall or open ports for defined (not arbitrary) services (e.g. ssh). No samba, no SLP. It is called simple network configuration in 1st stage. #6: Lukas Ocilka (locilka) (2008-06-10 16:42:14) (reply to #5) Yes I know what is it called, but as I've already written, in first stage, firewall can be only enabled or disabled. No additional servics could be open as they are unknown in that stage. I'm just talking about the limits of the proposed firewall/network client in first stage. The rest is left on particular modules to open ports/services as required by a specific service used in second stage. Services are defined in packages, their ports, names, description. Even SSH has its own definition in openssh package: /etc/sysconfig/SuSEfirewall2.d/services/sshd . This package needen't be installed at all. #7: Jiří Suchomel (jsuchome) (2008-06-11 08:07:35) (reply to #6) And again, I am not requesting any configuration of services in this stage. Basically I want the same thing we have in current network proposal (at the beginning of currently-usually-unused 2nd stage) , where you can shut firewall down and/or open ssh port. If sshd is the problem (but in the time of installation proposal, we know if it is going to be installed or not, so it may be hidden if sshd is not selected for installation) it doesn't have to be there, and it may consist of simple firewall off/on hyperlink. So yes, it is true that firewall_proposal client ...could only provide enable/disable functionality , but this is actually the point of this feature. I should probably also make clear that I'm not requesting any additonal step in the sequence, only the option to be selected from installation summary, just like Installation from Images is enabled (disable) one. #8: Guy Lunardi (glunardi) (2008-06-12 17:34:47) (reply to #7) Could this be served by providing an hyperlink which would open the current network module presented during the normal installation? Like I had made my initial priority, I am pretty neutral on this. I think power users would appreciate the feature but most of our 1-time installation users would not care. I am fine having it if the investment is very small. #11: Jiří Suchomel (jsuchome) (2008-06-13 07:48:43) (reply to #8) Hyperlink yes, but for enabling/disabling, not for full firewall configuration. This is not really possible in 1st stage, see Lukas' comments 4 and 6. #9: Federico Lucifredi (flucifredi) (2008-06-12 18:11:07) Guys, I am not following... why do we want the enable/disable choice in 1st stage? Looks just fine to me as is. Please clarify what's the advantage of allowing the choice earlier. #10: Jiří Suchomel (jsuchome) (2008-06-13 07:47:11) (reply to #9) In previous versions, we had the network configuration proposed which user had to accept, but now the networking is (by default) configured automatically (and this is without debates fine for most users). The old screen with the network configuration had an option disable firewall with one click and this is the thing which I miss now (yes, it is possible to use the old way also in 11.0, but it brings bunch of other configuration options that are correctly done automatically). So, earlier actually means during installation . Of course this is possible to configure after the installation, but just like many other users, I'd like to have the system configured after the system is installed. #12: Federico Lucifredi (flucifredi) (2008-06-13 17:02:08) (reply to #10) okay - I understand. Yes, this is handy, as it saves the need to go through all the config when all one wants to do is remove the fw. _if_ there is a way to include in the early workflow, lets do it. Of course, that may not be the case on "keeping it simple" grounds. #13: Stanislav Visnovsky (visnov) (2008-06-19 13:21:59) (reply to #12) I agree, if we are able to find a reasonable place, would be nice to have. #15: Jiri Srain (jsrain) (2009-07-16 12:26:49) Bubli, please, add very simple Firewall configuration to the first stage (only enabling/disabling firewall itself and opening/closing the SSH port). #16: Ralph Ulrich (ulenrich) (2009-08-28 16:18:55) Case study - Firewall on factory 11.2 The most common case today is the most hard to find out how to configure: In a normal 192.168.0.0 network that has a router to internet connection, there is also a total cracked Windows computer. So I want to enable SUSEfirewall. But I don't have seperated internal/external devices - all help directs to this seperated zones. And is my 127.0.0.0 network affected if I do default all to untrusted/external ? Where are examples? Help is no help. Fortunately I found in a forum message I do have: file:///usr/share/doc/packages/SuSEfirewall2/EXAMPLES.html -- openSUSE Feature: https://features.opensuse.org/303859

1 0

[openFATE 304971] Improved Popup support from libyui
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #304971, revision 12 Title: Improved Popup support from libyui openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-16 09:22:38 reject reason: Not needed anymore. Priority Requester: Desirable Projectmanager: Desirable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by (cthiel1) + reject date: 2009-10-27 16:06:44 + reject reason: not done for 11.2. Priority Requester: Desirable Projectmanager: Desirable Requested by: Arvin Schnell (aschnell) Description: Currently writing popups with longer texts is difficult: Line wrapping must be done in YCP and thus cannot take font metrics into account. Using RichText widget is also difficult since it's not possible to know the correct height in advance. What I would like to see is a popup that does line wrapping (preserving parapraphs) and adjusts the height of the whole popup accordingly. The popup width should be a parameter or the popup could find a good ratio between width and height. Relations: - missing linebreak in german YaST2 partitioner message (novell/bugzilla/id: 190817) https://bugzilla.novell.com/show_bug.cgi?id=190817 Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-06-27 19:50:50) I guess this is something to leave for our colleagues in engineering to prioritize, thus labeling neutral for PM. #2: Stanislav Visnovsky (visnov) (2008-07-01 13:37:34) (reply to #1) Duncan, this is in your team, up to you if you need this. #3: Arvin Schnell (aschnell) (2008-07-16 10:18:29) Why isn't this needed anymore? What do we have instead? -- openSUSE Feature: https://features.opensuse.org/304971

1 0

[openFATE 305171] NFS4 support in libstorage
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305171, revision 7 Title: NFS4 support in libstorage - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by (cthiel1) + reject date: 2009-10-27 16:04:25 + reject reason: postponed. Priority Requester: Important Projectmanager: Desirable + openSUSE-11.3: New + Priority + Requester: Important Requested by: Arvin Schnell (aschnell) Description: Add NFS4 support to libstorage and YaST expert partitioner. -- openSUSE Feature: https://features.opensuse.org/305171

1 0

[openFATE 305351] pam_mount update to latest stable version
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305351, revision 12 Title: pam_mount update to latest stable version - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by (cthiel1) + reject date: 2009-10-27 16:00:56 + reject reason: postpone, config file changes were to risky Priority Requester: Important Projectmanager: Important + openSUSE-11.3: New + Priority + Requester: Important Requested by: Michael Calmer (mcalmer) Description: The author of pam_mount declared the current version 0.X as unsupported. We should update 11.2 to the newest version. We can also think about an update for SLE11 SP1 if possible. The problem here are massive changes in the configuration file again. A clean and safe convert of the configuration might not be possible. Relations: - pam_mount: update to latest (novell/bugzilla/id: 438457) https://bugzilla.novell.com/show_bug.cgi?id=438457 Discussion: #2: Jan Engelhardt (jengelh) (2009-03-01 16:34:42) Anything but the latest two top releases are basically unsupported. The config file has been stripped of most built-in defaults that nobody ever changes anyway. For a conversion, just strip everything but < mntoptions>, <volume> and <luserconf>. -- openSUSE Feature: https://features.opensuse.org/305351

1 0

[openFATE 305500] User has no way to switch compiz on / off
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305500, revision 16 Title: User has no way to switch compiz on / off - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by (cthiel1) + reject date: 2009-10-27 15:59:58 + reject reason: yast isn't used to configure X anymore. Priority Requester: Desirable Projectmanager: Desirable Requested by: Juergen Weigert (jnweiger) Description: I searched Yast, SAX, gnome-display-properties, and did a desktop search for 'compiz'. The switch is not well advertised, it is here: computer -> System: control-Center -> Look and Feel: Desktop Effects -> [ ] enable desktop effects. -> Close Command line: simple-ccsm, but not ccsm. I suggest to enhance yast to allow compiz switching, using the above information. And/or include package fusion-icon. Discussion: #4: Cameron Blackwood (drkorg) (2009-10-05 04:37:35) +1. It would be great to be able to turn off all eye candy (for remote/vnc hosts) or to crank it up to full (for desktops and laptops). A simple 'no candy' or 'full candy' yast setting would be great! -- openSUSE Feature: https://features.opensuse.org/305500

1 0

[openFATE 305884] Support for creating partitions on ISW arrays
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305884, revision 15 Title: Support for creating partitions on ISW arrays - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by (cthiel1) + reject date: 2009-10-27 15:56:06 + reject reason: SLES-only feature. Priority Requester: Important Projectmanager: Important Requested by: Marc Ruehrschneck (macrue) Partner organization: openSUSE.org Description: Boot and install support for partitioned devices for MD external format (ISW) for supported raid levels (0, 1, 10, 5, 6?). Enable yast-storage to create partitions on ISW arrays. Either enable yast-storage to understand mdp devices (partitionable md devices), or use kpartx to expose the individual array partitions Business case (Partner benefit): openSUSE.org: Enable feature parity with the Windows IMSM stack for Linux customers Discussion: #3: Michael Löffler (michl19) (2009-05-27 18:57:38) (reply to #2) I wonder here as well. If not in openSUSE where is the place for upstream devlopment. And I wonder if we can open up the feature to openFATE so the community can comment here as well. #4: Duncan Mac-Vicar (dmacvicar) (2009-08-27 10:31:28) Please reject, no resources in storage area. -- openSUSE Feature: https://features.opensuse.org/305884

1 0

[openFATE 303736] yast and libzypp should respect the disk space reserved for root
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303736, revision 11 Title: yast and libzypp should respect the disk space reserved for root openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 12:18:47 reject reason: Postponing. This is nice to have. Priority Requester: Desirable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by (cthiel1) + reject date: 2009-10-27 15:34:16 + reject reason: -ENOTIMELEFT for 11.2. Priority Requester: Desirable Projectmanager: Desirable Requested by: Ladislav Slezak (lslezak) Description: If e.g. root partition has 70MB free user space and 500MB free space reserved for root user yast reports 570MB total free space. But installation of a package which is greater than 70MB fails: installing package kdelibs3-devel-doc-3.5.5-45 needs 335MB on the / filesystem Yast should display the non-root free space (70MB in this case). It seems that it is valid only for ext2/ext3 filesystems (XFS and ReiserFS seem to not support root space). Default reserved space for ext2/ext3 is 5%. References: https://bugzilla.novell.com/show_bug.cgi?id=237309 Discussion: #1: Luc de Louw (delouw) (2009-07-12 14:43:12) The problem is that the default reserved space is way to much for todays diskspace available. IMHO this issue should be addressed upstream, the default space should be much less than 5% or even a fixed amount of space e.g. 100MB. The reserved space for root is tought for emergencies and not for installing new packages, at least not with that size. At the end of the day it is not a good idea to support that feature. -- openSUSE Feature: https://features.opensuse.org/303736

1 0