April 2017 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 319035] Make YaST (incl. modules available in GNOME Software
by fate_noreply＠suse.de 22 Dec '19

22 Dec '19

Feature added by: Dominique Leuenberger (dimstar) Feature #319035, revision 1 Title: Make YaST (incl. modules available in GNOME Software openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Dominique Leuenberger (dimstar) Partner organization: openSUSE.org Description: GNOME Software is an other way of handling installations. Instead of being package centric, it is application centric. An application is being represented by means of an appdata.xml file in it's setup (installed to /usr/share/appdata), then a metadata parser extracts this info and produces 'AppStream' metadata (to be consumed by software centers) In order to make extensions/plugins to applications discoverable, a package can add a metainfo.xml file to the same location and have itself listed as an extension/addon to the application. For YaST, this results in: - an appdata.xml file being provided together with YaST.desktop (done) - For all yast modules to install a metainfo.xml file, describin their extensive nature to yast. -- openSUSE Feature: https://features.opensuse.org/319035

1 4

[New: openFATE 318458] Reading user process memory
by fate_noreply＠suse.de 26 Apr '19

26 Apr '19

Feature added by: Sławomir Lach (Lachu) Feature #318458, revision 1 Title: Reading user process memory Requested by: Sławomir Lach (lachu) Partner organization: openSUSE.org Description: Reading user's process memory or writting to it is very bad think. Malware can stole passwords or change settings of application. I have two idea about solving this issue: 1. Dissallow to debug(reading/writting memory) process placed in /bin, /sbin, /usr/bin, /usr/sbin 2. Dissallow to debug(reading/writting memory) process of file not belonging to user, who execute file. -- openSUSE Feature: https://features.opensuse.org/318458

1 1

[New: openFATE 323318] OBS WEBUI: User role selector on task list
by fate_noreply＠suse.de 21 Feb '19

21 Feb '19

Feature added by: Adrian Schröter (adrianSuSE) Feature #323318, revision 1 Title: OBS WEBUI: User role selector on task list Buildservice: New Milestone: 2.9 Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Requested by: Ruediger Oertel (oertel) Partner organization: openSUSE.org Description: OBS Webui shall support filtering open tasks for a user by his workflow role there. The role is defined via a group for now. Details for planing can be found in this trello card: https://trello.com/c/H0fZCfFi/319-allow-filtering-of-requests-reviews-and-b… This request is just for tracking and connecting involved people. -- openSUSE Feature: https://features.opensuse.org/323318

1 3

[New: openFATE 320873] Remove copy_to_system from control.xml and AutoYaST
by fate_noreply＠suse.de 20 Feb '19

20 Feb '19

Feature added by: Ancor Gonzalez Sosa (ancorgs) Feature #320873, revision 1 Title: Remove copy_to_system from control.xml and AutoYaST openSUSE Distribution: New Priority Requester: Desirable Requested by: Ancor Gonzalez Sosa (ancorgs) Partner organization: openSUSE.org Description: In 2006 an generic mechanism to (silently) copy files from an existing filesystem to the system being installed was introduced in YaST as part of the implementation of two different features (fate#120103 and fate#300421). Any information to the user about the files being copied was intentionally left out (see comments in #300421). In 2008 the list of files was moved to control.xml and the AutoYaST profile (fate#305019). But the documentation and schema for the AutoYaST profile were never updated to reflect the change. We have received several bug reports and Fate entries about it since then, from incomplete lists of files (bug#956515, bug#956976) to non-intuitive or incomplete behavior (fate#319624, bug#956976) and everything in between. Starting with yast2-installation 3.1.187 and yast2-users 3.1.49, the original features do not longer need to use "copy_to_system" and the corresponding section is now empty in the control files of both SLE and openSUSE. I would like to completely drop the "copy_to_system" feature since it's obscure (everything happen behind user's back), problematic (quite some bug reports), not necessary (not longer needed by the originating features) and poorly documented (not even in the AutoYaST schema). -- openSUSE Feature: https://features.opensuse.org/320873

1 12

[New: openFATE 310701] package byobu in an opensuse repository
by fate_noreply＠suse.de 28 Jan '19

28 Jan '19

Feature added by: Divan Santana (divansantana7) Feature #310701, revision 1 Title: package byobu in an opensuse repository openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Divan Santana (divansantana7) Description: Would be great if anyone using opensuse could zypper in byobu . Unfortunately it's not in any opensuse repo despite it being a great tool for administrating linux servers. I'm quite surprised this isn't already available for opensuse. Would be a nice addition for 11.4 -- openSUSE Feature: https://features.opensuse.org/310701

1 7

[New: openFATE 322073] yast should not override ip_forward setting
by fate_noreply＠suse.de 16 Jan '19

16 Jan '19

Feature added by: Bernhard Wiedemann (bmwiedemann) Feature #322073, revision 1 Title: yast should not override ip_forward setting openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Bernhard Wiedemann (bmwiedemann) Partner organization: openSUSE.org Description: someone thought, this bugfix qualifies as feature: http://bugzilla.suse.com/show_bug.cgi?id=1010036 Test Case: echo net.ipv4.ip_forward = 1 > /etc/sysctl.d/50-ip-forward.conf sysctl --system 2>/dev/null |grep "ip_forward = " net.ipv4.ip_forward = 1 Use Case: as a system administrator I want to override ip_forward setting in an easily scripted manner by writing my preferred values to /etc/sysctl.d/50-ip-forward.conf Business case (Partner benefit): openSUSE.org: manual configuration is deprecated and yast overriding admin's settings should be a thing of the past. -- openSUSE Feature: https://features.opensuse.org/322073

1 3

[New: openFATE 308445] Tor is not working out of box
by fate_noreply＠suse.de 29 Nov '18

29 Nov '18

Feature added by: Algimantas B (algyzas) Feature #308445, revision 1 Title: Tor is not working out of box Package Wishlist: Unconfirmed Priority Requester: Neutral Requested by: Algimantas B (algyzas) Description: Let's say I installed tor, it is came alone, without privoxy. One should download it manually. And then if I try :~> screen torify konqueror hich: no tsocks in (/home/senis/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:.) /usr/bin/torify: Can't find tsocks in PATH. Perhaps you haven't installed it? [screen is terminating] There is a guide http://en.opensuse.org/Privoxy_tor_squid how to setup it, I'll try it, but in some other distributions it works out of box like this. -- openSUSE Feature: https://features.opensuse.org/308445

1 1

[New: openFATE 309627] Enhance 'Safely Remove' to spin-down and power-off usb HDDs
by fate_noreply＠suse.de 07 Nov '18

07 Nov '18

Feature added by: Pete Clayson (Olmy) Feature #309627, revision 1 Title: Enhance 'Safely Remove' to spin-down and power-off usb HDDs openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Pete Clayson (olmy) Description: 'Safely remove' should (as far as possible) allow for genuine safe removal of all media. Under certain other OSs, the 'safely remove' option on usb devices will... 1/ On usb pen drive with a power/activity led, switch it off (trivial nicety, but reassuring). 2/ On usb HDDs, spin down the disk and power off. This seems more important. There is some discussion about this, for example, http://elliotli.blogspot.com/2009/01/safely-remove-usb-hard-drive-in-linux.… (http://elliotli.blogspot.com/2009/01/safely-remove-usb-hard-drive-in-linux.…) I know that the latest version of Ubuntu does this and there is a script offered in the above link. However, the script, as it stands and run on my installation of OpenSUSE, does not seem to work (in the same way as WinXP or Ubuntu, anyway - my WD600D036 disk does not power off) despite the positive messages in verbose mode. Perhaps this is the CONFIG_USB_SUSPEND option mentioned? -- openSUSE Feature: https://features.opensuse.org/309627

1 6

[New: openFATE 320385] Let Zypper know the version number of openSUSE
by fate_noreply＠suse.de 19 Sep '18

19 Sep '18

Feature added by: Philipp Bielefeldt (pbiel) Feature #320385, revision 1 Title: Let Zypper know the version number of openSUSE openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Philipp Bielefeldt (pbiel) Partner organization: openSUSE.org Description: All repo names in openSUSE are structured to have the version number/name in it, such as http://download.opensuse.org/repositories/science/ openSUSE_Leap_42.1 / (for 42.1); I do a lot of repo handling via bash scripts and I find myself over and over again telling someone: "Here, this is a script to install all the software you'll need right nowâ¦ But you have to specify your version string in the repo's name before running it" â 50% chance I will get asked "What do you mean? Where shall I put what?!" I think it was more convenient and less error prone if zypper commands yould use a variable such as osVersion that can be put to replace the string. On openSUSE Leap 42.1 zypper ar -f http://download.opensuse.org/repositories/science/$osVersion/ "Science" would than automatically change to zypper ar -f http://download.opensuse.org/repositories/science/openSUSE_Leap_42.1/ "Science" and so forthâ¦ Business case (Partner benefit): openSUSE.org: This feature would it make easier for admins to write scripts that handle software management/installation on different versions of openSUSE. It would also facilitate writing advice to people on the internet (e.g. the openSUSE wiki) on how to perform certain actions that concern repo management. -- openSUSE Feature: https://features.opensuse.org/320385

1 5

[New: openFATE 314778] Use polkit for YaST privilege management
by fate_noreply＠suse.de 14 Sep '18

14 Sep '18

Feature added by: Dainius Masiliunas (GreatEmerald) Feature #314778, revision 1 Title: Use polkit for YaST privilege management openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Dainius Masiliunas (greatemerald) Partner organization: openSUSE.org Description: At the moment of writing, YaST relies on having root privileges through a graphical sudo in order to view and carry out most tasks. However, there is no reason why simply displaying those tasks should be restricted like that. YaST should always be started with user privileges, and only ask for additional privileges when they are truly needed - when the selected tasks should be carried out. This can be achieved by using polkit. It also brings a lot of other benefits. Use Case: Users who do not have access to the root password currently also do not have access to a lot of functionality that does not actually require the password, such as searching for package information. Users that do administrative tasks are also subjecting the system to possible security risks by running YaST with full root privileges. Using polkit would increase security and prevent potential user mistakes. Business case (Partner benefit): openSUSE.org: Using polkit, the graphical interface of YaST would always be run as a normal user. That means that code that should not have elevated privileges - like GUI - would not run with them. More could be done without needing to enter the root password - package information query, printer setup, device information overview, reviewing network configuration options etc. In a restrictive environment, the system administrator could set certain tasks to be available for use by regular users, or to allow certain tasks to be run by certain users only. The authentication screen would provide more information about what tasks are about to be carried out for increased security. For instance, if a custom YaST module requests permission to modify the partition table, while it claims to only set up the date and time, it would be clear to the user that the module is either fraudulent or is malfunctioning. In order to not have to authenticate after every single change a module wishes to do, a global queue for the changes could be created (like what is shown by the /etc/sysconfig editor once its changes are to be applied). Once the global "apply" button is pressed, the user would be informed of what actions will be carried out and what privileges will be given to carry them out. Then, once the user confirms that by supplying a password, all the changes are applied. -- openSUSE Feature: https://features.opensuse.org/314778

1 8