July 2011 - openSUSE Features - openSUSE Mailing Lists

[openFATE 307834] allow zypper to understand obs:// repos
by fate_noreply＠suse.de 10 Jul '11

10 Jul '11

Feature added by: andrea florio (anubisg1) Feature #307834, revision 1 Title: allow zypper to understand obs:// repos openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: andrea florio (anubisg1) Partner organization: openSUSE.org Description: i think will be wonderful if zypper/YaST will be able to menage obs repos using the URI currenctly used on kiwi... obs://X11:/lxde/openSUSE_11.1 (or even obs://X11:lxde/openSUSE_11.1 using the obs name without / ) is much easier than http://download.opensuse.org/repositories/X11:/lxde/openSUSE_11.1 (hoping i didn't forget something writing that down) Business case (Partner benefit): openSUSE.org: to have a better cooperation between zypper and obs (and make easier to add obs repos just adding the project name instead of the full url -- openSUSE Feature: https://features.opensuse.org/307834

1 9

[New: openFATE 308472] switch from XDM to LXDM for XFCE and "X minimal installation"
by fate_noreply＠suse.de 10 Jul '11

10 Jul '11

Feature added by: andrea florio (anubisg1) Feature #308472, revision 1 Title: switch from XDM to LXDM for XFCE and "X minimal installation" openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: andrea florio (anubisg1) Description: xdm is a very lightweight login manager, but it's actually really ugly and not easy to use. i suggest to switch to LXDM as default login manager. it's lightweight (LXDE default one) and depends only on gtk pam and ConsoleKit. lxdm also allow to create a branding package to customize the apperence -- openSUSE Feature: https://features.opensuse.org/308472

1 7

[New: openFATE 312623] Aeskulap DICOM image viewer
by fate_noreply＠suse.de 10 Jul '11

10 Jul '11

Feature added by: Daniele Guerrieri (threarth) Feature #312623, revision 1 Title: Aeskulap DICOM image viewer openSUSE Medical: Unconfirmed Priority Requester: Important Requested by: Daniele Guerrieri (threarth) Partner organization: openSUSE.org Description: I think that Aeskulap could be included: http://aeskulap.nongnu.org/. I tried to compile it myself but it failed, maybe i need to setup better my dev environment. -- openSUSE Feature: https://features.opensuse.org/312623

1 0

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

06 Jul '11

Feature changed by: Robert Davies (robopensuse) Feature #312321, revision 8 Title: Replace blowfish with sha512 as password hash openSUSE Distribution: Implementation Priority Requester: Important Requested by: Thorsten Kukuk (kukuk) 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 + Business case (Partner benefit): + openSUSE.org: More secure password hashing, which are harder to crack + with passwd cracking software. 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? #4: Ludwig Nussel (lnussel) (2011-07-06 14:56:32) (reply to #3) I've filed a separate feature for dropping libxcrypt as a clean solution requires a glibc with gensalt functions to avoid copies of them everywhere -> 312617. #5: Robert Davies (robopensuse) (2011-07-06 15:26:42) Background for those who haven't seen it. Migration of current from "blowfish" hashed passwords, ought to be mandatory, because of the sign extension bug that's been found (in "John the Ripper". As, current user passwords would have to be changed anyway, it makes sense to force migrate to sha512 anyway as part of update. See "A hole in crypt_blowfish" http://lwn.net/Articles/448699/ (http://lwn.net/Articles/448699/) for explanation of the problem & discussion. Executive summary "crypt_blowfish developer Alexander Peslyak (aka Solar Designer) analyzed the effects of the bug and found that some password pairs would hash to the same value with only minimal differences (e.g. "ab£" hashed to the same value as "£"), which would make password cracking easier. A further analysis shows that some characters appearing just before one with the high bit set may be effectively ignored when calculating the hash." -- openSUSE Feature: https://features.opensuse.org/312321

1 0

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

06 Jul '11

Feature changed by: Robert Davies (robopensuse) Feature #312321, revision 7 Title: Replace blowfish with sha512 as password hash openSUSE Distribution: Implementation Priority Requester: Important Requested by: Thorsten Kukuk (kukuk) 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? #4: Ludwig Nussel (lnussel) (2011-07-06 14:56:32) (reply to #3) I've filed a separate feature for dropping libxcrypt as a clean solution requires a glibc with gensalt functions to avoid copies of them everywhere -> 312617. + #5: Robert Davies (robopensuse) (2011-07-06 15:26:42) + Background for those who haven't seen it. + Migration of current from "blowfish" hashed passwords, ought to be + mandatory, because of the sign extension bug that's been found (in + "John the Ripper". As, current user passwords would have to be changed + anyway, it makes sense to force migrate to sha512 anyway as part of + update. + See "A hole in crypt_blowfish" http://lwn.net/Articles/448699/ + (http://lwn.net/Articles/448699/) for explanation of the problem & + discussion. Executive summary "crypt_blowfish developer Alexander + Peslyak (aka Solar Designer) analyzed the effects of the bug and found + that some password pairs would hash to the same value with only minimal + differences (e.g. "ab£" hashed to the same value as "£"), which would + make password cracking easier. A further analysis shows that some + characters appearing just before one with the high bit set may be + effectively ignored when calculating the hash." -- openSUSE Feature: https://features.opensuse.org/312321

1 0

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

06 Jul '11

Feature changed by: Ludwig Nussel (lnussel) Feature #312321, revision 6 Title: Replace blowfish with sha512 as password hash - openSUSE 11.5: Evaluation by engineering manager + openSUSE Distribution: Implementation Priority Requester: Important - Projectmanager: Mandatory Requested by: Thorsten Kukuk (kukuk) 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? + #4: Ludwig Nussel (lnussel) (2011-07-06 14:56:32) (reply to #3) + I've filed a separate feature for dropping libxcrypt as a clean + solution requires a glibc with gensalt functions to avoid copies of + them everywhere -> 312617. -- openSUSE Feature: https://features.opensuse.org/312321

1 0

[openFATE 308626] Snapshot/Rollback interface to the ZYpp stack
by fate_noreply＠suse.de 06 Jul '11

06 Jul '11

Feature changed by: Andreas Jaeger (a_jaeger) Feature #308626, revision 51 Title: Snapshot/Rollback interface to the ZYpp stack openSUSE-11.3: Rejected by Gerald Pfeifer (geraldpfeifer) reject date: 2010-11-17 00:53:34 reject reason: openSUSE 11.3 has been released months ago. Priority Requester: Mandatory - openSUSE-11.4: Evaluation by project manager + openSUSE-11.4: Done Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Ability for libzypp and exposed via zypper to snapshot either automatically or explicitly the system before commit happens, plus an interface to revert the system. The interface should be generic and allow for different possible implementations which should be offered depending on the context: * btrfs based if /root is btrfs * simple based on package list before commit, plus package history and current package list to determine diff last transaction * two root partitions, where the interface would clone root filesystem before commit and switch them at rollback time. The feature includes the concept, and a working implementation with one or more of the strategies described before. References: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autou… http://wiki.rpath.com/wiki/Conary:conary_rollback packages: libzypp snapper zypper Relations: - grub1 patch for btrfs boot (url: ) Documentation Impact: Requires description of the functionality in zypper options Test Case: zypper install foo bar zypper rollback System should be as before the installation. Corner cases are not important. Use Case: Administrator installs a bunch of updates, which leaves the system in an an unworkable state. He types zypper rollback to undo the changes. Business case (Partner benefit): openSUSE.org: * Customer asked about snapshoting during our last meeting. * Feature parity with Solaris which is implementing package rollback based on ZFS * RHEL goes the same route, announced btrfs rollbacks in yum * We can do better, offering something more flexible and not btrfs dependent to support different scenarios: SLES (btrfs), Appliances (dual system partition), openSUSE (simple package list) Discussion: #1: Federico Lucifredi (flucifredi) (2010-03-05 07:29:41) PM: Important for 11.3. (sorry, on web client). #3: Joachim Werner (joachimwerner) (2010-04-28 18:10:50) I have SLEPOS-specific use cases for this feature, too. IBM implemented a similar rollback feature in IRES2, based on tripwire AFAIK. Some techical considerations we need to understand: Rolling back the right things What customers really want is not a dumb rollback of everything on the system to the old state, but just the changes done by the update. So it may be necessary to make sure the snapshot only applies to the configuration directories (usually /etc) and the code directories (/usr) affected by the update, but not things like logfiles (which should be continuous) or application data (nobody wants to get their database files rolled back by accident, or data a user has saved in /home/username in the meantime). Another potential issue with some applications is that they can be in an inconsistent state if they aren't stopped during a snapshot. This is a more generic problem with snapshots as such. For this Windows has mechanisms to inform an application that it's going to do a shadow copy now. In Linux there is no single interface to trigger that, although some databases and other applications have there own way of switching into a read-only snapshotting-safe mode. So, this is all doable, but just applying a system-wide snapshot seems to be too simple. Maybe we can just copy what Red Hat is doing here (if it's good enough). Red Hat has finished this feature in Fedora, and it's probably going to be in RHEL6 at some point, too. https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs (https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs) contains a few considerations on this. Avoiding situations that can't be recovered zypper rollback sounds like a good plan at first, but it is not in all cases. If you apply an update that breaks the system, this could mean that a kernel update went wrong and you can't even boot beyond a certain stage. So there needs to be a way of entering the recovery from the earliest possible level, the boot prompt. There needs to be an option to boot into the snapshotted system, and from there eliminate the changes made after the snapshot and declare the snapshot to be the current state. For the worst case (a broken grub package or so kills the bootloader configuration) we need to have a recovery workflow (from CD or so) that can still bring back the old working state. Do one thing right, not three things that solve the same problem If we decide to go down the btrfs route (which I like) we should not also solve the same problem using several other approaches. Why use dual system partitions if you can have snapshots? #7: Duncan Mac-Vicar (dmacvicar) (2010-10-21 10:43:26) I would like to clarify some issues: For rollbacks, it would be the ideal situation to have the root filesystem completely under btrfs, otherwise you run into the problem that kernels are not affected by the rollback and this increases complexity. * a) For this we need to boot with btrfs. Matthias told me we should ignore this problem because under EFI you have to put the kernel under /efi in a FAT partition, but my own research tells me that what is in FAT /efi is the grub EFI program, and therefore the kernel could be in btrfs if the grub EFI program supports finding the kernel with btrfs. Can anyone confirm this? * b) For booting with btrfs we need either grub2, or syslinux or a patch for grub1 (added as a reference to the feature). Which route will we follow here? Do we have anyone empowered to make this decision soon? * c) if b) is solved with grub1 patch I suggest we open a feature entry to track that one. #9: Olaf Kirch (okir) (2010-10-22 12:56:49) (reply to #7) My preferred solution would be to enable grub1 for btrfs; it seems to pose the least risk - assuming the btrfs code is stable enough. (BTW either my fate client is too old, or the link you added is broken). #13: Gerald Pfeifer (geraldpfeifer) (2010-11-17 00:53:01) One further idea that came up is adding a bootloader entry (or several) that, when chosen, would revert the system into an old state as represented/described by that entry and boot into it. This is more involved than the more basic scenarios here and might be suitable for another, linked FATE? #15: Federico Lucifredi (flucifredi) (2011-03-25 21:02:37) (reply to #13) I like that. If at all possible, we should provide a boot item into the previous snapshot. #14: Jörg Schmela (herz-von-hessen) (2011-02-25 18:42:40) therefore my full Consent #18: Michael Andres (mlandres) (2011-06-28 12:32:03) libzypp ability to execute pre/post commit plugin scripts is done (see http://doc.opensuse.org/projects/libzypp/HEAD/plugin-commit.html) Arvin is about to provide the snapper plugin, which actually takes the snapshots. #19: Arvin Schnell (aschnell) (2011-06-29 10:12:38) (reply to #18) I have now added a python-plugin for zypp that calls snapper pre and post to commits. I was told that this is all we provide for SLE11 SP2 so I'm setting this feature to Done although many more ideas are mentioned here. -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[openFATE 311297] Get rid of SuSEconfig.groff
by fate_noreply＠suse.de 06 Jul '11

06 Jul '11

Feature changed by: Karl Eichwalder (keichwa) Feature #311297, revision 26 Title: Get rid of SuSEconfig.groff openSUSE Distribution: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Michal Svec (msvec) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). Possible solutions: 1) Fix groff to respect locale settings (LC_PAPER); ideal solution. 2) Add that code to yast2 language (write things during installation and whenever the user changes it later); should be easy to do. 3) Drop SuSEconfig.groff without replacement; unclear consequences. 4) Add that code to yast2 language (write things only during installation), based on comment #1. I would vote for 1, as it's a proper solution. If not doable or not doable with a reasonable effort let's at least do 2. Discussion: #1: Thorsten Kukuk (kukuk) (2011-02-15 13:24:41) Option 1 is for various reason no option. My proposal is based on 2: YaST2 should write /etc/papersize during installation, and only there. Rewriting it later is a bad idea, since the admin could have choosen to change the default. #2: Michal Svec (msvec) (2011-02-15 13:35:25) (reply to #1) Can you elaborate why is 1 not an option? Regarding your proposal it is now changed everytime a new package is installed (unless turned off in sysconfig), so I don't think it would hurt to update it from YaST, but I am fine with both options. #3: Thorsten Kukuk (kukuk) (2011-02-15 13:38:13) (reply to #2) Read the code, the file is not changed if the administrator has modified it. #4: Michal Svec (msvec) (2011-02-15 13:43:49) (reply to #3) OK. And why is 1 not an option? #5: Thorsten Kukuk (kukuk) (2011-02-15 13:49:28) (reply to #4) You don't want to have that code in YaST2, this gives only surprises and is a support nightmare, if YaST2 sometimes changes the config and sometimes not. #6: Michal Svec (msvec) (2011-02-15 14:04:44) (reply to #5) That is clear. I wonder why we cannot go with option 1 (fix groff). #7: Thorsten Kukuk (kukuk) (2011-02-15 14:07:59) (reply to #6) Sorry, misunderstoood. We cannot fix groff because it is not broken. groff has a config file, and that should be honoured. I for example don't want letter output only because I prefer an english locale. #8: Michal Svec (msvec) (2011-02-15 14:11:18) (reply to #7) I would expect you to set LC_PAPER correctly then. But anyways, I can live with option 4. #9: Michal Vyskocil (mvyskocil) (2011-02-15 14:21:42) (reply to #3) SuSEconfig.groff in sle-11-sp1 version overwrites the /etc/papersize everytime - see bnc#644467 (https://bugzilla.novell.com/show_bug.cgi?id=644467) . The fix is easy (I assume the check_md5_and_move is in SLE-11-SP1). So in case you decided to stay with this script, this bug should be fixed. #11: Thorsten Kukuk (kukuk) (2011-05-18 10:09:45) For openSUSE: We can break with everything, so I suggest to remove the SuSEconfig.groff file completly without replacement. Background: groff does not read this file by default, you have to specify it on the command line. For SLE11 SP2 this is not an option, since we don't know if there aren't scripts using that option and expecting that the file exists. #12: Michal Vyskocil (mvyskocil) (2011-06-28 09:17:18) (reply to #11) Removed together with 1.21 update - sent to Factory by request 74706. Marked as done for openSUSE and SLE-12. - Release Notes: [Config] groff: /etc/papersize No Longer Depends on - sysconfig Variables + Release Notes: groff: /etc/papersize No Longer Depends on sysconfig + Variables Challenge: /etc/papersize no longer inherits settings from /etc/sysconfig/language when running SuSEconfig. Solution: Set /etc/papersize directly, e.g.: echo "letter" > /etc/papersize For details, see man 5 groff_font ('papersize string'). -- openSUSE Feature: https://features.opensuse.org/311297

1 0

[New: openFATE 308693] support keyboard layout switching in initrd
by fate_noreply＠suse.de 04 Jul '11

04 Jul '11

Feature added by: Ludwig Nussel (lnussel) Feature #308693, revision 1 Title: support keyboard layout switching in initrd openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Ludwig Nussel (lnussel) Description: When using an encrypted root partition only plain ASCII characters are possible as passphrase. International users may want to also use special characters though. https://bugzilla.novell.com/show_bug.cgi?id=547923 -- openSUSE Feature: https://features.opensuse.org/308693

1 3

[openFATE 312557] Yast DNS Server module: DNS Views Support
by fate_noreply＠suse.de 04 Jul '11

04 Jul '11

Feature changed by: Abel HM (abelhm) Feature #312557, revision 6 Title: Yast DNS Server module: DNS Views Support openSUSE 12.1: New Priority Requester: Desirable Requested by: Irving Leonard (irvingleonard) Technical Contact: (Novell) Partner organization: openSUSE.org Description: yast2-dns-server doesn't have VIEWS support This package provides an administration interface to bind DNS server. It is very usefull but doesn't support views (DNS VIEWS). There are situations where it is a show stopper. References: yast2-dns-server haven't VIEWS support https://bugzilla.novell.com/show_bug.cgi?id=686385 + Business case (Partner benefit): + openSUSE.org: I consider the views manage feature could be great for + this module. I have knowledge about a lot of WANs that use DNS VIEWS. + This feature can make the difference in the selection of the OS for DNS + servers in this case. Simple a GREAT idea. -- openSUSE Feature: https://features.opensuse.org/312557

1 0