May 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306373] revival of openCA
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Stephan Kulow (coolo) Feature #306373, revision 1, last change by Title: revival of openCA openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Hans Witvliet (digi_hans) Description: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060425 SUSE/1.5.0.3-7 Firefox/1.5.0.3 Any chance of reviving OpenCA? In the security manuals, chapter x509, it says that the yast-module for maintaing certificates is nice for small set-up's, but not intented for large roll-outs. OpenCA seems to be right for that job, with (poosible) seperate CA, RA, OSCP, support for smartcards and LDAP, mysql. If i'm not mistaken, Adrian maintained some time ago an old version of OpenCA for openSuSE_10.3. Hence my question: is it possible to re-create it for the 1.0.2 (ten-ten) version of openCA, preferably for openSUSE_11.1 and SLES-11 ? It seems that current verion of OpenCA does build on older versions of openSUSE, but fails to compile on 11.1. (not yet tried on sles11, but expect same results) Relations: - revival of openCA (novell/bugzilla/id: 491024) https://bugzilla.novell.com/show_bug.cgi?id=491024 Discussion: #1: Stephan Kulow (coolo) (2009-04-08 09:11:05) if you can't even get it to compile, it doesn't seem to be that well maintained. So I would think it's not good to rely on security of it. #2: Hans Witvliet (digi_hans) (2009-04-08 16:19:04) To put in perspective... I couldn't complete a compile of the latest version on 11.1. openca offers binaries for fedora, centos, ubuntu and open slowaris. I just tried it on 32/64-bit versions of 11.1, I can try it aagain on older versions. Allthough i just upgraded our whole environment, using our install server with xen farm wouldn't take too long. At work i've got a tough job keeping all the noses point to one direction. But it would be hard to defend sticking with open/sles with considerable effort if it compiles flawless (I kow: seeing is believing..) with others. It seems that OpenCA is the only opensource product in this class, comparing with CASA, yaST, tinyCA, pyCA that are only intended for small scale deployment. And for this particular assigment was specifically asked to evaluate OpenCA, regardless of the environment it runs in, though my first choice would be a sles11-cluster and secondly an open-11.1 cluster. #3: Stephan Kulow (coolo) (2009-04-08 23:58:21) you have two options: a) the openSUSE way: you're free to maintain it in openSUSE:Factory:Contrib (see en.opensuse.org/Contrib) b) the SLES way: you convince your presales contact person that there is no way around The "file an enhancement bug against openSUSE to get a SLES feature" does not work. #4: Hans Witvliet (digi_hans) (2009-04-09 15:22:41) Sorry, if i gave you the wrong impression. imho, openca looks great (from the docu and the live-version) It used to be included 10.0 - 10.3 with the distro itself, and later on it became also available on the OBS (Adrian). I presume that if you got someone who has spent some time before on it, it would be the first one to humbly ask to have a look again, instead of re-inventing the wheel. Personnaly, i work on the R&D department, only doing prototypes and prove-of-concepts and i am happy using openSuSE. Our production department however is using the official SLES-9 and now SLES-10 version. a) So if there is a version on the OBS for open_11.1 i would be happy. b) If it could be incorporated in the list of packages for SLE it would make you happy (sales) c) If the OBS could hold versions for 11.1 and SLE, you would be happier, (sales but no additional packages to officially maintain) Final word about the code: Yes, it is _old_ code, but the only thing that comes close with regards with its features, is the code that comes from AOL: http://www.redhat.com/certificate_system/ And i'm neither eager to switch to rh/fc/ct, nor to suggest a re-write of the 10MB from openCA. Hence my req to revive it on the OBS, anyone would benefit. Or do you have plans to "adopt" the above mentioned GPL-ed java code ;=) -- openSUSE Feature: https://features.opensuse.org/306373

1 3

[openFATE 307257] Default kdesu to use sudo and not su
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Bill P (google01103) Feature #307257, revision 1 Title: Default kdesu to use sudo and not su openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Bill P (google01103) Description: as described in the article http://www.benkevan.com/blog/default-kdesu-to-use-sudo-and-not-su/ -- openSUSE Feature: https://features.opensuse.org/307257

1 1

[openFATE 306779] a better support for Wlan driver
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Claus Rebler (Zunami) Feature #306779, revision 1 Title: a better support for Wlan driver openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Claus Rebler (zunami) Description: i have always a problem to install wlan drivers on opensuse i hab 1 acer laptop 1 hp laptop 1 asus latop and always the sam problem. the system have not the divers. i must after the system installation (opensuse 11.1) over again to install the driver. and then i must hope to find my network (next problem). when i install kubuntu i have no this problem. please make a easy or better wlan support. and after the installtion the system must be run -- openSUSE Feature: https://features.opensuse.org/306779

1 2

[openFATE 307171] Use Device Manager instead of the standard Device Notifier
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Robert Erne (Jeremay) Feature #307171, revision 1 Title: Use Device Manager instead of the standard Device Notifier openFATE: Unconfirmed Priority Requester: Desirable Requested by: Robert Erne (jeremay) Description: I think Device Manager has a lot of interesting and nice features. It`s rather stable and makes a good impression. -- openSUSE Feature: https://features.opensuse.org/307171

1 3

[openFATE 306949] Clearing Documents List from GNOME Slab Menu
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Eric Yeoh (yeoheric) Feature #306949, revision 1 Title: Clearing Documents List from GNOME Slab Menu openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Eric Yeoh (yeoheric) Description: There is no feature in openSUSE or SLED 11 to clear recently used documents under the GNOME desktop using the Slab Menu. This presents a possible privacy issue. If there is a way to clear via context-menu will be great. -- openSUSE Feature: https://features.opensuse.org/306949

1 1

[openFATE 306953] yast-GRUB: graphic
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: manuel m (manuel_songokuh) Feature #306953, revision 1 Title: yast-GRUB: graphic openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: manuel m (manuel_songokuh) Description: hello.. i want new grub from yast! i want not change grub from yast but new graphic and little change..i will send you my pictures..but my languange is italian ok? this picture is default of grub from yast opensuse 11.1 64bit (view-source://http//digilander.libero.it/jaoken2/grub-installazione.png) http://digilander.libero.it/jaoken2/grub-installazione.png (view-source://http//digilander.libero.it/jaoken2/grub-installazione.png) this is my idea for new graphic: http://digilander.libero.it/jaoken2/grub-presentaz.png (view-source://http//digilander.libero.it/jaoken2/grub-presentaz.png) this reason..it's for not-espert or neo-user, for not panic during install grub.. now i do an example picture for step-step: http://digilander.libero.it/jaoken2/1-step.png http://digilander.libero.it/jaoken2/2-step.png http://digilander.libero.it/jaoken2/3-step.png http://digilander.libero.it/jaoken2/4-step.png http://digilander.libero.it/jaoken2/5-step.png what do you think about pictures? -- openSUSE Feature: https://features.opensuse.org/306953

1 6

[openFATE 306971] keep the previous kernel after update process
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Ioan Vancea (IonutVan) Feature #306971, revision 1 Title: keep the previous kernel after update process openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Ioan Vancea (ionutvan) Description: I would like to see that "feature" implemented default because after kernel updates many times there were a lot of issues and to change back to the previous version is not very easy for a novice user. For example after a kernel update I have problems with encrypted filesystems, or the sound stopped to work, .... Yes, I know that it is possible to change the behaviour to keep the old kernel but why not to be default. -- openSUSE Feature: https://features.opensuse.org/306971

1 5

[openFATE 307114] Add "Upgradable" and "Upgradable (upstream)" filters to YaST Software Management
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Alexander shaduri (alex_sh) Feature #307114, revision 1 Title: Add "Upgradable" and "Upgradable (upstream)" filters to YaST Software Management openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Alexander shaduri (alex_sh) Description: I used to use Synaptic+apt on openSUSE 10.3. Since upgrading to 11.1 I switched to using YaST for my package management needs. I follow some Build Service repositories, so frequently there are packages to be upgraded. Unfortunately, compared to Synaptic, YaST's package upgrade mechanisms are way too unusable. Synaptic had two simple but very useful features - "Upgradable" and "Upgradable (upstream)" filters. "Upgradable" shows all the packages that have newer versions available. "Upgradable (upstream)" shows packages which have newer upstream versions (that is, it won't show "example-1.0.0-1" => "example-1.0.0-3", but will show "example-1.0.0-1" => "example-1.0.1-1"). This is important since the release version is usually changed on every recompile, and filtering the upgrades by the actual "new version" is more handy. Without these filters I have to basically scroll through ALL installed packages, looking for the "blue-versioned" ones. This is making it simply unusable. Also, adding to the unusability is the "Installed (Available)" column. The last components of the available versions are almost always hidden unless I resize it to a quite large size, and even then, it's very hard to read. Compare it to the following (both versions can be seen easily): http://www.freesoftwaremagazine.com/files/www.freesoftwaremagazine.com/node… Steps to Reproduce: 1. Subscribe to a couple of heavily-populated repositories from Build Service. 2. Try browsing through upgradable packages. openSUSE 11.1 x86_64, YaST QT interface. See also: https://bugzilla.novell.com/show_bug.cgi?id=524000 -- openSUSE Feature: https://features.opensuse.org/307114

1 2

[openFATE 306957] Allow ymp (one-click installs) to set the repo priority
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Sven Burmeister (rabauke) Feature #306957, revision 1 Title: Allow ymp (one-click installs) to set the repo priority openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Sven Burmeister (rabauke) Description: When people use one-click installs to e.g. install or update KDE4, they get a lot of dependency issues because the buildservice repo does not have the right priority, i.e. higher than e.g. the oss or update repository. One-click installs only make sense if they are easy to use and facilitate the process of adding a repo. Having to open YaST software management to adjust the priority manually and re-running the update afterwards is not "one-click". Setting-up a repo includes setting the correct priority. The problem with ymp setting repos' priority is that those are relative to the repos already installed. The best solution would be to read the other repos' priority and suggest priorities for the new repos accordingly. The user can still change them in the one-click GUI. The minimal solution would be to just allow the user to set the repo's priority via the one-click GUI. -- openSUSE Feature: https://features.opensuse.org/306957

1 4

[openFATE 306321] disk id change in fstab
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Jean-Daniel Dodin (jdd_sysop) Feature #306321, revision 1, last change by Title: disk id change in fstab openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Jean-Daniel Dodin (jdd_sysop) Description: "That basic request is that one or more simple tools be provided to allow a fstab to be automatically converted from /dev/sdaX nomenclature to one of the preferred methods." In other words, its now necessary to use YaST partitionner to change the fstab entry from /dev/sdx to the veeeeeeeeery long disk identification. This is very scary and is now nearly mandatory for updates. So it would be important to have some utility to make only this change in fstab and no other. If possible add the choice to use and set on the fly disk ID. -- openSUSE Feature: https://features.opensuse.org/306321

1 8