This problem was truly maddening. Some kind of rogue tcp process spawned by mongrel was not getting closed properly.

It was truly a ghost in the machine.

Doing a ‘ps aux | grep ruby’ or ‘ps aux | grep 3000’ yielded nothing. So it was darn neigh impossible to find a process to kill that was somehow still holding onto the socket. Attempting to start mongrel yielded the “Address already in use – bind(2) (Errno::EADDRINUSE)” error.

This link provided the answer.

If you normally run your mongrel(s) on port 3000, use the following snippet to kill em dead:

kill -HUP `lsof -t -i TCP:3000`

The following is the complete stack trace:

** Ruby version is not up-to-date; loading cgi_multipart_eof_fix
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
Exiting
/usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/tcphack.rb:12:in `initialize_without_backlog': Address already in use - bind(2) (Errno::EADDRINUSE)
        from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/tcphack.rb:12:in `initialize'
        from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel.rb:92:in `initialize'
        from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb:139:in `listener'
        from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:99:in `cloaker_'
        from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb:50:in `initialize'
        from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:84:in `run'
        from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/command.rb:212:in `run'
        from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:281
         ... 6 levels...

Good luck!

This is pretty simple once you know the exact syntax, but if you rarely use this OS functionality, it can be a pain to lookup each time. Let’s assume we have a directory in /data, called “backup”. Within it, many subdirectories and files exist.

We’d like to zip (or tar/gzip) the entire directory’s contents. Here’s how to:

Zip the Directory (recursively)

cd /data
zip -r backup.zip backup/

Tar/Gzip the Directory (recursively)

cd /data
tar -v -cf backup.tar backup
gzip backup.tar

And there you have it.

cat db.sql | grep euck
) ENGINE=InnoDB DEFAULT CHARSET=euckr;

Yuck, that should be UTF8! So you whip out your trusty steed, sed and do a quick:

cat db.sql | sed s/euckr/utf8/ > new.sql

cat new.sql | grep utf8
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Sweet, all good to go!

Note: security freaks, please do not read the following. It might make your eyes bleed. (or, feel free to propose an alternate solution in the comments)

The main potential security implication is:

If your mac is somehow compromised (an attacker gains access to your private keyfile located at ~/.ssh/id_dsa) then you will need to quickly kill access to that keypair on your remote servers.

Other than that, this setup is pretty slick if UR SSHN TO LOTS OF LEENUX BOXEN. Ahem.

Generate the Keypair Locally

On your OS X machine:

  ssh-keygen -b 1024 -t dsa

Just hit enter for all of the defaults, including a BLANK passphrase. (otherwise you would have to enter it each time you SSH’d to a remote box, thereby defeating this whole exercise, no?)

Ensure Remote Server has a ~/.ssh/ folder

  ssh deploy@remote.com
  mkdir ~/.ssh/

Next copy ~/.ssh/id_dsa.pub to the remote server. Example:

  scp ~/.ssh/id_dsa.pub deploy@remote.com:.ssh/authorized_keys

Try logging in sans password:

  ssh deploy@remote.com

It should now let you in without entering a password or passphrase!

Set .ssh Permissions on Remote Linux Server

On the remote linux box, do a:

  chmod 700 ~/.ssh
  chmod 600 ~/.ssh/*

Enabling this setup for other Linux Boxes

Do NOT overwrite your existing key pair (default locations) with ‘ssh-keygen’ on OS X because then all your other servers will not recognize the new key!

You can generate a new pair for each separate linux box you want to connect to, just follow the previous ssh-keygen instructions but place the output in a new location.

To use the same public/private keypair on each box (say it’s just you who’ll be admin’ing em):

  scp ~/.ssh/id_dsa.pub foo@another-server.com:.ssh/authorized_keys

Again, Try Logging in Sans Password

  ssh foo@another-server.com

Should now let you in without entering a password or passphrase!

You also might need to follow the directory setup/permissions guide as outlined above.