Let Capistrano Compile Ruby 1.9 For You

A Capistrano task to install Ruby 1.9.1 to “/opt/ruby-1.9.1” on Debian:
Read the rest of this entry »

Avoid Sore Fingers While SSHing Around

If you’re anything like me, you’ve gotten accustomed to commands like this:

ssh [user]@[remote.server.com]

If you find yourself connecting to the same machines repeatedly, save a few keystrokes by creating a handy alias for them. Create (or edit) “~/.ssh/config” and add as many of these as your little heart desires:

Host [the alias]
HostName [domain name or IP address]
User [the account to login as]

Now you don’t have to use the full command to access the machine, just use the alias! For example, here is how I access one of my DreamHost servers:

ssh dh

The same goes for SCP! So, to secure copy a file (my_file.txt) in my current directory to the same machine I would simply issue:

scp my_file.txt dh:

Ahh… that is easy on the fingers! What else can we do with SSH config files?

2>&1

A common practice when adding entries to crontab is to end the entry like this:

 >/dev/null 2>&1

The purpose of this is to suppress any output from the command itself, because we’re not interested. I picked up this syntax years ago because it just works, but I never knew what the ‘2>&1′ actually meant, until today.

The first part:

 >/dev/null

Means redirect STDOUT (the standard output stream) to /dev/null (which is basically a blackhole for bits). That’s easy enough.

The second part:

 2>&1

Means redirect STDERR (standard error stream) to the same place as STDOUT (which was just specified). STDOUT has the assigned number 1 and STDERR has the assigned number 2.

This way both STDOUT (1) and STDERR (2) are directed to /dev/null and all output of the cronned command is suppressed.

Rsnapshot (Rsync) Gotcha

If you’re trying to backup a remote host using rsnapshot (or rsync by itself) and run into one of the following ambiguous errors:

rsnapshot version:

ERROR: /usr/bin/rsync returned 12 while processing ...

rsync version:

rsync error: error in rsync protocol data stream (code 12)

It’s probably because you don’t have rsync installed on the remote host (doh!)

Bash array and loops in FireHOL configuration

IPTables is a powerful but cryptic firewall solution. FireHOL is an IPTables configurator that flat out rocks. One of FireHOL’s strengths is that it uses standard BASH syntax inside its configuration file, so you get all the power of BASH to configure your firewall.

Let’s see how a BASH array and for loop can help clean up our FireHOL config:

You have 3 machines that need SSH access to the server. First, you can setup variable names to reference the IP addresses (or DNS names) of the machines. Put these declarations at the top of your FireHOL config for easy maintenance.

srv1="205.205.205.1"
srv2="srv2.example.com"
srv3="143.32.2.44"

Now lets see what the SSH allow declaration will look like using these variables on interface eth0:

interface eth0 public
  policy reject
  server ssh accept src $srv1
  server ssh accept src $srv2
  server ssh accept src $srv3

Notice how each host you want to allow SSH access adds another line to your configuration. This may seem trivial in my example but can add a lot of complexity as your environment grows. Is there a better way to implement? You bet.

First, lets create an array to house all of the hosts we want to provide SSH access to:

ssh_list=($srv1 $srv2 $srv3)

Next, we change the declaration on our interface to simply loop through this list of hosts and allow SSH access:

interface eth0 public
  policy reject
  for host in ${ssh_list[@]}; do
    server ssh accept $host
  done

Much better! Now we can simply add/remove hosts from our ssh_list array (at the top of the config file where all our variables are declared) and let BASH do the rest. The key here is the ${ssh_list[@]} which returns the evaluated list of hosts inside the ssh_list array. Enjoy.