ZenLinux Blog

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.

Vlad the Deployer is currently broken with rake v0.8. You can either downgrade the rake gem and stick with v0.7, or make the following change in the vlad gem’s lib/rake_remote_task.rb on line 108:

def execute(rake_t)

Thanks to Brian Palmer for this workaround. I hope the vlad crew will get around to another release soon.

Update: vlad 1.2.0 has been released and now works with both rake 0.8 and 0.7. Thanks guys!

Don’t forget, the next meeting of the NH Ruby and Rails User Group is coming early this month. We’ll be meeting on Monday, November 12. Guest speaker and author David Berube will be discussing reporting using Ruport and various other tools. He knows a bit about this topic since he has a book forthcoming on the subject in early 2008.

I’ll also spend a few minutes discussing how to keep your mongrel processes under the watchful eye of monit. This is an outstanding utility that has many uses in systems administration.

Clifford Heath wrote a sarcastic yet poignant list of all-too-common screw-ups people can make when creating and deploying a Ruby on Rails project.

Sometimes you laugh because it’s funny. And sometimes you laugh because it’s true.

I deployed a Ruby on Rails application using Vlad the Deployer for the first time today. Vlad is a much, much simpler alternative to Capistrano, which I’ve also used.

However, the process wasn’t as smooth as it could have been. I ran into the following issues that required some digging:

1. My subversion repository is accessed via an https web server, which happens to use a self-signed SSL certificate. The svn program prompts you to verify and save this certificate the first time you perform a checkout. Vlad hung on this prompt until I logged into my deployment server as the user and manually completed a checkout from the repository.

2. My subversion repository is also password-protected using HTTP authentication. Vlad apparently doesn’t know how to deal with this, as I couldn’t find any documented variables to set an svn username or password. However, I could override the subversion command, and add switches for the username and password in my deploy.rb file:

set :svn_cmd, "svn --username=\"USERNAME\" --password=\"PASSWORD\""

3. The vlad:start task runs apachectl to give apache a kick after starting up mongrel. That binary was not in my user’s path, so I had to edit the user’s .bashrc file to add /usr/sbin to the $PATH environment variable. Second, the apachectl command needs to be run with root privileges, and Vlad seems to have no knowledge of sudo. To fix this, I was going to override the vlad:start task, and started poking around the gem sources to see how the original task was defined. That’s when I noticed that it sets the variable :web_command internally, so I was instead able to override that with another addition to my deploy.rb file:

set :web_command, "sudo apachectl"

These weren’t a huge deal, but that’s only because I’ve dealt with Capistrano and have an idea of what variables should exist to configure these kinds of options. I’m liking Vlad a lot.

In fact, I’m pretty sure for October I’ll be doing a presentation for NHRuby.org on Vlad the Deployer.