Ok this is just an example that hit me today, so I wonder what is the opinion here, please do not concentrate on the problem at hand but on the general problem it highlights (user experience on server).
In a headless F20 if you "yum install firefox" you get a broken application when you want to run it through an ssh session (I ssh -Y in my VM).
I think this is a reasonably common mode of operation, and yet installing firefox does not bring in all the dependencies it needs to actually work.
The classic dependency it misses that I know about is xorg-x11-xauth, however in F20 firefox apparently also misses fonts and will show an unintelligible crash report dialog (unintelligible because there are no fonts).
I think a good server experience will require that yum install firefox on a headless system installs all required packages to make it work, is this something we need to take care of going forward ?
Apparently there is some dispute about who owns the bug, but I wasn't able to find out where, on #fedora-devel I was told it was in a bug that has probably been closed w/o resolving the issue ...
Simo.
On 10/31/2013 09:39 AM, Simo Sorce wrote:
I think a good server experience will require that yum install firefox on a headless system installs all required packages to make it work, is this something we need to take care of going forward ?
So stepping back, the use-case being proposed here is:
'Users of Fedora server will be able to install - at their option - software with graphical interfaces, and they will be able to successfully use these graphical interfaces via trusted X-forwarding (ssh -Y).'
I think that this doesn't work for the particular example you gave is a bug; maybe there's a problem with the package.
From my perspective though, the use case is a good one, particularly if
we're trying to make our server accessible to Microsofty admin types with minimal Linux experience. To use myself as an example: I suck as a sysadmin, but I have needed this in the past (particularly to use system-config-firewall on a remote system because I suck at editing iptables config by hand!)
The only concern that the more technical folks like you could address here - there are security implications on installing the whole set of stacks/libraries necessary to get a GUI app running on a server, right? If so,
(1) Do we care, or is it the user opting in to this that needs to take responsibiltiy.
(2) Do we have any kind of mechanism we can use to help account for the potential damage? (E.g, just a stupid random idea, but, if the user is just going in for a one-time / infrequent iptables config, have the GUI stuff set an expiration date at which time it gets removed to lessen the risk of having it installed?)
~m
On Thu, 2013-10-31 at 09:53 -0400, Máirín Duffy wrote:
On 10/31/2013 09:39 AM, Simo Sorce wrote:
I think a good server experience will require that yum install firefox on a headless system installs all required packages to make it work, is this something we need to take care of going forward ?
So stepping back, the use-case being proposed here is:
'Users of Fedora server will be able to install - at their option - software with graphical interfaces, and they will be able to successfully use these graphical interfaces via trusted X-forwarding (ssh -Y).'
I think that this doesn't work for the particular example you gave is a bug; maybe there's a problem with the package.
Yeah I filed https://bugzilla.redhat.com/show_bug.cgi?id=1025331 it seem that doing something like: yum install liberation-* which installs at least one font unbreaks firefox.
From my perspective though, the use case is a good one, particularly if we're trying to make our server accessible to Microsofty admin types with minimal Linux experience. To use myself as an example: I suck as a sysadmin, but I have needed this in the past (particularly to use system-config-firewall on a remote system because I suck at editing iptables config by hand!)
Yes my concern is that we allow to install a package that is commonly used exported and it just doesn't work. The desktop people don't see nor will have high priority for this type of bugs, but it really breaks the user experience for headless systems, that only need occasionally a graphical interface, but when you need it is a blocking issue.
The only concern that the more technical folks like you could address here - there are security implications on installing the whole set of stacks/libraries necessary to get a GUI app running on a server, right?
In fact I am not installing the whole thing, just the needed packages. But mostly for space and cpu/efficiency concerns, not necessarily for security reasons.
If so,
(1) Do we care, or is it the user opting in to this that needs to take responsibiltiy.
Do we care about giving a good experience when the admin is forced to use on of this packages for whatever reason ?
(2) Do we have any kind of mechanism we can use to help account for the potential damage? (E.g, just a stupid random idea, but, if the user is just going in for a one-time / infrequent iptables config, have the GUI stuff set an expiration date at which time it gets removed to lessen the risk of having it installed?)
I do not think automatically removing packages is a good idea. The fact the package is installed is not itself a security issue. If it were to start automatically daemons or jobs that's something else of course. Bu that is not that common for GUI applications, yet.
Simo.
Le 31/10/2013 15:11, Simo Sorce a écrit :
Yes my concern is that we allow to install a package that is commonly used exported and it just doesn't work. The desktop people don't see nor will have high priority for this type of bugs, but it really breaks the user experience for headless systems, that only need occasionally a graphical interface, but when you need it is a blocking issue.
Another example of such bad user experience: https://bugzilla.redhat.com/982620 Remote applications (un)usability (AppMenu)
Remi.
On Thu, 2013-10-31 at 15:29 +0100, Remi Collet wrote:
Le 31/10/2013 15:11, Simo Sorce a écrit :
Yes my concern is that we allow to install a package that is commonly used exported and it just doesn't work. The desktop people don't see nor will have high priority for this type of bugs, but it really breaks the user experience for headless systems, that only need occasionally a graphical interface, but when you need it is a blocking issue.
Another example of such bad user experience: https://bugzilla.redhat.com/982620 Remote applications (un)usability (AppMenu)
To be honest I am less concerned about something like gedit, I do not expect an admin to run it from a headless server, but yeah it would be nice if it didn't break unnecessarily.
Simo.
Le 31/10/2013 15:37, Simo Sorce a écrit :
Another example of such bad user experience: https://bugzilla.redhat.com/982620 Remote applications (un)usability (AppMenu)
To be honest I am less concerned about something like gedit, I do not expect an admin to run it from a headless server, but yeah it would be nice if it didn't break unnecessarily.
This bug report is not really about gedit, but about "all" gnome app moving options to the AppMenu which is not available remotely.
Remi.
Le 31/10/2013 15:37, Simo Sorce a écrit :
Another example of such bad user experience: https://bugzilla.redhat.com/982620 Remote applications (un)usability (AppMenu)
To be honest I am less concerned about something like gedit, I do not expect an admin to run it from a headless server, but yeah it would be nice if it didn't break unnecessarily.
This bug report is not really about gedit (only an example), but about "all" gnome app moving options to the AppMenu which is not available remotely.
Remi.
On 10/31/2013 10:37 AM, Simo Sorce wrote:
To be honest I am less concerned about something like gedit, I do not expect an admin to run it from a headless server, but yeah it would be nice if it didn't break unnecessarily.
Should we define a list of apps that would be practical to want to use over ssh -Y?
~m
On Thu, 2013-10-31 at 10:55 -0400, Máirín Duffy wrote:
On 10/31/2013 10:37 AM, Simo Sorce wrote:
To be honest I am less concerned about something like gedit, I do not expect an admin to run it from a headless server, but yeah it would be nice if it didn't break unnecessarily.
Should we define a list of apps that would be practical to want to use over ssh -Y?
I think we could make a list of apps we think should absolutely work, and try to QA them at least once before release to make sure they keep working, yes.
Simo.
Simo Sorce (simo@redhat.com) said:
Ok this is just an example that hit me today, so I wonder what is the opinion here, please do not concentrate on the problem at hand but on the general problem it highlights (user experience on server).
In a headless F20 if you "yum install firefox" you get a broken application when you want to run it through an ssh session (I ssh -Y in my VM).
I think this is a reasonably common mode of operation, and yet installing firefox does not bring in all the dependencies it needs to actually work.
The font problem is more or less like this:
- The set of fonts required by your app is the union of: - a font for the charset of your current locale - a font for the charset of other locales in use on the system - a font for the charset of any content you may read
Furthermore, the only automatic font metadata we have is the automated reading of font charset coverage that adds (font:lang=<foo>) provides to fonts if there is charset coverage.
This: - can lead to suboptimal provides/false positives - has no mechanism for picking the *default* font for a locale
Hence, the current best practices for running X apps remotely is "if you want to run X apps remotely, install the @fonts group", which will include default fonts for maximal language coverage.
It's not great in that it can't be done with strict RPM dependencies, but trying to do so would require hardcoding default metadata in multiple places (certainly wouldn't want to do each application),
Bill
On Thu, 2013-10-31 at 14:50 -0400, Bill Nottingham wrote:
Simo Sorce (simo@redhat.com) said:
Ok this is just an example that hit me today, so I wonder what is the opinion here, please do not concentrate on the problem at hand but on the general problem it highlights (user experience on server).
In a headless F20 if you "yum install firefox" you get a broken application when you want to run it through an ssh session (I ssh -Y in my VM).
I think this is a reasonably common mode of operation, and yet installing firefox does not bring in all the dependencies it needs to actually work.
The font problem is more or less like this:
- The set of fonts required by your app is the union of:
- a font for the charset of your current locale
- a font for the charset of other locales in use on the system
- a font for the charset of any content you may read
Furthermore, the only automatic font metadata we have is the automated reading of font charset coverage that adds (font:lang=<foo>) provides to fonts if there is charset coverage.
This:
- can lead to suboptimal provides/false positives
- has no mechanism for picking the *default* font for a locale
Hence, the current best practices for running X apps remotely is "if you want to run X apps remotely, install the @fonts group", which will include default fonts for maximal language coverage.
It's not great in that it can't be done with strict RPM dependencies, but trying to do so would require hardcoding default metadata in multiple places (certainly wouldn't want to do each application),
Can't we create a Provides: tag and make it a dependency for firefox ?
Then make a package that has a 'reasonable default' of Requires: and make it Provide that tag, different spins may decide to have different packages provide the special tag.
Simo.
Simo Sorce (simo@redhat.com) said:
Can't we create a Provides: tag and make it a dependency for firefox ?
Then make a package that has a 'reasonable default' of Requires: and make it Provide that tag, different spins may decide to have different packages provide the special tag.
I suppose you could have a metapackage that requires the default set of fonts (that matches @fonts), and have it be a requirement of either libX11 or the major toolkits. But having to add the requires per-app would be wrong, IMO.
Bill
On Thu, 2013-10-31 at 15:00 -0400, Bill Nottingham wrote:
Simo Sorce (simo@redhat.com) said:
Can't we create a Provides: tag and make it a dependency for firefox ?
Then make a package that has a 'reasonable default' of Requires: and make it Provide that tag, different spins may decide to have different packages provide the special tag.
I suppose you could have a metapackage that requires the default set of fonts (that matches @fonts), and have it be a requirement of either libX11 or the major toolkits. But having to add the requires per-app would be wrong, IMO.
Well firefox brought in a number of libraries. The library that actually chokes seem to be pango, so perhaps that's the package that should have this metapackage as a dependency ?
Simo.
On Thu, Oct 31, 2013 at 2:53 PM, Máirín Duffy duffy@redhat.com wrote:
On 10/31/2013 09:39 AM, Simo Sorce wrote:
I think a good server experience will require that yum install firefox on a headless system installs all required packages to make it work, is this something we need to take care of going forward ?
So stepping back, the use-case being proposed here is:
'Users of Fedora server will be able to install - at their option - software with graphical interfaces, and they will be able to successfully use these graphical interfaces via trusted X-forwarding (ssh -Y).'
I would stop at the comma; to me (ssh -Y) is an implementation detail, we might be equally satisfied with a RDP server instead. (Especially if, as you suggest, Microsofty admin types are one of the targets. With Wayland we'll be using a bitmap-pushing protocol anyway, won't we? Or is it really critical to tie this functionality to ssh, perhaps to reuse ssh keys for authentication?)
(Speculatively we might instead consider deciding the really useful functionality is available as web applications, not X11 applications, and that we don't really need a X11-based GUI on the server; but that's dependent on actually having done the research on what useful applications exist and are popular, which I haven't done.)
(It seems to me that Firefox is one of the applications that one would _least_ need to run remotely - just run Firefox locally. OTOH Firefox is one of the easier cases nowadays, with the desktop stacks increasingly not taking non-local or non-primary sessions (like (su -) and ssh) into account, as Remi points out.)
The only concern that the more technical folks like you could address here - there are security implications on installing the whole set of stacks/libraries necessary to get a GUI app running on a server, right?
The security implications are non-zero, but decreasing over time.
It used to be useful to minimize the amount of software available on the target system to be reused by the attacker (e.g. not have interpreted languages compilers installed) because the networks were very slow, storage was lacking, and binary compatibility was rare; so pre-installed software was often reused by attackers both to minimize the download time and to make the malware more portable (either making it a shell or perl script, or shipping C source code to be compiled locally).
Nowadays the hardware+OS=ABI diversity is much smaller, the size of malware is frequently measured in megabytes, and they use even more local disk space (which nobody ever notices because a single photo is larger). Malware can therefore easily include whatever is necessary in its installation package instead of relying on the (potentially incompatible) software already installed on the system, so the benefits of not having software installed tend towards zero.
The one case where there still are security implications, and where minimizing the installed software makes sense, are privilege escalation paths: setuid programs, D-Bus servers, daemons.
So, overall, I think it would be well justified to just include xorg-x11-xauth and a basic set of fonts in the default server installation. (Or in "the server installation profile aimed at Windowsy users", providing a "really minimal and headless" profile? I'm inclined to say that storage is cheap and the really minimal profile just isn't needed, and within the context of the Server WG I might be justified in ignoring Matt, who always patiently points out that 200 MB * 10k guests on a SAN starts to get costly :) ) Mirek
On Fri, 2013-11-01 at 00:05 +0100, Miloslav Trmač wrote:
On Thu, Oct 31, 2013 at 2:53 PM, Máirín Duffy duffy@redhat.com wrote:
On 10/31/2013 09:39 AM, Simo Sorce wrote:
I think a good server experience will require that yum install firefox on a headless system installs all required packages to make it work, is this something we need to take care of going forward ?
So stepping back, the use-case being proposed here is:
'Users of Fedora server will be able to install - at their option - software with graphical interfaces, and they will be able to successfully use these graphical interfaces via trusted X-forwarding (ssh -Y).'
I would stop at the comma; to me (ssh -Y) is an implementation detail, we might be equally satisfied with a RDP server instead. (Especially if, as you suggest, Microsofty admin types are one of the targets. With Wayland we'll be using a bitmap-pushing protocol anyway, won't we? Or is it really critical to tie this functionality to ssh, perhaps to reuse ssh keys for authentication?)
(Speculatively we might instead consider deciding the really useful functionality is available as web applications, not X11 applications, and that we don't really need a X11-based GUI on the server; but that's dependent on actually having done the research on what useful applications exist and are popular, which I haven't done.)
(It seems to me that Firefox is one of the applications that one would _least_ need to run remotely - just run Firefox locally. OTOH Firefox is one of the easier cases nowadays, with the desktop stacks increasingly not taking non-local or non-primary sessions (like (su -) and ssh) into account, as Remi points out.)
The only concern that the more technical folks like you could address here - there are security implications on installing the whole set of stacks/libraries necessary to get a GUI app running on a server, right?
The security implications are non-zero, but decreasing over time.
It used to be useful to minimize the amount of software available on the target system to be reused by the attacker (e.g. not have interpreted languages compilers installed) because the networks were very slow, storage was lacking, and binary compatibility was rare; so pre-installed software was often reused by attackers both to minimize the download time and to make the malware more portable (either making it a shell or perl script, or shipping C source code to be compiled locally).
Nowadays the hardware+OS=ABI diversity is much smaller, the size of malware is frequently measured in megabytes, and they use even more local disk space (which nobody ever notices because a single photo is larger). Malware can therefore easily include whatever is necessary in its installation package instead of relying on the (potentially incompatible) software already installed on the system, so the benefits of not having software installed tend towards zero.
The one case where there still are security implications, and where minimizing the installed software makes sense, are privilege escalation paths: setuid programs, D-Bus servers, daemons.
So, overall, I think it would be well justified to just include xorg-x11-xauth and a basic set of fonts in the default server installation. (Or in "the server installation profile aimed at Windowsy users", providing a "really minimal and headless" profile? I'm inclined to say that storage is cheap and the really minimal profile just isn't needed, and within the context of the Server WG I might be justified in ignoring Matt, who always patiently points out that 200 MB * 10k guests on a SAN starts to get costly :) )
200MB x 5 guests is costly on my small SSD too ...
Simo.
On Thu, 2013-10-31 at 15:53 +0100, Remi Collet wrote:
Le 31/10/2013 15:37, Simo Sorce a écrit :
Another example of such bad user experience: https://bugzilla.redhat.com/982620 Remote applications (un)usability (AppMenu)
To be honest I am less concerned about something like gedit, I do not expect an admin to run it from a headless server, but yeah it would be nice if it didn't break unnecessarily.
This bug report is not really about gedit, but about "all" gnome app moving options to the AppMenu which is not available remotely.
On a personal note, I'd really like to be able to disable moving the menu in the gs bar, I find it really unusable if you like me do not work 100% of the time with maximized windows, but rather use very large screen estate and have many windows side by side as well sloppy focus...
The bonus would be to make it possible to export single apps remotely, which is something we'll want to allow no matter what is the protocol that will be used to remote applications.
Simo.
server@lists.fedoraproject.org
-
Bill Nottingham -
Miloslav Trmač -
Máirín Duffy -
Remi Collet -
Remi Collet -
Simo Sorce