At the very top of my personal list of improvements to Steam would be “native Linux support”. And I know, I know, I’ve heard all of the conventional wisdom: There isn’t a big enough market to justify porting it. Even if there was, there aren’t enough Linux-native games to make the service very useful. Everybody knows Windows is the OS for gaming.

But sitting here staring down that conventional wisdom is Desura. I’ve known that Desura existed for a while – the Frozenbyte Bundle and the Humble Bundle 3 both had options to acquire ‘Desura keys’, so it was obviously a Steam competitor. Until recently, though, I had just dismissed the product – obviously, I thought, any Steam competitor is going to lag far behind in available games and basic feature set, given Steam’s popularity. Faulty logic, but there it is.

So when a friend told me that Desura works in Linux, I was pretty stunned. I had gotten used to not being the ‘target audience’ for game companies. And now, a few hours later, I’ve got Desura installed, my humble bundle keys redeemed, and I’ve purchased Amnesia: The Dark Descent (which was on sale at the time, and I’ve been meaning to buy for some time anyway).

Desura’s (native Linux!) install is smooth and painless, and its (native Linux!) interface is pretty nice. It has some rough edges, to be fair: most of what it does is load websites that are skinned to feel like part of the interface (much like Steam does), and some of those pages are still obviously works in progress. On the other hand, everything works quickly and smoothly. The main options menu is accessed by clicking the Desura logo, which doesn’t look obviously like a button. So that’s a design flaw, but it didn’t take too long to work out. Redeeming gift keys is more streamlined than in Steam (once you find where to do it!).

Now, Desura certainly isn’t perfect, and it lacks very useful features that Steam has had for some time. One problem I noticed is that it lacks Steam’s resume-after-closing feature; I started to install Amnesia, absent-mindedly closed the client later, and it didn’t auto-resume after I opened Desura again. Desura doesn’t track how much time you’ve sunk into a given game. It also doesn’t have any way to access your save games from multiple locations (a la Steam’s cloud sync), and while their developer info mentions achievements, I haven’t seen any games implement Desura-specific achievements, nor would I even know where to look to find them.

Another feature that both Steam and Desura need are tags, or some sort of organizational system for your games. Right now all Desura has are ‘all games’ and ‘favorite games’. Steam has a categories system, but it doesn’t always save that information across accounts, and you can’t tag games with multiple categories. A proper tagging-based sorting system would be great.

So, Desura has a spartan interface, but it’s also still very young. And more importantly, it runs flawlessly in Linux, which makes it very appealing to me. If you game in Linux at all, check out Desura. It’s already a great service, and it looks like it’s only going to get better.

However, I have a problem with (most of) the available BitTorrent clients. Given what BitTorrent does, which is allow you to download and subsequently seed content, it should really run like a service – quietly running in the background handling your torrents. However, most of the clients for Linux work like Windows applications. They sit in your system tray, giving you “helpful” popup notifications. More importantly, they die if you logout. Luckily, I have found a solution.

Enter transmission-daemon

Transmission is one of the bittorrent clients for Linux that works like I described above – it’s a desktop application. However, it comes with a variant, transmisison-daemon, that can run in the background, as a dedicated ‘transmission’ user. This is much nicer.

Setting it up in fedora is pretty easy. Install the transmission-daemon package. Edit /etc/sysconfig/transmission-daemon to suit your needs. You can change TRANSMISSION_HOME to whatever directory you’d like your completed torrent files to live in (you do not need to modify the actual home directory of the transmission user, but do make sure TRANSMISSION_HOME is owned by that user).

Now, start transmission-daemon, then stop it again:

service transmission-daemon start
service transmission-daemon stop

That step created the transmission configuration files, which you can now find in $TRANSMISSION_HOME/.config/transmission-daemon/. The file you probably want to edit is settings.json. Edit this file to suit your needs, then start transmission again. To tell transmission to automatically start at boot, run:

chkconfig transmission-daemon on

transmission-remote – for all your transmission-related needs

So, now you have a daemonized BitTorrent client, running unobtrusively in the background. But how do you use it?

The answer is transmission-remote. This tool is an administrative front-end for transmission-daemon that lets you add, remove, start, stop, and view your torrents, and a lot more besides. To add a torrent, you can use ‘transmission-remote -a’ on either a local .torrent file or a URL, like so:

transmission-remote -a /path/to/file.torrent
transmission-remote -a http://example.com/file.torrent

Once the torrent is added, it will automatically start. You can get information on all your torrents with ‘transmission-remote -l’. Note that each torrent has a numeric ID assigned to it; you use that ID with the ‘-t’ option to tell transmission-remote to perform actions on the torrent. For example, to stop the torrent with ID 42, you could run:

transmission-remote -t 42 -S

transmission-remote can do a lot more; check its man page for details. In particular, the -s, -i, and –remove-and-delete are useful flags to know.

Making things easier – the watch directory

The problem with the approach I have described is that the command line, while great for interacting with your local torrents, is not the place most people go to look for torrents in the first place. More often, you find a .torrent file on the web, and having to open a terminal and run a command is an annoying extra step.

To make things easier, you can set up a watch directory; any .torrent files placed in that directory will automatically be added to transmission-daemon. To set up a watch directory, edit settings.json and add the following:

watch-dir-enabled: "true",
watch-dir: "/path/to/watch/dir",

(I have found it is best to always stop transmission-daemon before making changes to settings.json. It often overwrites settings at shutdown)

One caveat about the watch directory: when transmission-daemon is started, every .torrent file in there will be added. While this has no effect on torrents you are still downloading or seeding, torrents you have already removed will be re-added to transmission-daemon. For this reason, it is a good idea to routinely delete the files in your watch directory. You can use tmpwatch and/or cron to periodically delete the files.

Torrents from anywhere – using Dropbox with transmission-daemon

Dropbox is a fantastic tool for always having access to important files. Any files you put in your dropbox directory get automatically synced to every machine you use dropbox on. There are also Android, iOS, and web interfaces, so you can really get to your files from anywhere.

What does this have to do with transmission? Well, you can put your watch directory inside your dropbox directory. Any .torrent file you add to that directory – from any computer or phone – will automatically be started on the computer running transmission-daemons. This means you can start your torrents whenever you come across them, no matter where in the world you happen to be.

And if you have multiple people in your household who might all like to use one machine for BitTorrent, you can simply share your dropbox watch directory with all of them.

The way computers should behave – the world according to Anna

User interface design is a complicated thing, and a lot of research has gone into it. What a lot of UI discussions miss, though, is that everyone has different needs and preferences. The setup I have described here works the way I personally like best. It is transparent; that is, it gets out of your way and just does what it is supposed to do, with no fuss. It is powerful and flexible. For a Linux power user who prefers to use the command line where she can, it is hard to imagine a better BitTorrent solution.

Before we begin

You will need the following software for this tutorial. All of this software is free and open source.

• Blender, a professional 3d modelling tool. Blender is powerful but complex, and basic blender knowledge is assumed for this tutorial. Blender will be used to actually create the heightmap.
• The Gimp, a powerful program for creating and editing raster (i.e. normal) image files. The Gimp will be used for splitting the heightmap into RAW terrain files that OpenSim can use.
• gimpterrain, a plug-in for The Gimp that allows it to open and save RAW terrain files.
• terrainerizer (optional), a bash script I created to automate splitting the heightmap into RAW files. Terrainerizer only works on Linux, and still requires The Gimp and gimpterrain to be installed. It also requires ImageMagick.

In addition to the above software, you will also need a blank RAW terrain file. You could download a terrain file from OpenSim and transform it into a blank one (replace the Height layer with #ffffff, replace the factor layer with #808080), or you could just download this one that I have created for you.

Create a heightmap

A good tutorial on creating a generic heightmap in Blender can be found here.

The tutorial above creates a heightmap that is 512×512 pixels. However, an OpenSim RAW terrain file is only 256×256 pixels. This means that the above tutorial will create terrain for 4 regions, arranged in a square. If you need terrain for a different number of regions, you can modify the above tutorial to create different sized heightmaps.

For example, suppose you want to create an oblong island that is 2 regions by 4 regions in size. To do that:

1. Create the plane, but instead of scaling it to 2×2 blender units, scale it to 2×4 blender units. To do this, you can use this command sequence in blender:

• Right-click on the object to select it.
• Change the mode to Edit mode.
• Press ‘s’, ‘y’, ’2′, ‘return’.
• Press ‘s’, ‘x’, ’4′, ‘return’.

Now you should have a plane that is oblong instead of perfectly square.

2. When you configure the render settings, you will need to use different values.

• In the Scene settings (F10), SizeX and SizeY should be set to 256 * (number of regions). In our case, we have 2 regions in the Y dimension, and 4 regions in the X dimension. So, SizeX should be set to 1024, and SizeY should be set to 512.
• In the camera settings, the scale needs to be adjusted to fit the plane precisely. In our example, the scale should be set to 8. To get it just right, select the camera, and press Numpad0 to switch to camera view. You should see two concentric rectangles composed of dashed lines. Now, press F9 to view the Editing options for the camera. Now, adjust the Scale value until the outer dashed rectangle encompasses your plane completely, without including anything outside the plane. If the dashed rectangle is not the same shape as your plane, then you still need to set SizeX and SizeY in the Render settings.

Creating RAW terrain files with the Gimp

Now that you have a heightmap file, you still need to turn it into terrain files that can be uploaded into OpenSim.

Enter Domino Marama, creator of gimpterrain, an import/export plug-in for the Gimp that can handle the OpenSim RAW terrain format. Download gimpterrain and install it into your gimp plug-ins directory.

Now, if you are running Linux, you can automate the rest of this section with my terrainerizer script. See below.

We also need the blank terrain file that I mentioned earlier.

Armed with these tools, we can open a terrain file in the gimp and combine it with a portion of our heightmap.

1. Open your blank terrain file (blank.raw) and the heightmap in the Gimp.
2. Using the Rectangle Select tool, select a 256×256 pixel section of the heightmap, starting in the upper-left corner.
3. Click Edit -> Copy
4. Select the terrain file and make sure the Height layer is selected.
5. Click Edit -> Paste. You should see the section of the heightmap you copied appear as a floating layer.
6. Click Layer -> Anchor Layer. The Height layer should now look like the copied portion of the heightmap.
7. Click File -> Save As and save this file as a new file with the .raw extension.

Now, repeat this process for every 256×256 pixel section in your original heightmap.

Making it easier

Performing the steps in the previous section is very tedious, especially given how long it takes to save the terrain files. To make this easier, I have automated the process with the terrainerizer script.

If you are running Linux, simply put the terrainerizer script somewhere in your path. Edit it and specify the path to your blank.raw file, then run:

terrainerizer heightmap.png

Replace ‘heightmap.png’ with your heightmap file. Now let terrainerizer work. It will handle everything we did in the previous section automatically. It may take a while, depending on how large your heightmap is.

When it is finished, terrainerizer will leave several files in your current directory, named with this scheme:

heightmap-nxm.raw

Where ‘n’ and ‘m’ are numbers starting at 0 that represent the column and row for that terrain file. So, 0x0 is the top left region of your terrain, 0x1 is the next region (moving from top to bottom), and so on. Just upload these terrain files and you’re done!

Uploading the terrain files

Now that you have the terrain files, you can upload these files into OpenSim. There are two ways to do this.

1. From the OpenSim server console, you can simply:

change region RegionName
terrain load /path/to/terrain.raw

Repeat this for each of your regions.

2. From a viewer connected to OpenSim (assuming you are using Hippo or a similar viewer):

• Move to the region you where you want to upload terrain.
• Navigate to World -> Region/Estate -> Terrain
• Click “Upload RAW Terrain…” and select the terrain file you created for this region.

The Upload Terrain menu in Hippo

Repeat these steps for each region where you want to upload terrain.

Here is the result:

#!/bin/sh
echo -n "twitter> "
read text

while [ ${#text} -gt 140 ]; do

echo
echo "Message too long; used ${#text}/140 characters."
echo
echo -n "twitter> "
read text

done

echo
echo "Message is ${#text}/140 characters.  Press enter to post, or Ctrl+C to cancel."
read

curl --basic --user "username:password" --data-ascii "status=`echo $text|tr ' ' '+'`" "http://twitter.com/statuses/update.json" &> /dev/null


To use the script, copy all of that into a file somewhere in your path, then make the file executable (e.g., chmod 755 /usr/local/bin/twitter).  Now you can type ‘twitter’, type in your tweet, and you’re done!

I even set up fluxbox so that mod4+t launches a terminal with the script running.  To do that, I added this to ~/.fluxbox/keys:


Mod4 t :Exec xterm -e "twitter"


If you’re not familiar with ‘mod4′, it is the Windows key on most PC keyboards.

I’ll eventually get around to writing a slightly more full-featured twitter updater in c or c++.  Until then, enjoy this script!

Misconfiguration Most Foul

We begin our tale with NetworkManager.  Since I connect to several wireless networks and a VPN, NetworkManager is a very useful thing to have working.  Its initial setup was great; I loaded nm-applet in my fluxbox startup, it prompted me for a default keyring password, and we were off.

However, on my next boot I was not prompted for my keyring password; I had to enter my WEP key manually.  After some exploration, I learned that gnome-keyring-daemon needs to be running.  The paradox is that it WAS running.

A Red Herring

I found some rather old advice thas suggested I run gnome-keyring-daemon manually from ~/.fluxbox/startup, but this didn’t work; gnome-keyring-daemon starts automatically in Fedora 10, thanks to pam_gnome_keyring.so.  I now had two copies of the daemon now running, neither of which worked.

What I eventually discovered was this: if I kill the automatically-started gnome-keyring-daemon (or remove auto_start from the pam_gnome_keyring options in /etc/pam.d/kdm), then start it manually with different options, it works every time.  So, instead of:

gnome-keyring-daemon -d --login

which is the automatically provided command, I ran:

gnome-keyring-daemon -f -c keyring

from my fluxbox startup file.  This worked, but turned out to be unnecessary.

An Anwser

My next discovery:  If I disable the daemon’s automatic starting (once again by taking the auto_start option out of /etc/pam.d/kdm) and remove my custom invocation from the startup file, it still starts automatically, but with different options than the auto_start version!  In fact, it starts with the options work.

It turns out that nm-applet and gnome-screensaver both automatically start gnome-keyring-daemon if it isn’t running.  Since nm-applet runs first, it starts up the daemon, and passes it a completely different set of options than the pam-invoked version.  Thanks for the consistency, gnome!

A Problem

Starting gnome-keyring-daemon manually or allowing nm-applet to start it still poses a problem: the daemon doesn’t die when I log out!  This means that, as I log in and out several times, useless instances of the daemon end up sitting around doing nothing.  Since the apps that talk to the daemon use $GNOME_KEYRING_SOCKET to do so, everything keeps working; but it’s cruft I’d rather not have.

Elementary

After following this circuitous path, I finally stumbled into the answer: it’s a known bug.  It is actually related to the lack of a proper $DISPLAY getting set for gnome-keyring-daemon; it isn’t related to the passed in options at all.

At this point, I’m forced to fall back on a hack.  I’ve added the following to my ~/.fluxbox/startup, above the gnome-related apps:

killall gnome-keyring-daemon

I’ve also removed the auto_start option from /etc/pam.d/kdm.  Unfortunately, not launching the daemon with pam means that I can’t take advantage of the single sign-on feature provided by pam_gnome_keyring.  But until the bug is fixed, I guess this will have to be good enough.

(As for why I don’t use gdm, see this post)

Update: a command explained

If you look at the –help output for gnome-keyring-daemon (or, if you’ve applied my hack below, gnome-keyring-daemon-bin), you’ll see this output:

Usage:
gnome-keyring-daemon [OPTION...] - The Gnome Keyring Daemon

Application Options:
-f, --foreground Run in the foreground
-d, --daemonize Run as a daemon
-l, --login Use login password from stdin
-c, --components=ssh,keyring,pkcs11 The components to run

Anyone acquainted with Linux will understand the first two options, -f and -d, pretty intuitively. You’ll note in my post above that my ‘working’ option set included -f; this is because -f prints to standard out, allowing us to capture the GNOME_KEYRING_SOCKET and GNOME_KEYRING_PID variables that the daemon spits out. However, when run in -d, these variable seem to get set correctly anyway. Further, the -c option I used in my quest seems superfluous; the daemon defaults to using the keyring component. I wanted to explain this since it wasn’t clear in the original post exactly why I bounced between options. At the time, I was grasping at straws, and assigned a simple correlation (the different command-line options in use) to a causation (the daemon that started automatically, with the different options, failed to work correctly).

The option that had me baffled, though, was –login. The information in the help output is cryptic, but I finally worked out its purpose; it allows single sign-on. pam_gnome_keyring passes your login password to gnome-keyring-daemon, which uses it to unlock a special keyring called the login keyring. This keyring can then be used to store the passwords to your other keyrings, so that when you log in, everything unlocks automatically. Your system login doubles as your keyring authentication.

Further Update: Eureka! (or: building a better hack)

Based on a comment in the bugzilla entry for this problem, I have crafted a better (if more system-intrusive) hack. I simply perform the following:

mv /usr/bin/gnome-keyring-daemon /usr/bin/gnome-keyring-daemon-bin
touch /usr/bin/gnome-keyring-daemon
chmod 755 /usr/bin/gnome-keyring-daemon
cat > /usr/bin/gnome-keyring-daemon << EOF
#!/bin/sh
DISPLAY=":0.0" /usr/bin/gnome-keyring-daemon-bin "\$@"
EOF

This hack creates a wrapper script that sets the $DISPLAY variable before running the keyring daemon. Until this kdm bug is worked out, this hack performs beautifully.

First, a summary, for those who get a case of the tl;dr’s.  A woman bought a laptop to use for her coursework at a local college.  She accidentally bought a Dell laptop with Ubuntu on it.  When she realized her ISP’s setup disk wouldn’t work, she tried to get Dell to swap the laptop for one with Windows.  The Dell representative apparently convinced her to keep the one she had.

She claims that this problem, combined with a lack of Microsoft Office, forced her to withdraw from classes.  The local news ran the linked article; it is worth noting that the bottom portion (the part where the news agency contacted the college and Verizon, and everything got cleaned up) did not appear in the initial article.

Needless to say, the Linux community (and the Ubuntu community in particular) exploded.  The article hit digg, slashdot, and reddit.  The angry letters and phone calls started pouring in to the news station (though they got tons of traffic, naturally).  More significantly, the woman in question was harassed on facebook.

This story shows mistakes from every party involved.  The Dell representative should have helped her switch to a machine she was more comfortable with.  The woman herself should have taken initiative, called Verizon and asked what she could do to get her connection working.  Alternately, what’s wrong with using another computer (say, at a local library) until you can get the laptop issue sorted out?  Dropping all your classes for the semester is overly drastic and melodramatic.

The worst perpetrators of stupidity here, though, are the Linux community members who not only lambasted and ridiculed this woman publicly on forums and blogs, but also attacked her personally on her Facebook account.  This is childish, pointless, and it paints the entire Linux community as anti-social assholes.

Unlike most groups, the Linux community IS Linux.  If a Star Wars fan blogs about how everyone who doesn’t know the difference between a Sith and a Dark Jedi is an idiot, the Star Wars franchise is not going to be damaged; there is a clear disparity between the creators (Lucasfilm et al) and the consumers (fans).  On the other hand, if a Linux fanboy blogs that everyone should know the intricacies of iptables configuration before being allowed on the Internet, this will color peoples’ perception of Linux.

Why does this happen?  Because Linux is Free, open to the world.  Anyone can add to it.  The community and the product are intricately intertwined.

This is a false perception, though; in reality, the rabid fanboys who would harass a woman on Facebook are a completely different set of people than the assholes that argue fine technical points on LKML. (I’m using asshole here in its rare application as a compliment)  However, the impression that an outsider has looking in is that Linux is some wild, anarchistic (or maybe communist) creation.  This stems from the growing cultural knowledge that Linux was created by and for the people that use it.  This is not quite true.  Linux was created by and for developers and technology enthusiasts, true.  However, not every vocal member of the community actually contributes to Linux itself; only a fairly small subset of users are actively involved in improving the software.

I don’t mean to devalue the role of the community in development.  Community contributors are important, welcome, and numerous.  Bug submitters and other “active users” are vital to the strength of the open development model.  However, the active users aren’t even the people that we see evident in this article.  What we see here are fanboys:

fanboy (n): Someone who is so obsessed with some subject or thing that they are blind to its faults and harass and deride anyone whose opinion differs.

These are precisely the people that Linux does not need.  The community would be doing itself a favor by creating public distance from this subset of itself.  We need more rational, clear-headed people speaking out about the benefits of Linux.  Fanboys ranting and harassing people will get us nowhere.

First, a little background.  I switched to Fedora from a mixture of gentoo and slackware around the time I started my current job, since it was far easier to keep track of one package management toolset, and several things about gentoo’s packaging system had started to irk me.  The current release of Fedora at the time was 7.  I have been using it since, usually upgrading to new releases (via a clean install) about a month after they release.

My needs are simple, but apparently elusive to Fedora.  I use fluxbox as my window manager.  I prefer to perform all of my system configuration from the command line.  My graphical application use is minimal (firefox, games, pidgin).

Let’s explore the problems I’ve noticed have started creeping in, starting with the release of fedora 8.  My solution/workaround for each problem is included, if I have one.  For what it is worth, I realize that some of these could be the result of 3rd-party packages (such as Nvidia’s proprietary drivers).  However, if any of these are the result of user error, then the solution should rightly be easy to find by searching documentation, which I have done extensively in every case.

1. Pulseaudio

Pulseaudio… I hate the word

This one heads the list because it’s the problem I’ve had to deal with most recently.  I have been lucky in that pulseaudio plays nicely with the sound cards on all 3 of my Fedora machines (others have been less fortunate).  However, I was stuck with audio far quieter than what I had grown used to in gentoo.

Solution: I finally discovered that pulseaudio has its own volume settings, independent of the ALSA-level audio device.  You can adjust the hardware volume levels with either of these commands:

alsamixer -Dhw:0
alsamixer -c 0

It would be nice if this were clearly documented somewhere.  There are some vague hints on this page, which is what pointed me in the right direction.

Thankfully, pulseaudio is no longer quite so painful when dealing with apps that only talk to ALSA.  I noticed some popping in certain applications, though (Neverwinter Nights, for one).  pasuspender seems to work around this, but the fact that this is necessary is kludgy.

2. GDM

The thousand injuries of GDM I had borne as best I could; but when he ventured upon insult, I vowed revenge…

GDM in Fedora has been upgraded to the latest upstream from the gnome team.  The problem with this version of GDM is that it removes almost all of its configuration options.  They have crippled it thus intentionally, and while they claim the removed options were “obsoleted due to redesign”, it seems that some of the options were dropped to prevent users from doing stupid things.

This Lowest Common Denominator approach is fine for a default configuration, but it should always be possible to change the default behavior.  Removing the ability to customize it entirely is not only against the spirit of open source software and Linux, it is insulting to the users.  It feels as if the team responsible for GDM thinks they know better than I do when it comes to configuring my machine.

In my case, the default behavior that troubles me is the fact that GDM passes the +accessx option to X.  Gnome includes a daemon that can override the accessx behavior (namely, enabling sticky keys if you hold shift down too long).  KDE includes a similar tool.  Fluxbox, however, has none – it assumes (justly) that you can turn off the accessx option at the X11 level if you don’t want it.  The new GDM denies you this ability, however.

Solution: Switched to KDM, which doesn’t seem to enable +accessx by default.  I tried XDM first, but it has SELinux errors and fails to launch fluxbox.  Also, KDM looks much nicer.  Alternately, I could have booted into runlevel 3 and then used startx, but I’ve become a fan of the graphical login prompt.

3. Upstart

The name says it all

upstart is the new init system in fedora; a replacement for the aging sysVinit.  In theory, upstart is great – gives you much more granular control over what processes should happen at each runlevel, and may eventually replace /etc/init.d entirely.  In practice, however, it has a rather annoying problem: sometimes it fails to respawn the ttys when in runlevel 5.  This problem doesn’t seem to be present in runlevel 3, for whatever reason.

Solution: no real solution at present, but you can work around it with initctl start ttyX

4. rsyslog

Hey… Listen!

The traditional syslogd has been replaced with rsyslog, a much more powerful/configurable syslog daemon.  However, it seems to dump all kernel output to the console.  The default configuration doesn’t include any statements that should be logging to the console, so it could be caused by something else.  Either way, the problem is present.

You can test this from any fedora machine: it seems to happen on every F10 box I can find.  Just press Ctrl+Alt+F2, then plug in a USB flash drive.  This is annoying on its own, but is especially frustrating when combined with #5, below.

Solution: none

5. PCI-Express device errors

Or How I Learned to Stop Worrying and Love X.org

On my PCI-Express video card, I receive constant error messages, both in messages and on the console (see #4, above).  These happen whenever the screen is cleared or switched to.  In other words, Ctrl+Alt+FX will generate one of these, sometimes two.  Running ‘less’ generates the errors.  So does the ‘clear’ command.  emacs and vi both trigger the error.  Each instance of the error takes up about 25% of the screen’s real estate.  This makes operating on the command line extremely difficult.

Solution: None yet.  I suspect this may be related to the Nvidia drivers; in that case, a future update may fix these errors.  I’ll give Fedora the benefit of the doubt where I can.

First, the user (me) inserts a USB flash drive with an encrypted partition.  He mounts up the encrypted disk on a local machine (I’ll call this machine the ‘client’ throughout this article), providing the necessary password, and runs a script called ‘callhome’.  He is prompted for his passphrase, and then gets a terminal session on his home machine (we’ll call this one the ‘server’).

Read on for details about this setup, and how to do it.

Warning: what follows is madness. It is overkill taken to an extreme.  I am describing a way you can take a very, very simple procedure (connecting remotely to a system), and make it exceedingly complicated, all for the benefit of a little added security.  Whether or not this security is worthwhile to you is, of course, your business.  In an age where our governments and fellow citizens are increasingly keen on everything from our shopping and reading habits to our credit card numbers, I personally feel that cautiousness is worth the effort.

It is madness.  I’m not convinced it isn’t justified madness.

This tutorial assumes you are running Linux, and that you are comfortable with the command-line interface and with networked computing in general (of course, you’re reading this on the Internet, so that’s a good start).  All of my examples will be Fedora-centric.  If you don’t use Fedora, you’ll need to figure out what the commands are for your distro.

So, how is this complex setup I describe different from just typing “ssh user@server”?  Well, first, the callhome script executes a portknocking sequence.  Until this sequence is done, ssh is closed on the server.  After the sequence, ssh is opened only for the IP address of the client, and only for a small time window.  The ssh connection must happen during this window.  The script initiates the ssh connection, which helps keep this secure.  In addition, each portknocking sequence is valid only once – the USB drive contains a list of all valid sequences, and the script is set up to only use each one once.

Next, ssh on our server is set up to only allow connections with public keys.  This means that even if an attacker knew the correct portknocking sequence, he would not be able to login with a password – he must have the private RSA key.  The private key is on our USB flash drive, which is encrypted.  The key itself is further encrypted with its own passphrase, so you still enter a password to connect home, the work to verify it is simply done on the local machine.  The passphrase is never sent across the Internet, even in an encrypted/hashed form.

There are some other nice features, including a ‘panic’ portknocking sequence that will shut down the portknocking server itself, locking down the remote server completely.  This panic script is stored on a machine to which I have a shell account.  If the USB flash drive is ever lost/stolen, I can get to any machine with an ssh client, log in to the shell account, and kill the knock server.  New connections to the server then become impossible.

This setup is useful for more than just a terminal connection home.  You can forward X through it and run graphical apps from home (this is typically going to be very slow, however).  You can forward any ports you like, so that you can route web traffic through this ssh tunnel and prevent people on your network from watching where you go on the web.  Anything you can do with a normal ssh connection can be done here.  Later I’ll demonstrate some examples that I use. So, that’s the setup.

Now I will outline exactly how to do it, one step at a time.  You might want to grab a snack and use the bathroom – this is going to be a long trip.

Part 1: Dynamic DNS

Before you can call home to your server, it helps to have a name to call it by.  However, you can’t use a traditional hostname if your machine is on a broadband network because your IP address may periodically change.  Dynamic DNS (or DynDNS) was created to solve this problem.  A daemon runs on your server that periodically checks the IP address of the server and sends it to a DynDNS server.  This DynDNS server then updates a DNS record whenever your IP address changes. I use DynDNS.com.  It’s free and easy.  Just choose a hostname for your machine, then install and configure the ddclient software.  You can get instructions on configuring ddclient for DynDNS.com here.

Part 2: Configuring SSH

On the server, find your sshd configuration file (on Fedora, this is at /etc/ssh/sshd_config) and ensure the following options are set to these values:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no

Now, restart your ssh daemon:

service sshd restart

Now, try to ssh into your machine (you can just do ‘ssh user@localhost’).  You’ll get denied immediately, without even seeing a password prompt.  This is what we want. Next, we create the ssh key that we will use.  Run:

ssh-keygen -t rsa -b 4096

When prompted, specify a path other than the default.  Your home directory is a good choice – we will be moving id_rsa to the USB flash drive later.  Also, make sure you specify a good passphrase – if the USB flash drive is compromised, the strength of this passphrase will buy you time to lock down the server. Now you have 2 files in your home directory, id_rsa and id_rsa.pub.  id_rsa is your encrypted, private RSA key.  id_rsa.pub is the public key that matches this private key.  Copy the contents of id_rsa.pub into ~/.ssh/authorized_keys.  This step will allow the private key to connect to the server as this user.

Part 3: portknocking

There’s still one significant security concern: unknown vulnerabilities.  OpenSSH is a complex program, and almost certainly still contains a vulnerability or two that haven’t been discovered.  To combat getting hit with that latest exploit, we can hide the presence of ssh from the outside world completely.  This is the beauty of portknocking. The premise of portknocking is that the ssh port is firewalled off unless a specific sequence of ports are first pinged, in order.  This doesn’t add a lot of security by itself; an attacker can simply sniff the portknock sequence, then repeat it to open the same port.  Normally, portknocking will only deter attackers who don’t know you have ssh open.

However, the portknocking server we are going to use supports one-time sequences.  With this configuration, the correct knock sequence changes after each knock.  The server has a list of sequences to use, and we will also keep this list with us on the USB flash drive. Before we begin configuring portknocking, make sure you have firewalled off port 22.  There are two possible network setups we will consider:

• You have a router between the server and the Internet.  This router passes ssh traffic to your server, and the router acts as the firewall that blocks ssh access.
• The server is connected directly to the Internet.  Local firewall rules on the machine are blocking ssh access.

In the first instance, you need to be able to install a portknocking server on the router; additionally, the firewall rules needed will be more complicated, and will vary based on how your router is configured.  My example here assumes the second case: that the server itself is listening to the knocks (i.e. it is directly connected to the Internet).  The first case is discussed in Appendix C.  Install knockd.  Once installed, you’ll need to configure /etc/knockd.conf.  For now, I’ll present a basic configuration (we’ll add some more stuff to this later):

[options]
logfile = /var/log/knockd.log

[ssh]
one_time_sequences = /etc/knockd/ssh
seq_timeout = 10
tcpflags = syn
start_command = /usr/sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
cmd_timeout = 5
stop_command = /usr/sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT

In /etc/knockd/ssh, you need to have sequences of numbers to use as one-time sequences.  Each entry in the list should be formatted like this:

1,2,3,4,5

There is a space at the beginning of the line; this is helpful because knockd will comment out each line as it uses it by placing a ‘#’ at the beginning of the line.  The numbers you generate should ideally be between 1024 and 65535; I generate my numbers with a script similar to the following:

#!/usr/bin/perl
$num_keys = 50;
@data = `d20diceroller --nototals "5d65535[reroll< 1024][repeat $num_keys]"`;

foreach (@data)
{
next if (/:/);

s/ $//;
s/ /,/g;
s/^/ /;

print;
}

This script uses a program I created, d20diceroller, to generate its random numbers.  That tool is part of the d20tools package, and can be found at its sourceforge page.  The subversion repository is currently recommended. Now that you have the one-time sequences, you must start the knock daemon.  You’ll most likely want to add this to an init script (such as /etc/rc.local):

knockd -i eth0 &

‘eth0′ here should be replaced with whatever the name of your Internet-facing network interface is. Now, portknocking is configured and running.  We only need to configure the USB flash drive, and we’re done with the basics.

Part 4: USB Flash drive setup

First, you need a partition on the flash drive that will be dedicated as the encrypted partition.  This can be one small partition, or it can be the entire disk.  I set aside the last 10 MB of the disk, myself.  Use fdisk, parted, or another partitioning tool to get the disk to your liking (remember, re-partitioning can erase everything you have on the drive.  Be careful). Once the disk is partitioned, you must create a secure volume, then create a filesystem on that volume.  As root, run the command:

cryptsetup create secure /dev/sda1

Where ‘/dev/sda1′ is the device name of the partition that should be the encrypted partition.  Enter your desired passphrase when prompted.  This should be a different passphrase than you used with the ssh key, ideally.  Now, you should have a device file named /dev/mapper/secure.  This is the encrypted pseudo-device Linux has created to represent your partition.  Create a filesystem on it.  I recommend a DOS filesystem because of its portability (an ext3 filesystem will retain the UID/GID and permissions for each file, which can get really confusing when moving from system to system and using users with different UIDs):

mkdosfs -F 16 /dev/mapper/secure

Now mount /dev/mapper/secure.  On it, create a directory called .ssh.  Copy the id_rsa file you created earlier into this directory, and create a file called ‘config’ that looks like this:

Host your.server.address home
User your_user_name
UserKnownHostsFile .ssh/known_hosts
HostName your.server.address
Port 22
IdentityFile .ssh/id_rsa
Compression yes

Also, take a copy of the sequences you created earlier (in /etc/knockd/ssh) and copy them to a file called ‘sequences’ in this .ssh directory.  You need to modify this sequences file so that the commas are converted to spaces.  You can do that with this command:

perl -p -i -e 's/,/ /' sequences

Now, create a script in the root of the encrypted partition with these contents:

#!/bin/sh
SERVER_NAME=your.server.name
WD=$(echo $0 | perl -pe 's/^(.*)\/.*?$/\1/')
cd $WD
chmod 600 $WD/.ssh/id_rsa &> /dev/null
sequence=`head -n 1 $WD/.ssh/sequences`
[ -z "$sequence" ] && echo "Error: No more knock sequences" && exit 1
for i in $sequence;
do nc -z $SERVER_NAME $i; done
sleep 1
ssh -F $WD/.ssh/config home && sed -i '1d' $WD/.ssh/sequences

This script will execute the next portknocking sequence in the list, then automatically ssh into the server.  It uses the config file in our local .ssh directory, so the username and key file are already specified. Now, to unmount the USB flash drive’s encrypted partition, you can execute these commands:

umount /dev/mapper/secure
cryptsetup remove secure

That’s it!  Now, all you need to do use the system is set up the partition as an encrypted volume, mount the encrypted filesystem, run the ‘callhome’ script, and enter your ssh passphrase.  Extra-secure connection home, for the truly paranoid.  The only upkeep required is to periodically generate a new list of sequences when you run low.  This system is a bit more complicated than just using an ssh command, but I discuss how to automate the connection procedure on systems you use a lot in Appendix B.

But wait, there’s more!  What happens when The Bad Guys steal our USB flash drive and start frantically trying to decrypt it?  Enter the panic knock.

Part 5: Disaster recovery

A scenario, if you will.  You’re sitting at your desk, your uber-secure connection home humming along, letting you chat on IRC without your boss being any wiser.  You lock your X session and get up to grab some coffee.  You get back to your desk, and glance over at your workstation, expecting to see protruding from the front your faithful USB flash drive, fast friend these many years, steadfast companion against the dangers of revealing your personal life’s details to those who would kill for it.  But it’s gone.  Someone has taken it. A quick survey of your fellow workers (and by “survey” we mean “threaten them with violence so they know you’re serious”) reveals that they don’t have it.  No one saw anyone come near your desk.

There is only one explanation: Identity Theft Ninja.  Trained in the secluded mountains of Japan from birth, these versatile agents of stealth can smell a USB flash drive that allows a connection to someone’s home server from a league distant.  You never had a chance. Hope is not lost, however!  Because the drive is encrypted, and the ssh key is further encrypted, you have an advantage.  The Identity Theft Ninja have powerful computers for cracking encryption schemes, but it will still take time.

Basically, when you notice your USB drive is missing, you can execute your panic script. The panic script should live on a shell server; something you can get to from any machine.  I recommend silenceisdefeat.  On the shell server, you simply have a script called ‘panic’.  It can look like the following:

#!/bin/sh
SERVER_NAME=your.server.name
sequence=("1" "2" "3" "4" "5")

for i in ${sequence[@]};
do nc -z $SERVER_NAME $i;
done

Most shell servers will not give you execute privileges, but because this is a script, you can simply type ‘sh panic’ to execute it. On the knock server, we have a special action to perform when someone executes that particular sequence.  Add this to /etc/knockd.conf:

[shutdown]
sequence = 1,2,3,4,5
seq_timeout = 10
tcpflags = syn
command = killall knockd

By the way, do not actually use the sequence 1 2 3 4 5.  Use a random sequence, but include a number that will never appear in your normal portknocking sequences.  The ‘out of phase’ number guarantees you never accidentally shut down the server, and keeping the sequence random guarantees that a portscan or other malicious attack won’t lock you out down your server.  It would be a good idea to change this sequence every time you use it, as well, to prevent an attacker from repeating the sequence to frustrate you.

Appendix A: Beyond SSH – forwarding other traffic

You can take advantage of the power of SSH to create an extremely secure tunnel for almost any data; you aren’t limited to running commands on your remote machine. Perhaps you want to browse the web through the encrypted tunnel, so other users on the network can’t see that you’re really shopping on newegg instead of getting work done.  In that case, you could add this to your .ssh/config file:

DynamicForward 8137

This creates a SOCKS proxy that you can route traffic through.  Simply configure your web browser to use a proxy at localhost, port 8137.  If you want to tunnel certain sites through the proxy but not others (and you use Firefox), check out FoxyProxy. Check the command ‘man ssh_config’ for more options you can put in the .ssh/config file.

Appendix B: Mounting your encrypted volume made easy

You need root access to create and mount an encrypted volume.  If you use the same few computers all the time (and you have root access on them), you can simplify your life.  First, use the ‘visudo’ command and add a line to the end of the sudoers file like this:

your_user ALL=(root) NOPASSWD: /sbin/cryptsetup

This will allow you, as a normal user, to execute ‘cryptsetup’, which lets you create and remove encrypted volumes.  Next, add a line like this to /etc/fstab:

/dev/mapper/secure /mnt/secure auto noauto,user,umask=077 0 0

This will allow users to mount /dev/mapper/secure once it is created.  The umask guarantees other users on the system can’t see our files, which would compromise the ssh key.  Don’t worry, we can still prevent another user on the system from hijacking our mount; that comes next. Now, create two files in /usr/local/bin, called ‘secureon’ and ‘secureoff’.  In secureon, put:

#!/bin/sh
sudo cryptsetup create secure /dev/sda1 && \
mount /mnt/secure

sda1, of course, is whatever the device name of the encrypted partition is.  You can use udev or hal to ensure this is always a consistent name.  secureoff looks like this:

#!/bin/sh
umount /mnt/secure && \
sudo cryptsetup remove secure

Make both of these scripts executable (‘chmod 755 /usr/local/bin/secureo*’).  Now you can simply run ‘secureon to create and mount the secure volume (you’ll be prompted for the encryption passphrase), and ‘secureoff’ when you’re finished.

Appendix C: Behind a router

The last case we will consider is the complex but extremely common situation where you have one device acting as a router.  This changes the iptables rules we need to use with the knockd server.

First, you need to have a router that  you can install Linux software on.  In other words, your router must be running Linux.  If you have a computer acting as your router, this is probably no problem for you.  If you have a consumer broadband router, this may be more difficult.  You can get Linux firmware for certain models of broadband router, however.  Several broadband router distributions exist; I use OpenWRT; it is easy to install new software with OpenWRT, and knockd is available for it.

The exact rules you will need are going to depend on your particular iptables setup, but to forward a port you will need two rules:  one in the filter table’s FORWARD chain and one in the nat table’s PREROUTING chain.  The approach that I recommend is to add the rule in the FORWARD chain permanently, and use knockd to add and remove the PREROUTING rule.  This simplifies the knockd configuration, and allows you to use the FORWARD chain as a handy reference for what forwards are possible.

For example, let’s say you have a machine at 10.10.9.18, and the knock daemon will open SSH to this machine.  First, you want to add this firewall rule permanently:

iptables -A FORWARD -p tcp --dport 22 -d 10.10.9.18 -j ACCEPT

Put that in your router’s iptables configuration.  If your router is running Fedora, put this line (minus ‘iptables’) in /etc/sysconfig/iptables.

If you’re using OpenWRT, I would suggest using the forwarding_wan chain instead of the FORWARD chain.  Also, on OpenWRT you can put this line in /etc/firewall.user.

The start_command and stop_command lines in /etc/knockd.conf will add and remove the PREROUTING rule, like so:

start_command = /usr/sbin/iptables -t nat -A PREROUTING -s %IP% -p tcp --dport 22 -j DNAT --to 10.10.9.18:22
stop_command = /usr/sbin/iptables -t nat -D PREROUTING -s %IP% -p tcp --dport 22 -j DNAT --to 10.10.9.18:22

For OpenWRT, use the prerouting_wan chain instead of the  PREROUTING chain.

One great thing you can do with a router is use different knock sequences to forward SSH to different servers.  If you have several machines on your network, you can simply add additional sections to knockd.conf (and additional rules in the FORWARD chain).  As long as they use different knock sequences, you can overload port 22 to forward to whichever machine you need.

In the last year, whenever someone talks about “whether Linux is ready for the desktop”, the complaints that always crop up revolve around the fact that a user can’t throw in a Linux install CD, click next a few times, and have a fully functional desktop environment in half an hour. Several things plague these proverbial users: the lack of mp3 support is probably the most problematic now, as is the lack of 3d graphics support. The complaints further, er… complain, that the user has to know what she is doing to enable/install all of these components.

What most people overlook, though, is that installing Windows is no cakewalk, either. Windows ships with almost no real video or audio hardware support – everything must be downloaded from 3rd party websites, and more importantly, the user has to *know* what vendor website to go to, and how to navigate the vendor’s site (with some vendors, that can be a real pain!).

So now, let’s be fair. I’m taking a Windows XP install, out of the box, and comparing it side-by-side with an Ubuntu Linux install. Okay, here goes.

As a user, I have to install several non-free packages, which means changing my available repositories and running a few commands (or using the graphical tool). If I prefer the less-questionably-legal route, I would purchase Fluendo (28E for their entire set of plugins, with perputual updates, as of this writing. Still about 1/4 the price of Windows’ most basic version), and follow their instructions to install it.

Of course, I also have to *know* about these options. A quick google search (“MP3s in Ubuntu”) and a forum gives me the answer, in step-by-step format.

This is even easier. All we need is to install the nvidia-glx or xorg-driver-fglrx packages, depending on the card. They’re also in the restricted repository, but we’ve already enabled it previously. If we hadn’t, the google search “3d graphics in Ubuntu” gives us the correct answer immediately.

Another quick google search turns up the answer, as always with step-by-step instructions.

And, that’s it. Everything else I need to do to be productive is already provided by Ubuntu: web browser, office suite, multimedia software. Note: I never had to restart Ubuntu during this whole process.

First, I have to figure out the name of my audio chip, which Windows doesn’t tell me. All Windows will say is “Unknown Multimedia device”. By booting Linux and running lspci, I discover it’s a C-Media chip, and go to their website. I have to give them the exact chip model number, and they give me a driver to download. I have to restart Windows.

Again, the video controller is just called an “Unknown display adapter”. Foreknowledge tells me I have an Nvidia Geforce 6600 GT. I go to Nvidia’s website (much easier to use than C-Media was), and get the driver. I have to restart Windows.

Well, this one installs automatically. Doesn’t even need a restart! 1/3 isn’t bad, I suppose.

What’s the point of this exercise? Am I trying to say Windows is teh sux0r? No, that’s not my message today. I could extoll the myriad problems with Windows that make Linux a better option (spyware, viruses, openness and all the benefits thereof, etc), but that’s not the point.

The point is this: when it comes to installation, Linux and Windows are roughly equivalent in complexity. Linux has its installation issues; so does Windows. They tend to break roughly even, in my experience, although Linux has a much more readily available support structure in the form of community forums. But both OSes require a lot of user knowledge in order to get up and running. They assume you already know how to do things. What they really assume, underneath, is that

Most Windows users never install their OS; some technician installs it, either OEM at a factory, or at the local computer shop, or the in-law programmer who gets drafted for technical work (ahem…). Linux users have seldom known this luxury; instead, whenever someone talks about Linux, they assume that the end user is doing the install.

The solution is to treat Linux installation the way we treat Windows installation. Someone who Knows What They Are Doing ™ sets up the OS and delivers it to the end user. One practical advantage for the Linux community is that all the time spent on fancy installers could be channeled elsewhere (not to say we don’t like our hardware auto-detection, et al. But a curses-based menu is just fine, thanks). Make Linux installation work like OS installation always has before: technical users install their own OS, everyone else leaves it to the techs.

At least don’t hold us to a double standard.

Where have I seen this kind of threat before? Hmm… SCO, anyone? Is MS really desperate enough for that? SCO only sued IBM because they were losing money in copious amounts, flirting with bankruptcy. Vista seems to be the straw that’s breaking Microsoft’s back.