Tagged as: Linux

OpenSSL for!
April 18, 2014 by Noah

A while after the Heartbleed SSL vulnerability made headlines, ran an article titled "It's Time to Encrypt the Entire Internet" urging everyone to deploy SSL/TLS encryption on their sites.

SSL certificates tend to be pretty expensive, though, which is one reason I hadn't looked into it that closely in the past. In a Reddit comment thread about that Wired article some people mentioned Namecheap as a good option for simple SSL certs. So, I got a simple domain-level certificate for $9 for :) So all URLs are now running over https! This blog post is about the experience of setting up SSL and wrestling with various applications in the process.

Generating the Certificate

The simplest guide I found that I followed to make a certificate was Generate CSR - Apache OpenSSL. One command creates a passphrase-protected key file, the next one generates the signing request:

openssl genrsa –des3 –out kirsle.key 2048​
openssl req -new -key kirsle.key -out kirsle.csr

You apparently need a 2048-bit RSA key these days before a Certificate Authority will consider your signing request. I pasted in my CSR file and filled out some forms, got an e-mail verification sent to the address on my WHOIS record for my domain, and before I knew it I was e-mailed a zip file containing my certificate and the Comodo CA certificates.

Certificate Chain File

Various apps will need your Certificate Authority's chain to be in a single file. You can create this file by catting the certificates into one file in "reverse" order, with your site's certificate on top, and the root certificate on bottom. Comodo gave me these files (and this is also the order for the chain file):

  • certificate: www_kirsle_net.crt
  • Intermediate CA certificate: COMODORSADomainValidationSecureServerCA.crt
  • Intermediate CA certificate: COMODORSAAddTrustCA.crt
  • Root CA certificate: AddTrustExternalCARoot.crt

So I generated the chain as follows:

cat www_kirsle_net.crt COMODORSADomainValidationSecureServerCA.crt \
    COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > cacert.pem

Apache2 mod_ssl

I'm running a Debian server, so I just symlinked the ssl.load and ssl.conf files from my /etc/apache2/mods-available into my mods-enabled, and then edited the ssl.conf. All I changed in it was to uncomment the SSLHonorCipherOrder on line.

I removed the sites-enabled/default-ssl and then edited my config file to add a <VirtualHost *:443> version. I had to look at the default-ssl file to get an idea which options were needed (if I missed any, Apache would fail to start!)

Relevant SSL options for my VirtualHost:

    # SSL
    SSLEngine on
    SSLCertificateChainFile /etc/ssl/crt/cacert.pem
    SSLCertificateFile /etc/ssl/crt/www_kirsle_net.crt
    SSLCertificateKeyFile /etc/ssl/crt/kirsle.key
    SSLOptions +StdEnvVars
    BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

Note: if you leave out the chain file, web browsers will still behave fine (because they're smart enough to download the intermediary certificates themselves), but other things will break. For example, the Python requests module will throw an SSL exception if the server doesn't give it the intermediary certificates!

After making sure was working, I made an update to my Rophako CMS to support SSL sites better and then made the switch-over. Any requests going to my HTTP are redirected to the SSL version and given a Strict Transport Security header.

As a fun side note, Apache supports Perfect Forward Secrecy by default (using the default SSLCipherSuite option of HIGH:MEDIUM:!aNULL:!MD5).

Starting or restarting Apache requires you to enter the SSL key's passphrase at the command line. For simple config updates, service apache2 graceful will reload them without needing a full restart, so you don't need to enter the passphrase then.

Dovecot IMAP

I use Dovecot for my IMAP mail server on, and I wanted it to use my shiny new SSL certificate. Before this, I was using a self-signed certificate, and apparently Thunderbird doesn't even warn you if that self-signed certificate changes at any point. After the Heartbleed vulnerability was fixed, I re-generated new self-signed certs and was shocked that Thunderbird happily accepted the new certificate without even telling me. It would've been extremely easy to Man-in-the-Middle my e-mail server. (I had since then installed an extension in Thunderbird to police SSL certificates for me as a workaround).

So, configuration is pretty simple, just edit /etc/dovecot/conf.d/10-ssl.conf and enter in the new paths to your chain file and private key. Note that if you use just your domain's certificate, clients like Thunderbird that support SSL properly will complain about the certificate being insecure, and unlike web browsers, Thunderbird doesn't bother downloading the intermediary certificates itself.

One catch with Dovecot is that if your private key file is encrypted with a passphrase like mine is, doing service dovecot restart won't work. Dovecot will start in a way where it won't support TLS but will otherwise appear to function normally.

To start Dovecot with a passphrase, you need to run dovecot -p (as root) to start the service. It will prompt for your passphrase at the command line and then start up. The service can be stopped normally using service dovecot stop.

Postfix SMTP Server

This one I'm a bit upset about. Postfix has absolutely NO support for using a passphrase protected TLS key file! Even their official documentation states that the key file must not be encrypted.

That is so full of wtf. Postfix is a widely deployed SMTP server for Linux, and it has to use insecure, unprotected TLS key files. So, I'm still using a self-signed certificate for Postfix (and my Thunderbird add-on will tell me if this certificate ever changes, so don't get any ideas!). I don't send outgoing mail very often, anyway, and if I care enough I'll PGP encrypt. But, I'll be looking into an alternative SMTP server sometime soon.

Tags: 4 comments | Permalink
Google Music Manager Fix for Linux
October 30, 2013 by Noah
There seems to be a problem with the Google Play Music Manager on Linux, where once you set up the Music Manager for the first time, it's impossible to get its main window to appear after that. The tray icon is there, and it can be right-clicked on to bring up a menu, but clicking "Options" in the menu does nothing, and double-clicking the icon (which should bring up the Options window) also doesn't do anything.

I ran into this problem a couple different times on different machines running Fedora over the span of about the last 6 months. I had to Google it both times to find a solution (which wasn't easy to find), so here's the solution that ended up working for me each time.

  1. Stop the Music Manager by right-clicking the tray icon and clicking "Quit."
  2. Delete the folder ~/.config/google-musicmanager
  3. Optional step: the Music Manager is horrible at detecting duplicates, so I recommend you completely clear out your ~/Music folder (if you already downloaded songs from Google, move them to some other place). You'll see why in step #8.
  4. Open the Music Manager again from your applications menu.
  5. Log in to your Google account, etc.
  6. Choose "Upload music", not Download.
  7. Don't use the default "Music Folder" option, but explicitly browse to your Music folder and add it manually.
  8. Ignore any warnings about "less than 10 songs in the folder" etc. Also, if you already have music in your Music folder, the Music Manager will upload them anyway, and it sucks at detecting duplicates so you'll end up with a ton of duplicates on your Play Account in the cloud. This is why I recommend to clear out your Music folder in step 3.
For some reason, choosing to upload rather than download during the initial setup fixes the problem of the Options window not appearing from then on. Hopefully Google will fix the Music Manager soon, but it's been broken for ~6 months already so in the mean time this is the work-around. I eventually found this solution both times from a thread on the Ubuntu forums. Uninstalling and reinstalling the app is unnecessary, simply deleting the config folder does the same job.

Also, if you can't get the Music Manager to start at all in the first place, try running it from a terminal window with the google-musicmanager command and see what it says. On Fedora, it told me "error while loading shared libraries:", and I just had to yum install qtwebkit to fix it (the MusicManager RPM didn't correctly list this dependency). When you see this or similar errors in Fedora, you can use a command similar to yum provides '*/' and see what packages provide the missing file, and know what to install from there.

Tags: 41 comments | Permalink
Fedora on Raspberry Pi
May 25, 2013 by Noah
I'm writing this blog post from Pidora 18, a build of Fedora Linux for the Raspberry Pi ARM computer.

I'm going to compare it to Raspbian, which is the usual OS that people install on their Raspberry Pi's.

As far as speed goes, Fedora 18 runs pretty well on this device. I haven't directly compared it side-by-side with Raspbian, but I haven't noticed any real annoying slow-downs at all. They've optimized Fedora 18 to run well and take full advantage of the floating point unit on the Pi, which previous versions of Fedora didn't do.

One huge plus with Fedora over Raspbian is that the NetworkManager applet comes installed and set up by default (as it does on all Fedora OS's). It was super easy to connect to my wifi network with it. Under Raspbian, there's only the wpa_gui, and it doesn't work very well for me and I have to click the "Connect" button a dozen times before it finally connects. The NetworkManager applet is a huge improvement.

The Pidora distro comes with the XFCE desktop environment, as opposed to Raspbian's LXDE desktop (on my Raspbian, I had gone ahead and installed XFCE anyway). On my setup, audio was working how I want it to out-of-the-box. I have my Pi connected to a DVI monitor, using an HDMI to DVI adapter. In Raspbian, I had to uninstall Pulse and hack ALSA up to make it send audio out the analog jack instead of HDMI, so that I could connect it to some proper speakers. In Pidora, Pulse wasn't even installed by default, and ALSA already knew to send the audio through the analog jack.

I also managed to get Minecraft: Pi Edition to run on Pidora. I just needed to install libpng12 and SDL, and fix the permissions on the vchiq device (using instructions I found on the Raspbian Quake3 page), and I was good to go.

The biggest downside to Pidora is that there is no RPMFusion for it. They rebuilt pretty much all of the standard Fedora packages for the ARMv6 architecture, but upstream Fedora doesn't include anything non-free, like MP3 support, and so Pidora doesn't have that available in their repos either. Raspbian is a better bet if you need MP3 and video codec support, unless you want to compile the software yourself.

I think I'll stick with Pidora though. It's a lot more familiar since I run Fedora on all my other computers, and pretty much everything about Fedora is exactly the same in Pidora. :)

Tags: 1 comment | Permalink
Gnome Shell on Touchscreens
May 19, 2013 by Noah
For once, this is actually not going to be a rant about Gnome Shell. It actually runs decently on a touchscreen!

I recently got a Samsung Series 5 Ultrabook which has a touchscreen on it. After having trouble getting Windows 8 how I want it on this laptop, I installed Fedora w/ XFCE across the entire disk. I got motivated to try again with Windows 8, though, because it's a shame having a touchscreen and no software that knows how to use it properly.

XFCE doesn't work well with a touchscreen. I can't move windows around on it by touching and dragging their title bars. I can't highlight text.. when I touch and drag over text, it selects it, but it immediately de-selects as soon as I let go. About the only thing I can do on XFCE is click on things, and scroll a window by touching and dragging the scroll bar.

Before dealing with repartitioning and getting Windows 8 back on there, I decided I'd yum groupinstall "GNOME Desktop" and see how well Gnome Shell works with this touchscreen.

The first thing I tested was dragging windows around. It works. I opened Firefox and dragged inside a web page, which highlighted text (don't remember if the text stayed highlighted though). Dragging the scrollbar worked.

I opened Nautilus and navigated to /usr/share by touching the icons. This folder had a scrollbar. I could drag the scrollbar just like in Firefox, but I could also scroll the window by touching anywhere else in the window and swiping, just like you'd expect on Android or iOS. It supported acceleration too, where you could swipe quickly and let go and the window would continue scrolling and eventually slow down.

Dragging windows around in the Activities view worked exactly how you'd expect, too.

Gnome Shell doesn't support multi-touch, though. But I think this is the fault of X11 in general not supporting it, so you can't blame them for that. If you try a multi-touch gesture, it just gets confused and tries to treat all your fingers as one and you get erratic mouse movements or something.

I still don't like Gnome, but I am impressed that this actually works, for all the propaganda you hear from the Gnome devs about making it a tablet interface. I was expecting it to be as painful to use as XFCE on a touch screen.

Now, to install Windows 8 and then put Fedora XFCE back on. ;)

Tags: 3 comments | Permalink
Nvidia vs AMD in Linux
May 10, 2013 by Noah
Having used both brands of video card in Linux over the years, the tl;dr. is that Nvidia has much better support with their closed source drivers on Linux than AMD does. Here's my anecdotal evidence for why I think so.

I've used three computers that came with various kinds of AMD graphics cards, and all of them have given me nothing but problems in Linux. The first one was an ATI Radeon Xpress 200M, built into an old laptop I bought in 2007. This video card appears to have already been obsoleted by AMD at the time I bought the laptop, but that's another story.

The Xpress 200M card was problematic for both Linux and Windows. It only worked reasonably well with Windows XP; and it's entirely not supported by any means in Windows 7 or 8. In Linux, I can only use the open source radeon driver with it, but that doesn't give me any kind of hardware acceleration. If I install the fglrx driver (AMD's closed source proprietary one), it makes the system completely unstable, and random kernel panics and freezes become very common.

My second computer with an AMD video card was a Dell Studio XPS desktop. I don't remember the exact model number of this AMD card, but it was somewhere in the mid-range area. I installed the fglrx driver in Linux, and it worked reasonably well, except every once in a while my screen would completely go black, and then I could bring back parts of my display by "refreshing" them (i.e. moving my mouse around, dragging a window... any time a part of the screen needed to be redrawn by Linux, it would be redrawn and the solid black would go away). My XFCE panels were particularly difficult to get to redraw themselves, though, because they don't refresh very often. I'd have to kill/restart the panels instead.

The reason I replaced this card with a mid-range Nvidia wasn't because of the random blacking-out issue, it was actually the card's pitiful performance in Windows 7. I ordered the desktop with suitably powerful specs (6 GB RAM, 6 core 64-bit AMD CPU), so that I could run emulators for the likes of Sega Saturn and GameCube. For the latter, the frame rate would be pretty slow in parts and I suspected the video card was the bottleneck, so I tried replacing it with an Nvidia card I had from my old desktop. This did indeed speed up the frame rate in the emulators by quite a lot (most games run at full speed most of the time), and of course fixed my blacking-out issues in Linux.

The third time I had to deal with an AMD card was on a work PC. This one has an AMD Radeon HD 7400 Series video card, and it really caused nothing but problems.

First, the open source radeon drivers in this case were entirely useless. About half of the time when I booted this computer, it was unusable. I'd end up seeing a completely white screen, with maybe 3 pixels worth of stuff happening at the top of the screen (I think it was the bottom of an XFCE panel, with a workspace switcher applet). It's like the screen resolution was completely wrong and/or scaled up to a ridiculous level. Switching to text mode didn't work either... the screen would go black, but there'd be no prompt (presumably, the prompt was WAY outside the screen borders).

The other half of the time, the display would simply be off-centered. The left edge of the display would be about 1/3 of the way across the monitor, and then it would wrap-around on the right so that the right part of the display was on the left 1/3 of the monitor. Attempting to change the screen resolution within XFCE (using both XFCE's built-in tool, or xrandr directly), would put the monitor into "seizure mode" where it would flicker black and white rapidly.

Installing the fglrx drivers fixed most of my problems, except that AMD feels the need to let me know that my video card isn't officially supported. They placed a watermark in the bottom right corner of my screen, that's rendered on top of everything else the display puts out, that has their logo on it and says "Unsupported hardware". And there's no configurable option where you can say "that's fine, just let me try my own luck using this driver anyway". Nope, to get rid of the watermark, you have to hotpatch the driver binary to basically delete the image out of it, and then reboot. There's a shell script on the Internet that does this - just google "fglrx watermark"

In contrast, I have never seen an Nvidia card that gave me any problems in Linux. The binary drivers for Nvidia have always been absolutely perfect. The only issues I'd ever run into were the times when Fedora would get a new kernel update, and the third party group who package the Nvidia driver lagged behind a day or two in getting their update out. This is largely fixed by using akmod-nvidia instead of kmod-nvidia, though. akmod's automatically rebuild themselves when you update your kernel.

Tags: 3 comments | Permalink
Make Emoji Work in Linux
April 4, 2013 by Noah
I've discovered how to get the full range of Emoji icons to render on Linux systems.

tl;dr. - Just install the Symbola font (the link on the right half of this page: Unicode Fonts for Ancient Scripts) into your /usr/share/fonts or ~/.fonts folders. Ubuntu users can sudo apt-get install ttf-ancient-fonts. For Fedora users, you can yum install gdouros-symbola-fonts (thanks James in the comments for correcting the spelling. I typed this command for the blog instead of copying/pasting from my terminal. ;)).

I ranted about the poor Emoji support in non-Apple systems before, then updated the post with screenshots showing exactly how various users will see (or not) your Emoji icons, but I got curious again to figure out what can be done to make Linux support them.

I heard (inaccurately) that Ubuntu should support them (in actuality, the person I heard this from had installed the Symbola font, so he could see Emojicons, but the default Ubuntu user can't). I also heard that it was up to the individual typefaces to include all the Emoji symbols, and if your chosen font doesn't include them, they don't render.

Testing the latter theory, I yanked the Segoe UI font from Windows 8, which is the default font, and I know that Windows 8 fully supports Emoji. This font in Linux though didn't render Emoji icons any better than all my other fonts did.

I heard about Symbola from a Google search, but the blog post I saw that mentioned it was talking specifically about how to use Emoji on your web pages... and it sounded like, "you embed Symbola.ttf using HTML5's new feature, and use that font family for each Emoji icon you want to include on your page... i.e. <span style="font-family: Symbola">emoji symbol here</span>.

Then a coworker mentioned that the typefaces don't need to include the Emoji icons, as long as font substitution is supported... so I was curious if Linux could do such a thing, so I simply dropped Symbola.ttf in my ~/.fonts folder, and within 2 seconds, all the unrenderable Emoji symbols I saw in my Pidgin chat logs suddenly transformed into the correct symbols like some kind of magic.

So, that's how you do it.

But now I'm curious about what kind of black magic Linux did to suddenly render these symbols. Maybe, when it finds an unrenderable symbol, it scans through the installed fonts until it finds one that provides that symbol...

Tags: 20 comments | Permalink
Steam for Linux in Fedora x64
December 30, 2012 by Noah
Update: Spot has a Steam yum repository set up. Download steam.repo to your /etc/yum.repos.d directory, and then yum install steam. When I originally wrote this post, Spot's steam repo was gone (that link gave a 404).

Just a quick post about how to install the Steam for Linux client on 64-bit Fedora Linux.

This works for Fedora 17 x64. I'm not sure it will work in Fedora 18 or later versions when they come out, but I'll probably test that at some point too and update this post.

NOTE: It should go without saying, but the terminal commands I list below begin with a $ sign -- you don't type this symbol. That represents your prompt. So when it says "$ yum install ..." you just type "yum install ..."

  1. Download the steam.deb Ubuntu package (currently, Steam only officially supports Ubuntu 12.04) - link that works as of the time of this writing.
  2. Open the .deb in an archive manager, such as Gnome's file-roller. Extract data.tar.gz from the .deb file.
  3. Extract data.tar.gz somewhere like ~/steam - put it in an empty folder, so after extracting, this folder will only contain the directories "etc" and "usr"
  4. In a terminal, switch to the directory you extracted data.tar.gz to, and run:
    $ sudo cp -r * /
    Alternatively, open a file manager like Nautilus as the root user if you'd prefer to do a copy/paste visually.
  5. You'll also have to install the 32-bit versions of some libraries that Steam depends on. Run this command in a terminal:
    $ sudo yum -y install libpng.i686 libpng-compat.i686 gtk2.i686
  6. Run Steam either by the steam command in your terminal, or via your application menu.
And it should work. You will probably also need to install 32-bit support libraries for your video card, for example xorg-x11-drv-nvidia-libs.i686 for recent NVIDIA video cards (assuming of course you're using kmod-nvidia and not the default nouveau drivers!). You're on your own here though, but this Crossover Wiki page may help.


If you get an error that says "Failed to load", this will be caused by missing dependency errors. Steam will need the 32-bit versions of some libraries it depends on, which don't get installed by default in a 64-bit Fedora OS. Re-read the steps above and make sure you installed the 32-bit versions of libpng, libpng-compat, and gtk2. If they're all installed, it may be another library (I personally only had to install the three listed). The general procedure to track down missing libraries in Linux is as follows:
  1. In a terminal, navigate to Steam's library folder, which (as of right now) should be in $HOME/.local/share/Steam/ubuntu12_32
  2. Run this command to list the missing library dependencies for
    env LD_LIBRARY_PATH="$PWD:$LD_LIBRARY_PATH" ldd | grep "not found"
  3. If this command shows no results, this means there are no missing libraries and everything should be working. If it does list results, continue reading.
  4. For example, if it says " => not found", run this command to identify the package in Fedora that provides that file:
    yum provides '*/'
  5. This will list packages like gtk2-2.24.10-1.fc17.i686 : The GIMP Toolkit (GTK+), a library for creating GUIs for X (there will also be a ".x86_64" version, but we don't care about those because we need the 32-bit libraries).
  6. Ignore the version number part of the package and just sudo yum install gtk2.i686 -- make sure to include the .i686 part, otherwise Fedora will just assume you want 64-bit because it matches your current architecture.
Good luck!
Tags: 2 comments | Permalink
Linux of the 90's
September 27, 2012 by Noah
Let's look at some very, very old* desktop environments, which lack in some features we've had for at least a good decade now.

Gnome Shell

What sorts of things does this clunky old desktop environment not allow us to do, which every other desktop does (and has for a decade)?

  • We don't have a customizable panel. There's a panel on the top, and it stays there; can't be moved, hidden, changed in any way...
  • We can't change the widget (GTK) themes on the fly. The desktop environment itself provides no way of changing the theme at all, and changing it via a third-party tool requires you to log out of your desktop and back in for the change to take effect. How old school is that!
  • The same goes for the window manager theme. Every other window manager in the history of ever lets you re-theme it "live" without logging out. Not good old Metacity, though!
That's enough ragging on this one, let's look at another one!


This one is based on Gnome Shell. Some people didn't like Gnome Shell and they wanted to make it look and feel like a more functional desktop environment known as Gnome 2. So let's compare it to that!

  • Oh no. The panels aren't hardly configurable. You have 3 options: one panel on top, one on bottom, or both. And changing that setting requires you to log out and back in. How ancient.
  • Panel applets? I hope you only want one of each applet, and that you're fine sticking them into pre-designated slots on your panel. You can't customize them beyond that. The applets don't even have their own settings--your app menu will say "Menu", and you can't change that.
  • Metacity strikes again! You can't change the window manager theme without logging out and back in.
Wait, what ever happened to Gnome 2, anyway? I used to like that guy!


*These desktop environments aren't very old at all. They're current. Gnome Shell is the default desktop environment of Fedora, and Cinnamon is one of the defaults of Linux Mint. And who's really at fault for these two desktop environments being so 1995, anyway? The GNOME dev team of course!

Gnome Shell is just so, so awful that Cinnamon was spawned as a way to get a more traditional (read: Gnome 2-like) desktop environment out of the utter mess that is Gnome Shell, except that Shell's bad design decisions are rotten to the very core and Cinnamon has to suffer for it as well.

Just to pick on one specific problem, Metacity no longer supports re-theming the window manager without logging out and back in. How many window managers in the world follow this behavior? Let's count them:

  1. Metacity 3.x
Oh? And which window managers do allow being re-themed live?
  • Metacity from Gnome 2 and back
  • XFWM4 (the window manager for XFCE)
  • KWin (window manager for KDE)
  • OpenBox, Blackbox, Fluxbox, FVWM, . . .
That's right, damn well every single one of them.

I was very impressed with the MATE desktop environment when I tested it on Linux Mint... it is the exact same Gnome 2 that I used to love. The panels behaved the same way (read: fully effing configurable and requiring no log-outs to see your changes take effect), it had all the same applets and didn't come with the high-and-mighty "we know better than you and you may have ONE of each applet at most" attitude that Cinnamon has... and it doesn't use Metacity 3 so that all kinds of theming takes effect immediately.

So there's MATE, XFCE, KDE, LXDE and a good handful of window managers that exist here in the 21st century, and then there's Gnome Shell, and by extension Cinnamon, stuck back in 1995 which is the only place that their lack of features can possibly fit in.


Tags: 3 comments | Permalink
A Simple Web Browser Launcher
July 23, 2012 by Noah

I like to keep my Facebook separate from my other web browsing, so I use Google Chrome for Facebook and Firefox for everything else. This way, Facebook will have a harder time tracking me across the web through those "like" buttons if they don't have a logged-in cookie for me, since web browsers don't share cookies.

But this becomes annoying when somebody sends me a Facebook link on Pidgin, because it would open in Firefox when I click it and I'd have to copy/paste the link to Chrome instead. So, I wrote a little wrapper script to make this all automatic for me.

I set this script to be my default web browser, so anytime a program wants to open a link, it calls my script instead of Firefox. Then my script looks at the domain name from the URL, and opens it in Chrome if it's a facebook link, or Firefox otherwise.

Here's the script for others to use. You can also download it here.


# browser-wrap: Set this as your default browser to open certain links with
# certain browsers.
# To get `xdg-open` to use this, put this in your ~/.profile (update the path
# to match where you installed the script to):
# if [ -n "$DISPLAY" ]; then
#     BROWSER=/home/kirsle/bin/browser-wrap
# fi
# --Kirsle

use 5.14.0;
use strict;
use warnings;

# Configuration Section                                                        #

# Define your browser rules here.
my $rules = {
    # These are domain names to match. Use a regular expression.
    qr/(facebook|fbcdn)\.(com|net)/ => "google-chrome",

# Default browser for links that don't have rules that match.
my $default = "firefox";

# End Configuration Section                                                    #

# Get the URL passed in.
my $url = shift(@ARGV);
my $browser = $default;

# Looks okay?
if ($url =~ /^https?:\/\/([^\/]+)\/?/i) {
    print "Domain: $1\n";
    my $domain = $1;

    # Look for the best rule.
    my @sorted = sort { length($b) <=> length($a) } keys %{$rules};
    foreach my $rule (@sorted) {
        if ($domain =~ /$rule/i) {
            # Matched!
            $browser = $rules->{$rule};

# Launch the browser.
my ($app, @args) = split(/\s+/, $browser);
exec($app, @args, $url, @ARGV);

Tags: 0 comments | Permalink
Yum Updates Daemon for XFCE
June 4, 2012 by Noah

Update (5/28/13): I've ported this script over to Python: pyupdatesd. The Python version only requires pygtk2, which tends to come preinstalled on Fedora XFCE systems.

Since about three versions of Fedora ago, there wasn't an updates daemon for the XFCE desktop environment (or LXDE or the others, for that matter). KDE still had theirs, and Gnome 3's update daemon was built in to the desktop environment. So, XFCE users were stuck having to look for updates manually.

Not anymore!

I finally got around to writing a Perl script that checks for available updates, and shows a Gtk2 tray icon and a notification pop-up when one has been found. You can set it to start up automatically in your session settings and it will check updates for you every 15 minutes.

kupdatesd screenshot

You can get it from Or you can see its source code here. :)


# kupdatesd - A simple yum update checker.
# This script will watch for available yum updates and show a GTK+ TrayIcon
# and notification pop-up when updates become available.
# This is intended for desktop environments like XFCE that don't have a native
# PackageKit update watcher.
# Set this script to run on session startup and it will check for updates every
# 5 minutes (by default; this is configurable in the source code).
# --Kirsle

use 5.14.0;
use strict;
use warnings;
use Gtk2 -init;
use Gtk2::TrayIcon;
use Gtk2::Notify -init, "kupdatesd";

# Configuration Section                                                        #

my %c = (
    # The title to be shown on the pop-up and the icon tooltip.
    title    => "Updates Available",

    # The message to be shown in the pop-up.
    message  => "There are updates ready to install.",

    # The icon to use for the pop-up and tray icon.
    icon     => '/usr/share/icons/gnome/32x32/status/software-update-available.png',

    # How often to check for updates (in seconds).
    interval => 900,

    # The path to your yum binary.
    yum      => '/usr/bin/yum',

    # The path to your graphical updater.
    # gpk-update-viewer is provided by gnome-packagekit
    gui      => '/usr/bin/gpk-update-viewer',

# End Configuration Section                                                    #

# Gtk objects
my ($icon, $image, $eventbox, $tooltip, $notify);
my $visible = 0; # Icon is currently being displayed?

# Enter the main loop.
my $check = time() + $c{interval};
while (1) {

    # Keep Gtk2 active.
    if (defined $icon) {
        Gtk2->main_iteration while Gtk2->events_pending;

    if (time() > $check) {
        # Look for updates.
        unless ($visible) {
            system("$c{yum} check-update > /dev/null 2>&1");
            if ($? >> 8 == 100) {
                say "There are updates available!";

        # Queue another check.
        $check = time() + $c{interval};

sub show_icon {
    # Already initialized this once before?
    if (defined $icon) {
        # Just show the icon and notification again.
        $visible = 1;

    # Tray icon. Image goes in EventBox, EventBox goes inside TrayIcon.
    $icon = Gtk2::TrayIcon->new("kupdatesd");
    $image = Gtk2::Image->new_from_file($c{icon});
    $eventbox = Gtk2::EventBox->new;

    # Attach the tooltip.
    $tooltip = Gtk2::Tooltips->new;
    $tooltip->set_tip($icon, $c{title});

    $eventbox->signal_connect("button_press_event", sub {
        $visible = 0;

    $notify = Gtk2::Notify->new(
    $visible = 1;

Tags: 15 comments | Permalink