March 2015 - openSUSE Features - openSUSE Mailing Lists

[openFate 305356] 802.1x authentication on wired network using YaST via wpa_supplicant
by fate_noreply＠suse.de 22 Apr '15

22 Apr '15

Feature added by: Marius Tomaschewski <mt(a)novell.com> Feature #305356, revision 1, last change by Title: 802.1x authentication on wired network using YaST via wpa_supplicant openSUSE-11.2: New Priority Requester: Desirable Requested by: Marius Tomaschewski <mt(a)novell.com> Partner organization: openSUSE.org Description: Some networks using 802.1x authentication on metallic Ethernet and I think it would be cool have a possibility, handle this connection type using YaST. The major problem to support this is that the wpa_supplicant is in /usr/sbin; it seems also to be difficult to move it to /sbin because of all the libs the wpa_supplicant is using. What would be required, is to extent the "supported_on_localfs" function to check this and start the interface in remotefs flow when 802.1x is enabled. That is, using remotefs on 802.1x authenticated interfaces would be not possible -- same as with NetworkManager. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305356

1 9

[New: openFATE 314850] Ability to create encrypted partitions without using LVM
by fate_noreply＠suse.de 02 Apr '15

02 Apr '15

Feature added by: Maciej Pilichowski (truemacias) Feature #314850, revision 1 Title: Ability to create encrypted partitions without using LVM openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Maciej Pilichowski (truemacias) Partner organization: openSUSE.org Description: With no LVM OS installer is too strict when it comes to choose what partitions can be encrypted. From technical POV only /boot partition really has to be left not encrypted but for the rest -- as root, /var, /usr it can be done. So please provide this option in installer. Current lack of support is strange and limits power of the Linux capabilities. -- openSUSE Feature: https://features.opensuse.org/314850

1 5

[New: openFATE 318813] ALSA: Improved dmix defaults for multi-channel audio
by fate_noreply＠suse.de 28 Mar '15

28 Mar '15

Feature added by: Martin Herkt (lachs0r) Feature #318813, revision 1 Title: ALSA: Improved dmix defaults for multi-channel audio openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Martin Herkt (lachs0r) Partner organization: openSUSE.org Description: For those who still reject PulseAudio in favor of ALSAâs dmix, thereâs a small but significant improvement to the default configuration with regard to multi-channel audio sources. Currently, the default dmix device is limited to stereo sources, which means that playing surround sound sources necessitates exclusive access. Having to make sure nothing else is using the underlying hardware when trying to watch a movie is not nice. Thereâs a relatively trivial solution to this, using the upmix plugin, which is included with the alsa-plugins package. In general, I see no reason not to install this package, seeing as it also includes the Speex resampler (which is used automatically if available, and without which audio quality will be severely degraded for sources that need to be resampled by ALSA first). The only known case where this does not âjust workâ is when audio hardware exposes channels as multiple stereo pair subdevices instead of a true multi-channel card (e.g. EMU10K1), but this hardware is a special case anyway (and a somewhat rare one these days), and Iâm sure workarounds are possible. Test Case: https://github.com/mpv-player/mpv/wiki/ALSA:-Surround-Sound-and-Upmixing I wrote this article for users of mpv. It contains an example asoundrc. So to test this, make equivalent changes to the default dmix configuration and try playing a surround sound file with e.g. mpv (or use speaker-test) while something else is playing e.g. a stereo stream via the default device. Playback should not fail, and both sources should output sound to the appropriate channels (i.e. the stereo source should be upmixed and mpv should detect the correct channel map automatically, applying downmixing as necessary). Use Case: Playing audio from several applications with different channel configurations (e.g. stereo system notifications and a media player playing a surround sound file). Business case (Partner benefit): openSUSE.org: For some users, PulseAudio does not solve any problems (and in fact still is the source of some), or they may prefer dmix for other reasons, but with the current default configuration, just watching movies or playing games can be inconvenient, as it would require exclusive access to the sound hardware, and in some cases (e.g. openal-soft) editing configuration files just to get the channel mapping right. -- openSUSE Feature: https://features.opensuse.org/318813

1 0

[New: openFATE 318809] Add support for unlocking LUKS root volumes during boot process via SSH
by fate_noreply＠suse.de 26 Mar '15

26 Mar '15

Feature added by: Björn Voigt (bjoernv) Feature #318809, revision 1 Title: Add support for unlocking LUKS root volumes during boot process via SSH openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Björn Voigt (bjoernv) Partner organization: openSUSE.org Description: Unlocking a openSUSE system with full disk encryption is currently done locally on the console with a passphrase input. Systems installed with distributions like Debian and Ubuntu can be unlocked via SSH: https://www.debian-administration.org/article/579/Unlocking_a_LUKS_encrypte… There is a DRACUT module in development for this feature: https://github.com/haraldh/dracut/pull/39 https://bugzilla.redhat.com/show_bug.cgi?id=524727 Use Case: Servers which are controlled via remote control can be easily unlocked via SSH. The feature simplifies the management of full disk encrypted servers, because starting and restarting servers can be done without local console access. -- openSUSE Feature: https://features.opensuse.org/318809

1 0

[New: openFATE 318808] Bibliography management system
by fate_noreply＠suse.de 26 Mar '15

26 Mar '15

Feature added by: lissa coffey (lissacoffey) Feature #318808, revision 1 Title: Bibliography management system Education Li-f-e: Unconfirmed Priority Requester: Important Requested by: lissa coffey (lissacoffey) Partner organization: openSUSE.org Description: a web-based bibliography management system. Its functionality is similar to jabref, but the main advantage is that it allows to share and simultaneously access the bibliography database (which is managed with MySQL) . (http://unitedfilter.com/) The programming language is PHP. I found this system highly desirable to be included at least in openSUSE Life if not in openSUSE distribution -- openSUSE Feature: https://features.opensuse.org/318808

1 0

[New: openFATE 318771] Unified UI for modules managing services
by fate_noreply＠suse.de 18 Mar '15

18 Mar '15

Feature added by: Ancor Gonzalez Sosa (ancorgs) Feature #318771, revision 1 Title: Unified UI for modules managing services openSUSE Distribution: New Priority Requester: Desirable Requested by: Ancor Gonzalez Sosa (ancorgs) Partner organization: openSUSE.org Description: This has been already discussed in the YaST development mailing list and even in some video calls involving the UX team at SUSE. The problem is outlined in the first page of this document https://docs.google.com/document/d/1TQO-bdqagSOUssGqJsf3eEeMDh2w40BujdOFP9-… The UI is different between YaST modules and the expected behavior is different for different users. Since it was not possible to reach a total agreement on the proposal presented in the previous document, a new approach has been proposed at https://docs.google.com/drawings/d/1cVv4FY4tWRLAnMG96Cdfvw8asTNpzhFUdKn4TEq… The final goal should be to design a coherent and suprises-free interface and implement it in all YaST modules managing services to provide a consistent user experience. References: https://docs.google.com/document/d/1TQO-bdqagSOUssGqJsf3eEeMDh2w40BujdOFP9-… https://docs.google.com/drawings/d/1cVv4FY4tWRLAnMG96Cdfvw8asTNpzhFUdKn4TEq… -- openSUSE Feature: https://features.opensuse.org/318771

1 0

[openFATE 305326] 5 Second Boot
by fate_noreply＠suse.de 09 Mar '15

09 Mar '15

Feature changed by: akash vishwakarma (vish_99) Feature #305326, revision 19 Title: 5 Second Boot openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-02-09 15:47:52 reject reason: Sorry to be harsh, but this feature can't be implemented as asked for. Priority Requester: Mandatory + openSUSE Distribution: Unconfirmed + Priority + Requester: Desirable Requested by: Jared Allen (jpallen) Product Manager: Michael Loeffler (sprudel24) Partner organization: openSUSE.org Description: The amount of time required to boot up needs to be reduced drastically. I suggest we consider the work being done in this article: http://lwn.net/Articles/299483/ as our baseline and strive to make similar adjustments. Business case (Partner benefit): openSUSE.org: As we continue to get more involved in the Thin Client and UMPC markets, boot time becomes increasingly important. Intel's Moblin project is touting boot time as one of the significant features/advantages of their Moblin project. There are signs that other distros are following suit. We have at least one Thin Client partner that is requesting significant improvements in boot time in order to remain competitive. In fact, SLETC would have been included on more thin client hardware shipments to-date had we a faster boot time. Discussion: #1: Jared Allen (jpallen) (2008-10-06 17:03:30) I spoken with both AJ and Michael Meeks regarding this requirement. AJ suggested that include Coolo in the discussion since it will most definitely affect the distribution as a whole. #2: Stephan Kulow (coolo) (2009-01-20 15:18:14) similiar adjustments? Do you mean the "We had to do a lot of damage to X," part or the "use xfce" part? There is a limit on what you can do in a generic system and many of the low hanging fruits is already done. If you talk about getting a thin client to boot fast, then making transparent use of suspend & resume is the way to go IMO. Booting off cold hardware is problematic if you want more than xfce. There are about 100MB data to read for a pretty standard KDE session (and I assume GNOME is similiar) - on a pretty fragmented file system you get ~8MB/s netto - so just reading your files takes already 12s. Making preload dynamic on the blocks actually used is something that was discussed long, long ago, but the kernel still doesn't provide the infrastructure - so this is one of the TODOs, but possibly Intel got that ball rolling. Kernel drivers being quicker with probing would be another TODO, also listed in the article. Another urgent TODO is defragmentation because readahead helps only a little if the next update will scatter the files around your 1TB hard drive. #3: Jean-Daniel Dodin (jdd) (2009-02-15 10:28:27) may be this is plain stupid, forgive me if it is. The install time was dramatically reduced by the use of "images" of installs. Could it not be possible to build "images" of the installed system - that is to have all the necessary files on boot able to read at once. It's not exactly the same as suspend to disk, of like a suspend to disk with only the system. Most computers never change hardware and a new grub entry could be added: boot with new hardware #4: Ralph Ulrich (ulenrich) (2009-08-05 23:14:17) Squashfs could be utilized for that. It would be superior to preload as it also could do the initrd thing. But every time a /bin/lib is updated the whole squash-start-image needs to be updated also. Andthere it is to make sure such an image is not fragmented on disk. #5: Sławomir Lach (lachu) (2010-06-30 12:23:07) Already we need to update dependencies of running scripts after adding a new script. We can create tarbar on this command. Init system may only checks last modify date for each file in tarbar and compare it with file outside tarbar. -- openSUSE Feature: https://features.opensuse.org/305326

1 0