Dev::Blog

I’m sure I’m not the first to do this, but when adding a new association table to your user object, the changes won’t take effect for your logged in profile until you log out if the damned user object is attached to the session…

I blame the Nyquil-clone. Or maybe I need a recharge.

After 2 days of off and on server admin, I’ve finally got a production server that can take Capistrano deployments without sacrificing the Plesk GUI!

Here are some of the highlights - most of the steps I used can be found in Time for a Grown-Up Server, so this is more of a list of gotchas to do with a Plesk setup. I’m sure I’m missing a thing or two here and there, so contact me if you’re stuck and I’ll either fill in the blanks or fix my typos. :)

Installing Apache 2.2

Capistrano’s cool by itself, but if I’m messing around with server crap, I want a Mongrel cluster at the same time. While Plesk 8.1 supports Ruby on Rails via FastCGI, Capistrano seems to work best with Mongrel, and more importantly, that’s how I’ve got another server configured, so I’d rather have a smaller set of problems to troubleshoot between the boxes.

Unfortunately, running a cluster requires mod_proxy_balancer on Apache, which isn’t available until Apache 2.2. Plesk comes with Apache 2.0. Urgh.

Upgrading requires a few steps. I used Bryan Thompson’s guide to get Apache in, but it turned out I needed to compile it with –enable-openssl. Once that was in, I had to figure out how to handle the server config. Plesk likes to overwrite /etc/httpd/conf/httpd.conf a lot, and it keeps its virtual server config info (with other files) in /etc/httpd/conf.d. I didn’t care much about the non-virtual stuff - I can set that up myself, so I kept httpd.conf in its new /usr/local/apache2/conf directory and added an Include /etc/httpd/conf.d/zz010_psa_httpd.conf to keep the one file I wanted in play. I also had to include mod_suexec to keep everything happy.

Mongrel and Capistrano

Using the ultimate Time for a Grown-Up Server guide, I was able to get Mongrel and Capistrano working. The catch was getting Plesk to be happy with it.

Your mileage may vary, but my Plesk-managed websites were located at /var/www/vhosts/[site name]/httpdocs. I wanted the document root to be [app base]/current/public, so I switched it over with a symlink - I added a directory at /var/www/vhosts/[site name]/website and made that my base directory for Capistrano. Then I deleted (OK, renamed) httpdocs, and once I ran cap setup to get the rest of the structure in place, I did an ln -s /var/www/vhosts/[site name]/website/current /var/www/vhosts/[site name]/httpdocs to line everything up.

That gave me a 403 error, because Plesk was set up to not follow symbolic links. Chowning and chgrp’ing the new httpdocs probably fixed that.

Finally, it’s good to test a reboot to make sure everything sticks. Sure enough, when I tried to access my site I got a 503 error. The Mongrel processes hadn’t started. Thankfully The Google had my back and this post pointed a possible problem (boot path issues), but the fix didn’t work for me - at first. Since I didn’t have console access, I redirected the outputs of the commands in /etc/init.d/mongrel_cluster and it turned out I was running a different version of ruby in /usr/bin that didn’t have rubygems installed. Updating that version did the trick.

So here I am - now I can develop wherever I want, check in my code, and deploy to production without ever touching the live web directory, but I can still use Plesk to manage the occasional little server thing that I don’t want to bother remembering, though granted, the more tasks like this that I do, the less I need Plesk for.

Technorati Tags: Plesk, Capistrano, Mongrel, Apache, Rails

I’ve been getting swamped with spam lately on the order of 300 messages a day, and I’ve nobody to blame but myself. See, I’ve had some of my domains for more than 5 years now, and back then, having a “catch-all” email setup was pretty cool - I didn’t have to worry about giving my friends an exact email address, and I could make “one-off” addresses easily for form signups that I wanted to track to see where future spam came from. Anything addressed to an arbitrary account @ thrustlabs.com would get
to me.

Of course, spammers win big in this scenario, and I’m getting hit with 7 or 8 emails at a time with the same subject addressed to various made-up accounts like “accounting@thrustlabs.com” and whatnot.

The solution’s obvious - shut off the catch-all, right? Unfortunately, I didn’t exactly keep track of the addresses I’ve given out over the years, so turning off catch-all could block something that’s actually important. Urgh.

Fortunately, I know just enough Ruby and just enough about Thunderbird’s mbox format to write something that’ll extract my email addresses from email stored in folders:

emails = {}
Dir['c:/documents and settings/your account/application data/thunderbird/profiles/**/*'].each { |file|
  if FileTest.size?(file) then
    mbox = File.new(file, "r")
    while(line = mbox.gets)
      emails[line.scan(/[A-Za-z0-9._]+@thrustlabs.com/)[0]] = 1
    end
    mbox.close
  end
}
emails.each_key {|email| puts email }

It might not be pretty, but it works for me (as always,it might destroy your computer, handle with caution, etc., etc.)

I took the output, edited out the spam-generated accounts, and set up explicit forwarding accounts for each of the addresses that were left, disabling catch-all at the same time. Once that takes effect (it’s a shared server, so there’s a lag), I can go through the rest of my spam and identify other troublesome addresses for other domains (I just did the two oldest, and thus biggest problem, domains to start). You know, assuming I didn’t do something stupid like block all my mail. Come to think
of it, that would be rather peaceful…

Technorati Tags: Spam, Ruby, Thunderbird

Note to self: using Ruby On Rails’ SaltedHashLoginGenerator is a lot easier with the following line added to user_controller below the class declaration:

before_filter :login_required, :only => [:welcome, :change_password]

Without that, the thing seems to want to authenticate everything, even account validation clicks from an email, which you’re obviously not logged in for.

Technorati Tags: Ruby On Rails, SaltedHashLoginGenerator

I spent far too much of this morning futzing about trying to get Typo working in a DreamHost account (no, it’s not public yet). This post turned out to be the key to getting everyting going.

While Typo is pretty sweet, I’m not sure if I’ll be able to actually use it with DH on a shared plan - I already get regular messages saying I blew the CPU limit, and right now I’ve got 5 instances of dispatch.fcgi that’ve sucked back 3 seconds of power each. Unfortunately, while DH has been great, and I still heartily recommend them for smaller sites (no, this blog isn’t the “problem”), they won’t have any dedicated servers available until they migrate their data centre.

Of course, I do have a static IP at home… While I wouldn’t want to run anything mission critical¹ on it, a home server might be just the ticket for lower-traffic sites and experiments. Now if I could just get FastCGI working on Tiger…

I’m visiting family this week, which has a real stop-and-go rhythm for getting anything done, which means it’s a good time to do “shallow” tasks like surveying a lot of tech from 10,000 feet.

I got Ruby installed on the ThinkPad¹ - the one-click 1.82 was a lot easier than the many-click 1.84 version, and now it’s got me thinking about how I can use it online (more on that later, I’m sure). Dreamhost has Rails support now, but it’s pretty simple to do straight CGI stuff too:


#!/usr/bin/env ruby
puts "Content-Type: text/html\r\n\r\n"
puts "hello world"


The trick is to name the file with a .cgi extension - DH’s Apache doesn’t have support built in for .rb files

1. (and technically on Ubuntu, but that was installed as a Virtual PC and really really really doesn’t seem to like when the box goes to sleep)