Even if you’ve been to DevConf personally, you surely missed a lot of very interesting talks and workshops. All the videos are now available. Here are the Fedora related ones:
https://www.youtube.com/playlist?list=PLU1vS0speL2YytY0-1oxuNWXmfd1BHSd6
And here is the full list:
https://www.youtube.com/playlist?list=PLjT7F8YwQhr-Ox8LZY8VFrZHFkApOduBi
Enjoy!
I have just discovered GnomeOSTree (I’ve heard about it before, but never tried it). It allows you to run an absolutely fresh version of GNOME (checked out from git the very day) in a virtual machine. This is perfect for
I’ve just played with it for 10 minutes, so I might be missing a lot of things, but this seems to be a very useful tool for anyone testing and reporting GNOME bugs. It’s extremely easy to set up, you just download a VM disk image and import it into virt-manager. Later you can update it from inside the system. Try it!
In this blogpost I’ll describe how to run graphical applications under a different user account in your current desktop session (i.e. without fast user switching). It involves some fiddling with the system configuration, this is not intended for general users without advanced system knowledge. The instructions are created for Fedora 18.
Everything mentioned here was discovered through a trial-and-error approach, I don’t have any expertise in this area. Some of the advice might not be fully correct. I have talked to a few qualified people and I was told that Linux doesn’t support this properly and some applications might display some glitches or not work at all. Consider this a best-effort solution – it might work perfectly for some applications, but you can’t expect it to work in general.
In my setup I have a regular user account kparal and also a second user account gamer that I use for several purposes:
But using the second user account is sometimes also inconvenient:
Over the weekend I installed Steam. Obviously I run it under the gamer account. Not just because of performance, but also because my trust in Steam is far from being 100%. It downloads lots of external binaries and executes them. I trust Valve they are careful to not have any security incident (e.g. malware added to some of their game updates), they certainly have some security checks and policies, but how reliable are those? Does Steam executes everything inside some sandbox? I don’t know and honestly, running Steam (and dozens of third-party binaries it executes) in a separate account seems like a reasonable trade-off.
When I tried to buy a game in Steam, I needed to log in to my Moneybookers account. But my financial passwords usually consists of 20 random characters and are safely stored in a password manager in the kparal session. I got very annoyed at this point. The string is too long to remember, I was offended by the idea to write it down (what do we have technology for if I need to use paper?) and I didn’t really want to save it in a plain text file on disk. Call it a whim. So how do I transfer it? Why on earth can’t I just run steam under the gamer account inside my kparal session and copy and paste it? Windows can do it!
Well, it turns out Linux can do this too, more or less, but it needs a few tweaks. After that you can run any application under a different user account inside your desktop session. Let’s see how.
If you log in using su and run a sample graphical application, it should work out of the box:
kparal@kraken ~ $ su - gamer -c gcalctool Password: ** (gcalctool:3969): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ** (gcalctool:3969): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly. (repeated many times)
There are some accessibility bus warnings, but I haven’t seen any loss of functionality, so I consider them mostly harmless. The dconf errors are arguably a bug and you might lose some functionality because of that – application settings might not be loaded nor saved. If you see these errors, you should unset XDG_RUNTIME_DIR variable first:
kparal@kraken ~ $ su - gamer Password: gamer@kraken ~ $ unset XDG_RUNTIME_DIR gamer@kraken ~ $ gcalctool ** (gcalctool:3969): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
At this point most of your graphical applications should work just fine (the only problem I’ve found is that the global GNOME menu doesn’t work with them). Some of their functionality can be lost however, especially if the application tries to communicate over D-Bus with other processes. According to information I gathered, you might improve the situation in certain cases if you run the application using dbus-launch:
gamer@kraken ~ $ dbus-launch your-application
I haven’t yet seen any application where this would be required, so I can’t provide any more details. Basically if you see any errors regarding D-Bus, you can expect some loss of functionality. But often you might not care, it depends on what you need to achieve with that particular application.
I like to use sudo instead of su, because it caches your password and it can be even configured for password-less login. However the approach is not so straightforward here and requires more tweaking. Only follow this section if su doesn’t suit your needs.
In the basic workflow, this is what you will see using sudo command:
kparal@kraken ~ $ sudo -i -u gamer gcalctool No protocol specified ** (gcalctool:5113): WARNING **: Could not open X display No protocol specified (gcalctool:5113): Gtk-WARNING **: cannot open display: :0
This is because your X server permissions do not allow anyone else to connect to it (IIUIC):
kparal@kraken ~ $ xhost access control enabled, only authorized clients can connect SI:localuser:kparal
If you want to use sudo instead of su, you need to allow gamer to display the window in your session. Like this:
kparal@kraken ~ $ xhost +si:localuser:gamer localuser:gamer being added to access control list kparal@kraken ~ $ xhost access control enabled, only authorized clients can connect SI:localuser:gamer SI:localuser:kparal
Now try it again:
kparal@kraken ~ $ sudo -i -u gamer gcalctool
The calculator should appear just fine. The xhost command has to be executed after each session start, so I wanted to add it to ~kparal/.xprofile, but then I found out that Fedora doesn’t source that file. I added it to ~kparal/.profile instead like this:
# allow gamer to display apps on this X server # (don't do that for local non-X and any remote connections) if [ -n "$DISPLAY" -a -z "$SSH_CLIENT" ]; then xhost +si:localuser:gamer fi
I now used the command above to run Steam in my session and paste in the Moneybookers login credentials conveniently. Success!
I quickly found out that sound is not routed for these redirected applications. It’s a pity it doesn’t work out of the box, but fortunately it can be fixed quite easily.
First, install and run paprefs and activate Enable network access to local sound devices. I have no idea which configuration was adjusted, because nothing changed neither in ~/.pulse nor in /etc/pulse. But you can see now the pulseaudio server listening over TCP/IP for network connections. Authorization should be required, so you don’t need to be afraid of eavesdroppers.
Now, try to play some sound:
kparal@kraken ~ $ su - gamer -c paplay /usr/share/sounds/alsa/Front_Center.wav
(or just run Totem/Firefox/etc)
If you are lucky (unlike me), your audio now works out of the box. But if you pulseaudio daemon is restarted for any reason (it crashes or you kill it and start again), the routing no longer works and you need to re-log to your desktop session. Probably a bug. I didn’t know that, so I spent hours reading PulseAudio documentation. It’s not the most thrilling experience.
If that magic routing didn’t work for you, or you need to play audio even after PA is restarted, this is what I involuntarily discovered:
(It should be also possible to route the audio using unix sockets (instead of TCP/IP sockets), but the damned documentation is not helpful at all in achieving this task.)
Spot two differences:
kparal@kraken ~ $ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset
and
kparal@kraken ~ $ su - gamer -c glxinfo | grep render Password: libGL error: failed to load driver: i965 libGL error: Try again with LIBGL_DEBUG=verbose for more details. direct rendering: Yes OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301)
Yes, your redirected applications don’t have 3D acceleration. Here is a more detailed error message:
kparal@kraken ~ $ su - gamer Password: gamer@kraken ~ $ LIBGL_DEBUG=verbose glxinfo | grep render libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so libGL error: failed to open drm device: Permission denied libGL error: failed to load driver: i965 libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so libGL: Can't open configuration file /home/gamer/.drirc: No such file or directory. direct rendering: Yes OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301)
I tried to run chromium-bsu and extremetuxracer, both run around 30 FPS using software rendering. Not suitable to gaming at all.
Fortunately I’ve found out the reason. It’s all about access permissions to /dev/dri/card0 file, which represents your graphics card. If you log in using a standard graphical session, some daemon (probably logind) grants you temporary rw access to that file using ACLs:
kparal@kraken ~ $ getfacl /dev/dri/card0 getfacl: Removing leading '/' from absolute path names # file: dev/dri/card0 # owner: root # group: video user::rw- user:kparal:rw- group::rw- mask::rw- other::---
But if you log in using su or sudo, you are not given proper permissions. I have found two solutions. The first one is to manually add gamer‘s ACLs after each boot:
kparal@kraken ~ $ sudo setfacl -m user:gamer:rw /dev/dri/card0
This can be added for example to /etc/rc.d/rc.local in order to be executed every boot. The other approach is to add gamer to the video group, which owns the file. In this case you don’t need to execute anything else on each boot, the change is permanent.
Now your 3D applications should work correctly:
kparal@kraken ~ $ su - gamer -c glxinfo | grep render Password: direct rendering: Yes OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset
The simple games I tried now run at full speed.
Please note however, that there are slight security concerns when you elevate these permissions for gamer permanently. If the account gets hacked, the attacker can access your graphics card (maybe see your display? I don’t know) or even a camera (just if you used the video group approach, because this group also controls access to the webcam) while being logged in remotely. From this reason the first approach seems a bit safer to me (limits the number of devices) and you should definitely prohibit gamer from any remote access (e.g. disable this account in your ssh server configuration).
That’s it, I can finally display graphical applications (even games) from a different user account inside my desktop session. It took me quite some time to find this all out. It’s highly probable that I did a lot of things the wrong way. Does anybody know of a tool that would handle all this setup transparently and easily? Or does anyone know a working sandbox tool that would fit these use cases? Please share your improvements in the comments. Thanks.
I have recently found out that GNOME Online Accounts now support Kerberos authentication. I assume this might be interesting for many people who use GNOME in an corporate environment, so I decided to spend a few words about it here.
The setup is as simple as it can get. You just add a new Kerberos account in GNOME Online Accounts and provide a domain name, your user name and a password. Then you see this:
Every time you boot your computer now, you will also receive a Kerberos ticket. Awesome!
Unfortunately, the world is not perfect, and neither is GNOME Online Accounts. So there are a few annoying problems:
Let’s hope these problems will be ironed out in GNOME 3.8, currently it’s just a half-baked solution. But it’s definitely better than having nothing at all.
If you’ve installed/upgraded to Fedora 18 and you would like to play your media files (music and videos), this is the current way to go:
$ yum install gstreamer1-libav gstreamer1-plugins-ugly
For some reason the Totem’s auto-search function is now broken, so you have to do it manually. I suspect the reason is that the package names have changed (compared to Fedora 17 and earlier).
Of course all of this only applies to citizens of those countries where software patents are not valid. Otherwise this action would probably be illegal and you might receive a capital punishment or similar.
From Fedora 18, we will finally have LibreOffice included on Live CD, and installed by default! (We were able to do this by raising the Live CD size from 700 MiB to 1 GB, now targeting flash drives instead of CD media). This is great news for our users, because the office suite is needed by many and they had to manually install it in older releases. With this change Fedora 18 makes another step towards reasonable defaults, and it will certainly be appreciated by our newcomers.
Thanks to everyone who supported me in the discussion, and Bill Nottingham for pushing that change.
It’s a bit ironic that Fedora 18 DVD will not install LibreOffice by default, you have to select it as an “add-on” in the installer. The infrastructure standing behind package collections has been re-worked and it doesn’t allow us to enable some collection (like LibreOffice) by default. Of course you can still select it manually. Hopefully we will have it fixed and auto-selected in Fedora 19.
I would like to warn you all about a serious bug discovered in Nautilus in Fedora 17 (GNOME 3.4). If you use it to copy files from your computer to an external HDD, you might experience a data loss (some files missing/corrupted). The problem is that Nautilus doesn’t show notifications properly when you want to eject the drive and all data is not written out yet. The bug has been fixed in Fedora 18 (GNOME 3.6), but it is still present in Fedora 17, and it is reported in bug 886435. It does not affect flash drives, only external HDDs (at least according to my tiny statistical data).
Ideally, it should look like this – if you try to eject the device, you are told that data are still being written: 
Once that is complete, you are told that you can finally eject the device:
However, none of these notifications are shown in Fedora 17, if you eject the drive using Nautilus. You then assume that everything is OK and disconnect the drive – and some of your data is silently lost.
The workaround is to use GNOME Shell notification area to unplug the drive:
That works well and notifications are shown.
If you happen to use some other desktop environment, like XFCE or MATE or something else with Nautilus, then probably the safest choice it to open up a terminal and run “sync” command. Once it finishes, all your data is written out correctly.
Hope this helps.
In GNOME 3.4 (Fedora 17), GNOME Online Accounts (GOA) worked great with Google two-factor authentication (you really should enable that, if you value your data). In GNOME 3.6 (Fedora 18) it works no more, and it might be fixed in GNOME 3.8. When developers break some existing functionality for the sake of “progress”, but don’t bother fixing it or providing an alternative way before an official release, I always feel a bit… disenchanted.
Fortunately you can work around the broken code.
'password': <'your_password'>.It would be really nice if we didn’t have to fix this stuff by hand. Every time I upgrade I have to do lots of these kinds of magic fixes. In Fedora 18, this was one of the minor issues. The big issues still await me.
There is a nice improvement in Fedora 18 related to yum and PackageKit. It fixes a long-standing issue that while PackageKit is active (e.g. checking for system updates), any yum usage is blocked. You would see messages like this:
$ yum install foo
...
Another app is currently holding the yum lock; waiting for it to exit...
The other application is: PackageKit
Memory : 41 M RSS (447 MB VSZ)
Started: Fri Sep 7 09:27:08 2012 - 23:13 ago
State : Sleeping, pid: 1315
Another app is currently holding the yum lock; waiting for it to exit...
The other application is: PackageKit
Memory : 46 M RSS (452 MB VSZ)
Started: Fri Sep 7 09:27:08 2012 - 23:15 ago
State : Running, pid: 1315
...
It could last from seconds to dozens of minutes. Killing PackageKit was often the only choice. For me, as a yum-only user, this was really painful and annoying.
But it is no longer the case! As you can see in Bug 812938, Elad Alfassa implemented a patch to PackageKit-yum-plugin and Richard Hughes incorporated it upstream. If you run yum in Fedora 18 now, it will send a signal to PackageKit to cancel any background operations, run your yum command almost immediately and then resume PackageKit operation. The fix turned out to be quite simple, which is ironic, because this issue caused a lot of grievance among our users.
Elad, Richard, thanks a lot!
And the lessons learned for the rest of us is that if you have at least decent technical knowledge and something troubles you, it’s worth to have a look at it. The solution might turn out quite simple. (Personally, I really miss some team in Fedora that would focus on these small issues that cause a lot of discomfort).
Thanks again, guys.
There is currently a nasty bug in Fedora 17 related to USB devices. If you copy some data to your USB flash drive/harddisk and try to eject it (either in Nautilus or using Gnome Shell tray icon), there is no indicator of progress saying whether you need to wait until all the data are written or whether you can already remove the drive. Instead you’ll get the notion that you can remove the drive immediately. But if you do this, your data might be corrupted (in case some of them haven’t been transferred yet).
There are two possible workarounds for this:
1. (easier) After you eject the device using Nautilus or Gnome Shell dialog, run a terminal and write sync. Wait until that finishes and only after that unplug the device from the computer.
2. (harder) Don’t use Nautilus or Gnome Shell to eject the device, but use umount in terminal instead. You have to be root to do this. The mount point is in /run/media/.
As you can see, none of these approaches is suitable for inexperienced users. I’ll try to make sure we won’t release Fedora 17 Final with this bug included. Until that time, please be aware of this so that you don’t lose your data.
EDIT: Follow-up post: Fedora 17: Your data on USB devices are now safe(r)
Kparal's Fedora Blog 