ZenLinux Blog

Last year marked a new first for Portland, OR – the birth of the Open Source Bridge technical conference. In a previous post I expressed a great deal of enthusiasm about how awesome last year’s event was. Those weren’t just kind words – I found myself moved enough by the incredible activism and community in the Portland tech scene to get involved for this year’s conference as a volunteer. That’s right, Open Source Bridge is back in 2010! June 1-4, to be exact.

This year’s event has an outstanding presentation lineup and will be held at the Mark Building of the Portland Art Museum. I had a chance to tour the venue with the OSB organizing crew and must say that the location is really unique, inspiring, and truly fitting for a conference of people who are working to improve the world through quality open source software projects. There will once again be a 24-hour hacker lounge (a major highlight from last year), this time on-site at the Mark Building.

One of the great things about OSB is that it’s a very diverse gathering of open source citizens, and offers a great opportunity to expand your horizons to learn about tools and platforms you may not have encountered before. I will also be giving a variation of my PLUG Advanced Topics talk on OpenEmbedded if embedded Linux systems pique your interest.

Check out the Open Source Bridge website to learn more and register. Trust me – it’s gonna rock your socks.

A big warning to the many users behind a proxy server who will be installing Ubuntu Lucid Lynx soon: wget isn’t going to work. You can read the details in this bug report on Launchpad.

Basically the problem is that if your proxy exclusion list ends with a comma character, wget can’t parse the $no_proxy environment variable and defaults to not using your proxy (usually configured in ~/.wgetrc or via the $http_proxy/$ftp_proxy environment variables). And the GNOME Network Proxy UI apparently leaves a trailing comma in there if you make changes to the ignored hosts list.

The quick workaround is to add the following to your ~/.bashrc:

export no_proxy=$(echo $no_proxy | sed 's/,$//')

I spent a couple of days figuring this out, so I hope it helps someone else. I don’t see any way the fix will be included in Lucid before it ships on Thursday, so people will need to use this workaround until then. It’s a shame because as an LTS release, a lot of enterprise users are going to run into problems right out of the gate.

SpamAssassin is one of those mission-critical services that I run on my mail server, and if you haven’t heard, there is a bug in SpamAssassin that has been marking legitimate messages (ham) as spam if the date of the email was 2010 or later. Now that it really is 2010, this is a serious problem. More details about the bug can be found here.

I’ve confirmed that my CentOS 5.4 install was vulnerable and I had to apply a workaround. There are a couple of ways to do this. You can either edit your local.cf file and disable the rule with the following line (on CentOS it’s in /etc/mail/spamassassin/local.cf):

score FH_DATE_PAST_20XX 0.0

Or you can enable the cron job to run sa-update nightly, which I would recommend. My CentOS system had the cron entry commented out in /etc/cron.d/sa-update, so I uncommented it.

If you’re running spamd on your system, don’t forget to restart the service for the new rules to be reloaded.

I feel the need to spread this ssh tip that saves me from quite a bit of typing on a daily basis. I learned about it from Elliott’s OS X Tips and Tricks post on the Carsonified blog.

Add the following to your ~/.ssh/config file:

Host *
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

Now when you ssh into a host, subsequent connections to that host use the same TCP socket, and don’t require authentication. This will be the case for as long as that initial connection stays open, and it works for sftp as well as ssh.

I realize another way of avoiding typing your password all the time is to use ssh keys, but I happen to work on embedded systems that get rebuilt very frequently and which I’m not able set up an ssh key as part of the build process. This technique allows me to log into the system once per session and not have to type the password over and over again.

For years now I’ve maintained my own rsync-based shell scripts to “synchronize” my web browser bookmarks and email client address book between the various computers I use at home and at work. The scripts didn’t actually synchronize changes – they were more of a way of pushing or pulling changes, and I’ve developed a diligence in keeping track of what’s most up to date to avoid clobbering the data I want to keep.

Recently I started using the Foxmarks Firefox extension for managing my bookmarks, and it has worked flawlessly. This free plugin does true synchronization – meaning I can add or delete bookmarks at will on any machine at any time and distribute my changes without losing any data. This kind of bookmark sync service has been around for a while, but Foxmarks allows me to store my data on my own server – a key feature I had been waiting for for some time. All I needed to do was add WebDAV support to my Apache setup. It even works with https and authentication.

So checkout Foxmarks if you need to keep your Firefox bookmarks synchronized. I believe it also supports sync’ing password data too, but I’m too much of a security geek to keep passwords stored in my browser.

Thanks to everyone who came out for the NH Ruby and Rails User Group meeting last night. I think the three-topic format worked really well, and offered something for everyone.

As promised, I have added a page to our wiki with a command-by-command reference for setting up your Linode VPS quickly for the Rails Rumble programming competition. I hope it’s useful for people looking to spend more time during the Rumble working on your app rather than configuring your deployment server.

Secure shell (ssh) uses cryptographic keys to uniquely identify (fingerprint) the hosts that you connect to. Once you connect to a new host, the fingerprint string is added to a file called known_hosts in your ~/.ssh directory. Then, every time you reconnect to that host, the fingerprint is checked to ensure it hasn’t changed.

This is an important security feature, because if the saved fingerprint doesn’t match, it could be because someone is maliciously spoofing the server you’re trying to connect to as part of a man-in-the-middle (MITM) type attack. However, in this modern age, some of us have local networks with numerous devices/laptops which change their IP address regularly due to DHCP. When this happens and you ssh to a device now using the same IP that a previous device used (and for which you have the host fingerprint saved), you get a nastygram from ssh and it refuses to allow you to connect to the device. Then you must clear the fingerprint from your ~/.ssh/known_hosts file and reconnect. This gets old really quickly.

So I spent some time today reviewing ssh configuration options to disable this host key checking for my home network subnet. Upon first glance, the StrictHostKeyChecking option seems like the one you’d want to change, but in fact setting it to “no” still does not allow you to ssh to a host when the saved fingerprint doesn’t match up.

In resignation, I instead hacked up a different solution, and now tell ssh to use /dev/null instead of ~/.ssh/known_hosts as where to save host keys for my local subnet. If anyone knows a better solution to this, please enlighten me. Here is my final ~/.ssh/config file:

Host 192.168.1.*
StrictHostKeyChecking no
UserKnownHostsFile /dev/null

Note that for hosts outside of my home subnet, the host key checking is still enforced (as it should be).

I recently updated my Rails deployment server from CentOS 4 to CentOS 5, and immediately ran into the following error when deploying my apps using vlad:

sudo: sorry, you must have a tty to run sudo

Thus apache wasn’t being restarted after my mongrel instances. It turns out that RHEL/CentOS 5 includes added restrictions in its default sudo configuration. Simply comment out the following line in /etc/sudoers:

#Defaults requiretty

to resolve the problem.