December 2010 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 310152] Enable Num Look at boot time.
by fate_noreply＠suse.de 19 Jul '11

19 Jul '11

Feature added by: Genix Info (genixinfo) Feature #310152, revision 1 Title: Enable Num Look at boot time. openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Genix Info (genixinfo) Description: Enable Num Look at boot time, through this tip: > How do I start for the Num Lock always enabled? # man setleds or put this script in the last line of rc.local numlock.sh #!/bin/bash INNIT=/dev/tty[1-8] for tty in $INNIT; do setleds -D +num < $tty done This link has this and many other tips for the keyboard: Original (Brazilian Portuguese): http://www.zago.eti.br/ (ttp://www.zago.eti.br/teclado1.txt) teclado1.txt (ttp://www.zago.eti.br/teclado1.txt) Translated into English: http://translate.google.com.br/translate?u=http%3A%2F%2Fwww.zago.eti.br%2Ft… (http://translate.google.com.br/translate?u=http%3A%2F%2Fwww.zago.eti.br%2Ft…) -- openSUSE Feature: https://features.opensuse.org/310152

1 9

[New: openFATE 310739] Explain how to "disable" pam-config, if manual pam configuration is in place
by fate_noreply＠suse.de 18 Jul '11

18 Jul '11

Feature added by: Michael Calmer (mcalmer) Feature #310739, revision 1 Title: Explain how to "disable" pam-config, if manual pam configuration is in place openSUSE-11.4: New Priority Requester: Mandatory Requested by: Michael Calmer (mcalmer) Description: pam-config write the files /etc/pam.d/common-***-pc. If a user want to use its own configuration, he has to remove the symlink from /etc/pam.d/common-*** to the -pc files and create the common-*** file with his configuration to prevent pam-config from removing his configuration. But this is nowhere explained. It should be added to the pam-config manpage Additionally we should think about a way to prevent overwriting manual changes to the service files, if --service is used. -- openSUSE Feature: https://features.opensuse.org/310739

1 8

[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 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 306410] Guest session
by fate_noreply＠lists4.suse.com 29 Jun '11

29 Jun '11

Feature added by: Vincent Untz (vuntz) Feature #306410, revision 1, last change by Title: Guest session openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Description: It'd be nice to provide a guest session, for people using a computer that is not their computer. This guest session would: * require no password * would cleanup itself on logout/login * be easily accessible from the login manager It should of course be easy to disable it, for people who don't want this. -- openSUSE Feature: https://features.opensuse.org/306410

2 1

[New: openFATE 309326] Make Attributes storable on more items
by fate_noreply＠suse.de 24 Jun '11

24 Jun '11

Feature added by: Adrian Schröter (adrianSuSE) Feature #309326, revision 1 Title: Make Attributes storable on more items Buildservice: New Priority Requester: Desirable Requested by: Adrian Schröter (adriansuse) Description: Attributes should be stored on * Repositories * binary packages (md5sum ?) -- openSUSE Feature: https://features.opensuse.org/309326

1 1

[New: openFATE 309308] spectool in buildservice?
by fate_noreply＠suse.de 24 Jun '11

24 Jun '11

Feature added by: Robert Xu (bravoall1552) Feature #309308, revision 1 Title: spectool in buildservice? Buildservice: Unconfirmed Priority Requester: Important Requested by: Robert Xu (bravoall1552) Description: I'm marking this as important because it really is. As you know, we can put URLs in spec files. The tool spectool can parse spec files and automatically download the Sources and Patches into the desired directories. So why don't we just integrate this into OBS? it's easier than just uploading one by one or using osc. Not only that, everytime the spec file is changes, any sources that have been deleted can be deleted by obs after a period (probably 3 days) and any new sources can be retrieved immediately! -- openSUSE Feature: https://features.opensuse.org/309308

1 2

[New: openFATE 310925] Increase of the appliance's hard drive size
by fate_noreply＠suse.de 24 Jun '11

24 Jun '11

Feature added by: Gregor Dschung (chkpnt) Feature #310925, revision 1 Title: Increase of the appliance's hard drive size Buildservice: Unconfirmed Priority Requester: Important Requested by: Gregor Dschung (chkpnt) Partner organization: openSUSE.org Description: The appliance's hard drive is too small. There is only less than 200MB free space left. Business case (Partner benefit): openSUSE.org: I wanted update my appliance with "zypper patch", because "zypper lp" listed several security related patches. But the command wasn't successfull, because the root partition went out of space. I wasn't able to resize the partition with VMware vSphare, so I had to exchange the appliance's vmdk-Image. This means, every configuration done in /srv/www/obs is lost and needs to be reconfigured (like LDAP settings, etc.). -- openSUSE Feature: https://features.opensuse.org/310925

1 2

[New: openFATE 310292] TOMOYO YaST Integration
by fate_noreply＠suse.de 24 Jun '11

24 Jun '11

Feature added by: Martyn Hare (NthDeGeek) Feature #310292, revision 1 Title: TOMOYO YaST Integration openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Martyn Hare (nthdegeek) Partner organization: openSUSE.org Description: Add TOMOYO as an option for security on OpenSuSE's YaST. It offers more features than AppArmor and with the correct YaST integration it can be made to work in the same "targeted" way as AppArmor does by default, offering powerful features to less experienced users without causing system-wide changes. It is pathname based just like AppArmor but also provides domain separation based upon execution history. Just like AA it offers an extensive learning mode which is simple to use and policies are human readable. Use Case: Derek wants a system where only applications with a created policy may execute according to principle of least authority. With AppArmor he can only lock down specific applications, and SELinux uses a complex labelling system (and doesn't offer POLA). With TOMOYO he can apply learning mode to analyse normal behaviour system-wide, then tweak human-readable policy to run as enforced. Suzie runs a server where remote access is limited but local access is intended to be unimpeded. TOMOYO would differentiate between a local login shell and remote login shell by the execution history, resulting in a restricted shell remotely but not locally without the need to create hard links or use alternative user accounts. John wants to limit who can directly connect to his P2P client, but needs to keep the port randomised to avoid conflicts with others on his residential network, but has other applications listening on ports too - TOMOYO allows him to restrict what direct inbound connections are accepted by the P2P application. Business case (Partner benefit): openSUSE.org: Benefits to OpenSuSE: * The ability for an end-user to lock down the whole system if he/she chooses in addition to the ability to lock down individual applications * Conditional checking of permissions based on whether file is owned and/or what user is accessing files * Control over listening, sending and receiving over the network per-process on a per-port and/or per-IP basis * Enhanced control over the use of capabilities on a global and/or per-app basis * Security which can be LSM or non-LSM (1.x has out-of-tree patches, 2.x which is in-tree uses LSM) * If using 1.x the end-user may run TOMOYO in parallel with either AppArmor or SELinux (this may allow SELinux policies to get additional testing!) * Hard link security bypassing resolved through control over the ability to create and/or use hard links -- openSUSE Feature: https://features.opensuse.org/310292

1 15