April 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 304970] YaST UI for pam_mount configuration
by fate_noreply＠suse.de 10 Apr '10

10 Apr '10

Feature changed by: Jan Engelhardt (jengelh) Feature #304970, revision 17 Title: YaST UI for pam_mount configuration openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-12 16:48:23 reject reason: Postponing. Priority Requester: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-05-26 20:24:01 reject reason: Out of resources for 11.2. Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Important Requested by: Jiří Suchomel (jsuchome) Developer: (Novell) Description: See bug https://bugzilla.novell.com/show_bug.cgi?id=347144: user requests a way for configuring pam_mount. We already have feature 300967 for some part, maybe other parts of it could be used in samba-client module. Michael, please check which parts might have sense Relations: - inlcude pam_mount in an up-to-date version and provide a YaST interface for it (novell/bugzilla/id: 347144) https://bugzilla.novell.com/show_bug.cgi?id=347144 Discussion: #1: Michael Calmer (mcalmer) (2008-06-30 11:25:01) Hmm, maybe we should think about a general solution. We use currently pam_mount for encrypted home directiories. Mounting samba shares is requested and now we have a general request to configure pam_mount. The pam_mount configuration is more or less the same like /etc/fstab. It provides all filesystem types which are supported via fstab and some more with special handling from pam_mount directly. The main difference is, that it is possible to have general rules which applies for all users logging-in, groups of users (supporting uid ranges, by guid or guid ranges or group names) and rules which applies only for a single user. For single user configuration a plugin for the users module would be good, but for more general rules a special module would be the best way. Such a module should have an API which can be used by other modules like samba-client to push in special rules needed fo this kind of configuration. #3: Ralph Ulrich (ulenrich) (2010-03-28 18:08:58) Doing a factory upgrade as zyper ref&&zypper -d dup&&zypper dup This beta1 release did overwrite my /etc/pam.d configs that use pam_mount for automaticly mounting the encrypted /home. I did search for a yast config variable in /etc/sysconfig to keep my pam_mount configs intact in case further upgrades are coming. But I didn't find any viable variable .... And for to configure pam_mount with yast gui you need to configure some nis, kerberos servers + #4: Jan Engelhardt (jengelh) (2010-04-10 12:12:41) (reply to #3) + pam_mount dose not depend on NIS or Kerberos. -- openSUSE Feature: https://features.opensuse.org/304970

1 0

[New: openFATE 309252] Make vendor change updates visible and easy to install
by fate_noreply＠suse.de 10 Apr '10

10 Apr '10

Feature added by: Martin Schlander (cb400f) Feature #309252, revision 1 Title: Make vendor change updates visible and easy to install openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Martin Schlander (cb400f) Description: It requires too much work and knowledge to perform vendor changing updates - especially if you only want single packages and not switch vendor for every package in a repo. I suggest to make single vendor changing updates easily installable via the sw_single Search tab. For example like this: 1) Make the existence of the update possibility visible with colouring - similar to current red and blue packages. 2) Make the vendor changing package installable via the context menu - Right click package -> Update with vendor change -- openSUSE Feature: https://features.opensuse.org/309252

1 5

[New: openFATE 309290] Support of cascading credentials in OpenSSH via better GSSAPI support
by fate_noreply＠suse.de 08 Apr '10

08 Apr '10

Feature added by: Christoph Bartoschek (pontobart) Feature #309290, revision 1 Title: Support of cascading credentials in OpenSSH via better GSSAPI support openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Christoph Bartoschek (pontobart) Partner organization: openSUSE.org Description: Please include the patches at http://www.sxw.org.uk/computing/patches/openssh.html into the OpenSSH package. They allow kerberos ticket renewal on remote machines if the local tickets are updated. This is especiallly important for real single sign-on in a kerberos environment. Otherwise upon ticket expiration on each machine one is logged in one has to renew the tickets. This can be very tedious. Other popular distributions already support this like Debian, Gentoo and Fedora. Use Case: A user has a desktop machine and logs into a computing server via ssh. The tickets on the desktop are renewed each time the screen is unlocked. However the tickets on the computing servers are not automatically renewed. The patches allow this. Business case (Partner benefit): openSUSE.org: Allowing real single sign-on in our network. -- openSUSE Feature: https://features.opensuse.org/309290

1 0

[New: openFATE 308474] Only install a recommended subset of screensavers by default
by fate_noreply＠suse.de 07 Apr '10

07 Apr '10

Feature added by: Vincent Untz (vuntz) Feature #308474, revision 1 Title: Only install a recommended subset of screensavers by default openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Description: At the moment, a default openSUSE install gets all the screensavers from xscreensaver. While it's quite nice, for most people, that's way too much. I believe a selection of 10-15 screensavers should be made, and then the xscreensaver package should be split in: * xscreensaver: would contain the binary, and its data files * xscreensaver-recommended: would contain the recommended screensavers * xscreensaver-extras: would contain all the other screensavers Note that we'll also need to adapt the gnome-screensaver packaging for this, but that should be easy. Also, this would make it possible to install xscreensaver-recommended without xscreensaver itself, which is useful for GNOME, but probably also for KDE. -- openSUSE Feature: https://features.opensuse.org/308474

1 2

[New: openFATE 309253] add keyboard settings from YaST to gfxmenu in GRUB
by fate_noreply＠suse.de 03 Apr '10

03 Apr '10

Feature added by: Jozef Uhliarik (juhliarik) Feature #309253, revision 1 Title: add keyboard settings from YaST to gfxmenu in GRUB openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Jozef Uhliarik (juhliarik) Description: y2-bootloader set language and help text for GRUB gfxmenu but keyboard is not set. It is used default keyboard for language. It means there can be problem if somebody use Germany and set English keyboard in YaST because gfxmenu from GRUB uses german keyboard. -- openSUSE Feature: https://features.opensuse.org/309253

1 2

[openFATE 306476] Install boot entry configurable in kernel git file
by fate_noreply＠suse.de 03 Apr '10

03 Apr '10

Feature changed by: Stefan Dirsch (sndirsch) Feature #306476, revision 19 Title: Install boot entry configurable in kernel git file - openSUSE-11.2: Rejected by (sndirsch) + openSUSE-11.2: Rejected by Stefan Dirsch (sndirsch) reject date: 2010-01-10 10:12:41 reject reason: Obviously this has not been implemented for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Thomas Renninger (trenn) Developer: (Novell) Developer: (Novell) Description: Provide a file in the kernel git which describes an installation boot entry including: - help/description - specific boot parameters - active on which arch The installation image (e.g. DVD) will then provide these specific boot entries to make it easy for: - kernel developers to add critical boot parameters required for specific HW for booting - users by providing a meaningful help at boot loader start up Currently most important settings that are coming to my mind are: - apic=bigsmp (for i386 machines with a lot cores might require that) - disable Kernel Mode Settings -> disable kernel graphics parts which won't work on all HW if set by default soon The idea originally comes from Bernhard Walle. Steffen and myself discussed that already and agreed that it makes sense to do that. On longterm it would be great to get rid of the "Failsafe" Yast boot loader functionality. This would not be necessary anymore then. This currently totally useless and outdated anyway. With the new approach, soon as one successfully booted an entry from the installation image, these boot options will be the default forever (or manually adjusted). Discussion: #1: Stefan Dirsch (sndirsch) (2009-06-22 10:09:05) I think the X' team' would like to get involved here WRT KMS. Also I believe we still want to have a possibility to detect that the user wants to start the Xserver from installation (usually fbdev driver) instead of the apparently broken native X driver. This was boot param 'x11failsafe' in the past. #2: Thomas Renninger (trenn) (2009-06-22 14:27:39) Yeah, in this case we probably need some advise from the X guys which boot params have to be passed, eventually other extra quirks are needed for KMS, no idea. But in general the responsibility and possibilty to generate/modify extra boot entries and with them passing extra kernel boot parameters and a description when to use them should rely in the kernel teams hands and thus the config file should lie in the kernel repo. Coolo, can you set this fate entry a project manager state, so that we can finally work on that at some time, thanks. #3: Stefan Dirsch (sndirsch) (2009-06-22 14:52:39) Probably the modeset option needs to be used for all relevant KMS capable DRM modules, like i915, radeon. Possibily also radeonhd (still to be implemented) and nouveau (in case it's installed, we don't ship it). So something like this: i915.modeset=0, radeon.modeset=0, radeonhd. modeset=0, nouveau.modeset=0. #5: Andreas Jaeger (a_jaeger) (2009-07-10 11:47:39) I'm a bit confused what you want to do here. What advantage will this bring us? #6: Andreas Jaeger (a_jaeger) (2009-07-14 15:13:04) (reply to #5) Just talked with Thomas: The idea is to safe the information about kernel-parameters as part of the kernel package and let the installation get this information from there - instead of hardcoding it in the installation workflow. Also the kernel would provide different options that the developers think make sense. #8: Michal Marek (michal-m) (2009-09-04 13:05:51) Adding such file(s) to git and packaging them in the binary rpms is not a problem, I think this is mainly a feature for installation images build to get the configuration from the kernels and use it when generating the menu. Steffen, what do you think? #9: Thomas Renninger (trenn) (2009-09-04 13:47:04) Yep. Steffen and I already fiddled out a config file format. It's mainly on me to add an example file to our git repo. Steffen then can implement the installation image part. I just did not found the time (and wanted to poke graphics guys about sane KMS kernel boot params to provide which should be most important for 11.2). #10: Stefan Dirsch (sndirsch) (2009-12-12 07:14:04) About KMS integration for openSUSE 11.3 and SLE11-SP1, please see Bug #560438. + #11: Stefan Dirsch (sndirsch) (2010-04-03 11:47:31) + Not sure if this one is still interesting for X developers. KMS + integration is now fully done in SLE11-SP1 and openSUSE 11.3. -- openSUSE Feature: https://features.opensuse.org/306476

1 0