May 2011 - openSUSE Features - openSUSE Mailing Lists

[openFate 305593] Send notifications on link, branch and aggregate, show them in interface
by fate_noreply＠suse.de 23 May '11

23 May '11

Feature added by: Pavol Rusnak <prusnak(a)novell.com> Feature #305593, revision 1, last change by Title: Send notifications on link, branch and aggregate, show them in interface Buildservice: New Priority Requester: Desirable Requested by: Pavol Rusnak <prusnak(a)novell.com> Partner organization: openSUSE.org Description: * send notification emails on link, branch and aggregate and/or show how many packages are linked to current package - that should reduce number of deletions which break other people's packages -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305593

1 3

[New: openFATE 308270] add link to download all files(sources, patches, spec, etc...) as one file
by fate_noreply＠suse.de 23 May '11

23 May '11

Feature added by: Alex Savin (alexqwesa) Feature #308270, revision 1 Title: add link to download all files(sources, patches, spec, etc...) as one file Buildservice: Unconfirmed Priority Requester: Important Requested by: Alex Savin (alexqwesa) Description: if you want build some package local - you need download sources, patches, spec, and all other files, but some packages use very many files. Add link to download all files(what needed to build package) as one file. -- openSUSE Feature: https://features.opensuse.org/308270

1 5

[New: openFATE 308469] Automatically generated list of various private/open repositories
by fate_noreply＠suse.de 23 May '11

23 May '11

Feature added by: Lee Matheson (oldcpu) Feature #308469, revision 1 Title: Automatically generated list of various private/open repositories Buildservice: Unconfirmed Priority Requester: Important Requested by: Lee Matheson (oldcpu) Description: The new build service promises to make available many new packages for openSUSE community members. It also means proliferation of many packaged rpms to varying standards, with risk of dependency problems and breakage in users openSUSE systems, who add unsupported private repositories without understanding the risk. A way forward is needed to help both the private packagers and the community in using any newly available packages where appropriate, and not using them where not appropriate for use. A way forward start (but not the final answer) would be an automatically (on a regular basis) generated list posted on a web page/site, that would list all build service repositories, with a comment/descriptive field that the build service packager is required to fill in. A recommend field could be an indication as to their planned future support for any package (ie "one of package" for private use, or "temporary package for TBD time frame", or "planned for long term support", or "packaged for private testing" ... ) etc ... With this automatically generated/re-generated list in place, openSUSE users could go to the list to help them assess if they should download and install an rpm from a repository, or indeed if they should add the repository to their software package manager's repository list. -- openSUSE Feature: https://features.opensuse.org/308469

1 5

[New: openFATE 312362] AuthorizedKeysCommand patch for openssh OR openssh-lpk
by fate_noreply＠suse.de 22 May '11

22 May '11

Feature added by: BJ Taylor (beeg_98) Feature #312362, revision 1 Title: AuthorizedKeysCommand patch for openssh OR openssh-lpk Package Wishlist: Unconfirmed Priority Requester: Important Requested by: BJ Taylor (beeg_98) Partner organization: openSUSE.org Description: There has long been a need to combine opensshd authorized keys with ldap. A couple of solutions have come about, and I would love to see one of these make it mainstream with opensuse. Here is one patch I have found that is supposedly being implemented on both Fedora and RHEL6 products: https://bugzilla.mindrot.org/show_bug.cgi?id=1663 Of course there is the openssh-lpk patch as well. http://code.google.com/p/openssh-lpk My company has standardized on suse some time ago, but by policy we require dual factor authentication (key and password). We can not move to an ldap solution until there is a way to integrate ssh keys into ldap. We are a growing company and it is getting to the stage where it is painful to manage each server individually without a centralized system for authentication. Use Case: If you have 200 servers, and a requirement for ssh keys, you have to install the key on each server every time you hire somebody new. (Or if you let somebody go, you have to remove it from each server.) Using ldap+ssh keys would allow you to do that from one place. Business case (Partner benefit): openSUSE.org: This would make the SuSE suite of products SOOO much more business friendly while keeping security a priority (also important for businesses). -- openSUSE Feature: https://features.opensuse.org/312362

1 1

[New: openFATE 310940] Mumble into Distribution
by fate_noreply＠suse.de 20 May '11

20 May '11

Feature added by: Karl-Thomas Schmidt (genau-danben-denken) Feature #310940, revision 1 Title: Mumble into Distribution openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Karl-Thomas Schmidt (genau-danben-denken) Partner organization: openSUSE.org Description: Mumble, a groupchat system, should go into next Release. It could improve the support. A testchannel "openSUSE" is alreday set up at "openMafia.org". Working repos exist at buildservice. -- openSUSE Feature: https://features.opensuse.org/310940

1 5

[openFATE 305301] Central Regulatory Domain Agent (for 802.11)
by fate_noreply＠suse.de 19 May '11

19 May '11

Feature changed by: Marius Tomaschewski (mtomaschewski) Feature #305301, revision 57 Title: Central Regulatory Domain Agent (for 802.11) openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-10-27 16:08:49 reject reason: not done for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2010-11-15 11:30:29 reject reason: yast part not done yet. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.4: New Priority Requester: Mandatory Info Provider: (Novell) Requested by: Vladimir Botka (vbotka) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) Developer: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org 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 References: packages: wireless-regdb,crda,iw,sysconfig 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 - switch nl80211 wpa_supplicant driver in ifup-wireless for WIRELESS_REGULATORY_DOMAIN support (novell/bugzilla/id: 585802) https://bugzilla.novell.com/show_bug.cgi?id=585802 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. #25: Jiri Benc (jbenc) (2009-11-04 11:56:30) Opening for 11.3 and setting as mandatory for requester, as without the feature wifi cards are not fully usable outside of the US (and in some cases not even there). #26: Marius Tomaschewski (mtomaschewski) (2010-03-05 15:07:43) (reply to #25) Thanks! I've created bug 585802 to switch to the new nl80211 wpa_supplicant driver as default in ifup-wireless, except in cases where we know that it does not work. #27: Vladimir Botka (vbotka) (2010-05-18 20:22:08) crda and wireless-regdb packages are available and functional in 11.3 . New nl80211 extension must be used to set the country. + #34: Marius Tomaschewski (mtomaschewski) (2011-05-19 14:58:40) + Sysconfig package is in submit request 12203 + (https://build.suse.de/request/show/12203) on the way to SLE-11-SP2:GA -- openSUSE Feature: https://features.opensuse.org/305301

1 0

[openFATE 312321] Replace blowfish with sha512 as password hash
by fate_noreply＠suse.de 18 May '11

18 May '11

Feature changed by: Thorsten Kukuk (kukuk) Feature #312321, revision 5 Title: Replace blowfish with sha512 as password hash - openSUSE 11.5: New + openSUSE 11.5: Evaluation by engineering manager Priority Requester: Important + Projectmanager: Mandatory Requested by: Thorsten Kukuk (kukuk) Product Manager: (Novell) Project Manager: (Novell) + Engineering Manager: (Novell) Partner organization: openSUSE.org Description: Since upstream has meanwhile a good replacement for DES crypt (sha256 and sha512), we should follow the other distributions and switch to sha512 as default password hash for local accounts. For openSUSE this means: * Make sha512 the new password hash (pwdutils, YasT2? * Stay with blowfish patch in glibc libcrypt to allow people with blowfish hash to login * Remove blowfish as option from YaST2 * Drop libxcrypt Discussion: #1: Bruno Friedmann (bruno_friedmann) (2011-05-17 17:24:55) Want to add me as interested but get an error Errorcode: 0 Message: undefined method `next=' for nil:NilClass #2: Thomas Schmidt (digitaltomm) (2011-05-17 17:35:32) (reply to #1) Please try again, that was caused because the product openSUSE 11.5 was not created completely. + #3: Thorsten Kukuk (kukuk) (2011-05-18 15:21:35) + pwdutils is adjusted. Lukas, can you please remove blowfish from YaST2 + as option to choose and link yast2-core against libcrypt and not + libxcrypt? -- openSUSE Feature: https://features.opensuse.org/312321

1 0

[openFATE 312321] Replace blowfish with sha512 as password hash
by fate_noreply＠suse.de 17 May '11

17 May '11

Feature changed by: Thomas Schmidt (digitaltomm) Feature #312321, revision 4 Title: Replace blowfish with sha512 as password hash openSUSE 11.5: New Priority Requester: Important Requested by: Thorsten Kukuk (kukuk) Product Manager: (Novell) Project Manager: (Novell) Partner organization: openSUSE.org Description: Since upstream has meanwhile a good replacement for DES crypt (sha256 and sha512), we should follow the other distributions and switch to sha512 as default password hash for local accounts. For openSUSE this means: * Make sha512 the new password hash (pwdutils, YasT2? * Stay with blowfish patch in glibc libcrypt to allow people with blowfish hash to login * Remove blowfish as option from YaST2 * Drop libxcrypt Discussion: #1: Bruno Friedmann (bruno_friedmann) (2011-05-17 17:24:55) Want to add me as interested but get an error Errorcode: 0 Message: undefined method `next=' for nil:NilClass + #2: Thomas Schmidt (digitaltomm) (2011-05-17 17:35:32) (reply to #1) + Please try again, that was caused because the product openSUSE 11.5 was + not created completely. -- openSUSE Feature: https://features.opensuse.org/312321

1 0

[openFATE 312321] Replace blowfish with sha512 as password hash
by fate_noreply＠suse.de 17 May '11

17 May '11

Feature changed by: Bruno Friedmann (bruno_friedmann) Feature #312321, revision 3 Title: Replace blowfish with sha512 as password hash Requested by: Thorsten Kukuk (kukuk) Product Manager: (Novell) Project Manager: (Novell) Partner organization: openSUSE.org Description: Since upstream has meanwhile a good replacement for DES crypt (sha256 and sha512), we should follow the other distributions and switch to sha512 as default password hash for local accounts. For openSUSE this means: * Make sha512 the new password hash (pwdutils, YasT2? * Stay with blowfish patch in glibc libcrypt to allow people with blowfish hash to login * Remove blowfish as option from YaST2 * Drop libxcrypt + Discussion: + #1: Bruno Friedmann (bruno_friedmann) (2011-05-17 17:24:55) + Want to add me as interested but get an error Errorcode: 0 Message: + undefined method `next=' for nil:NilClass -- openSUSE Feature: https://features.opensuse.org/312321

1 0

[openFATE 312321] Replace blowfish with sha512 as password hash
by fate_noreply＠suse.de 17 May '11

17 May '11

Feature changed by: Martin Vidner (mvidner) Feature #312321, revision 2 Title: Replace blowfish with sha512 as password hash Requested by: Thorsten Kukuk (kukuk) Product Manager: (Novell) Project Manager: (Novell) + Partner organization: openSUSE.org Description: Since upstream has meanwhile a good replacement for DES crypt (sha256 and sha512), we should follow the other distributions and switch to sha512 as default password hash for local accounts. For openSUSE this means: * Make sha512 the new password hash (pwdutils, YasT2? * Stay with blowfish patch in glibc libcrypt to allow people with blowfish hash to login * Remove blowfish as option from YaST2 * Drop libxcrypt -- openSUSE Feature: https://features.opensuse.org/312321

1 0