Supersonic Feet

A while back, Phusion released a product called Passenger, effectively mod_rails for Apache. The idea is that rather than having to do a lot of the usual manual setup work when running a Rails app (using mod_proxy to point at mongrel_clusters, etc.), you can just have them run automatically via Apache, the same way PHP apps will. Today I finally managed to get it running and while the solution was simple, it's hard to find.

My problem was that I have WebHostManager/cPanel running on my server, which installs Apache for you. This has the common trade-off of being very convenient, but reducing your options for true customization. So when you run:

passenger-install-apache2-module

the installer will tell you to install the httpd-devel library via 'yum install httpd-devel'. Trying that just had yum return a 'nothing to do' response because it had decided there wasn't an httpd-devel package to be found.

I've had a couple of half-hearted attempts in the past few months trying to find an rpm for httpd-devel to match the version of Apache cPanel currently installs (2.2.9) to no avail for my CentOS box. Today I tried a bit harder while setting up a new server and found the solution!

It turns out (thanks to this thread on the cPanel forums) that cPanel excludes all yum packages for httpd to avoid conflicts, although the tools are actually installed when cPanel installs Apache. So they're there, Passenger just doesn't know that.

The cPanel thread provided the solution to this problem by basically pointing the Passenger installer at apxs:

APXS2=/usr/local/apache/bin/apxs passenger-install-apache2-module

Now the required dependencies checks should pass and hopefully all will be fine. I did however hit one more problem, with a complaint along the lines of  "'apr_ino_t' does not name a type". Luckily this is also solved by just pointing the installer at apr-1-config, so you end up with:

APXS2=/usr/local/apache/bin/apxs APR_CONFIG=/usr/local/apache/bin/apr-1-config passenger-install-apache2-module

Thanks to a blog post from Peter Cooper for that solution, which it turns out has the previous solution as well. If only I'd found that blog post before! Anyway, in the same spirit of Peter Cooper's post of this problem not being documented widely enough (or at all), I thought I'd better get it written down here too, if nothing else but for my own reference.

This would've been so useful to me when I switched from PHP to Ruby a couple of years ago: the PHP documentation with the Ruby equivalent described for each function.

Found via RubyFlow.

The official Rails blog has the announcement that Rails 2.0 is done and great news that is too. Now I just need to find the time to eventually catch up on all the changes and start playing with it!

Tantek Çelik's slides from his talk on Social Network Portability are a very good, quick read as an introduction to supporting social network portability on your own site/service using microformats.

The slides include real, practical demonstrations of how it can be done and having made a bit of a start (i.e. not a good-enough start) on making bragster profiles support hCard and XFN, it's pushed me to get it sorted on bragster as soon as possible, both in terms of properly marking up the profiles as well as potentially doing some importing of hCard/XFN info.

A 2-minute play with mofo shows it's not hard to do the importing bit, so (dev-time time allowing) I'll be seeing how we can use it to good effect on bragster. Satisfaction's signup form is a pretty good example of a first step in hCard importing - helping you fill out the signup form quicker by pulling some of the data you've already given to another social network.

Not quite but Derek Sivers, an early proponent of switching to Rails for large-scale websites, has written a post on his O'Reilly blog about why he just gave up on 2 years' work in Rails on his CD Baby project to switch back to PHP.

It's a very sensible article looking at the fact that Rails isn't always the answer, much as it may pain us to admit, and that when PHP (or any other language) would actually be easier to use, we just should.

That said, I haven't been tempted back to PHP for anything just yet :)