Dev::Blog

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

Just once, I’d like to see a problem that takes more than 20 minutes of my time to identify actually take time to resolve than it did to research. We’re probably all a little guilty of trying to make things harder than they should be, but I swear, I must have skipped “simple stuff” in school, because that’s what always gets me.

In this case, I had some files being ftp’d in regularly to a user’s folder on the server, and I needed to make the file accessible on a website that also runs on the box, but under a different ID.

The server is managed through Plesk, so I needed a brief lesson in httpd.conf management under Plesk - you don’t edit the file directly (it gets overwritten regularly with Plesk-generated data), but you can create a file called vhost.conf in [webroot]/conf. Mine looked like this:

Alias /cover /home/theuser
<Directory “/home/theuser”>
order deny,allow
allow from all
AllowOverride Limit
Options FollowSymLinks ExecCGI
</Directory>

Once that’s in place, two commands are needed:

1. /usr/local/psa/admin/sbin/websrvmng –reconfigure-vhost –vhost-name=radio.lggmedia.ca
2. /usr/sbin/apachectl restart

Everything above, including the vhost.conf creation, seems to need to be done as root.

That, however, wasn’t the problem.

The problem was that despite the amazing setup job I did with my vast array of sysadmin knowledge, I kept getting a 403 Forbidden error when trying to access any files in the /cover directory. Permissions were great across the board with everything world-readable from / to /home/theuser/file but Apache hated me.

After too much time and not enough beer, the issue turned out to be that Apache wanted the /home/theuser folder to be executable. I don’t know what made me try that, but once I set the bit, it all worked.

Sadly, I only found the explanatory “Directories need to be executable by the Apache user, so that Apache can get listings of the files in the directory, and display the documents located in that directory” from this article after Googling “why does apache need executable rights on a directory,” which isn’t much of a query for troubleshooting, since it kinda needs you to know
the answer up front. What did work great was preparing a blog post about the problem, which brought a solution to my mind right away. Talk to the duck…

Technorati Tags: Apache permissions