I’ve only been a member of SliceHost (the server that is currently serving this article to you) for a week now but I have to say that I’m very impressed and very pleased with the service thus far. They have a real-ness about them. They have an IRC channel where you can actually find members of the staff. They don’t limit what you can do on your VPS. They’re inexpensive. I could go on about why I think they’re service is great, but I’ll stop myself there. I want to string together some articles that will basically go over how I set up certain parts of my server for those of you who are either new to SliceHost or new to setting up a server.

Since most of my work and most of this blog will be about Ruby on Rails, I thought it only fit that the first article be about getting a Ruby on Rails system up and running. My slice has Gentoo installed on it, so the instructions will be using commands specific to Gentoo, but if your using a different system, you should be able to follow along and replace ‘emerge’ with your package manager. Let’s get started, shall we?

Getting Started

The first thing we should really decide is how we want to serve up our Rails application. You lucked out because I’ve decided that for you! I’ll be setting up a mongrel cluster with Apache 2.2 used as the proxy. If you would like to use Lighttpd and FastCGI or some other setup, you may want to just skim this guide and find another that is more specific to your needs, but mongrel clusters and Apache 2.2 are all the rage these days, so you should really give it a shot. Let’s start with the basics. Let’s get Ruby on Rails up and running. First, how about we make sure everything is going to stay pretty uniform. We need some USE flags so that ruby and apache and everything else get installed with the correct things compiled in. Edit /etc/make.conf.

USE="apache2 ruby ssl mysql postgres sqlite3 imagemagick gif jpeg jpeg2k png tiff svg wmf xpm pdf truetype unicode python"

Obviously, not all of these flags are necessary, and you may even want to add some extras. When using emerge, I strongly recommend adding the -va option. This will print out everything that’s going to be installed and ask if you want to continue. It will also print each USE flag the packages will be compiled with and without, so it’s a good way to see what flags you really need. Next we need to emerge some things. Since we already know what we NEED to have installed, I’m going to go ahead and do this in one step. Let’s add some keywords and unmask some things.

# vim /etc/portage/package.unmask
net-www/apache
dev-libs/apr
dev-libs/apr-util

# vim /etc/portage/package.keywords
~net-www/apache-2.2.4
~dev-libs/apr-1.2.8
~dev-libs/apr-util-1.2.8
dev-ruby/rubygems

These are essential unmasks and are used for installing Apache 2.2 on Gentoo (which is currently masked for testing). I’ve yet to find any bugs or any critical problems with it so if your afraid of installing testing software on your new server, relax a little. x=) If you can’t relax, you may want to seek out a tutorial that doesn’t use mongrel clusters with apache, since 2.2 is the version you require to use the mod_proxy_balancer module. Again, your free to add whatever else you might want to have a more bleeding edge version of.

Emerge!

Let’s start the emerge, I’m getting hungry.

# emerge ruby rubygems openssl apache \
graphicsmagick subversion mysql postgresql \
sqlite3 -va

You’ll see a list of everything that’s going to be installed. It’s good practice to get into the habit of looking at this and seeing what use flags are and are not being used. If you see something you don’t like, just say no and add the use flag to /etc/portage/package.use and try again until it looks right. When your satisfied, say yes to the prompt and your packages will start to build. This will probably take a while so, like I said, I’m hungry. You should grab something to eat as well…

Lunch ....

Install Gems

Okie doke. How was lunch? Ready for the fun stuff? Of course you are. We need some gems! There are people who say it’s better to use portage for some gems that are available, but I would rather just have 1 place where I install all my gems so we’re going to use Ruby Gems for all of this. We’ll start by updating Ruby Gems, since the latest version in Gentoo is a little old and then we’ll install Rails and a few other things we might need.

# gem update --system
# gem install rails -y
# gem install mongrel -y
# gem install mongrel_cluster -y
# gem install rmagick -y
# gem install mysql -y
# gem install postgres -y
# gem install sqlite3-ruby -y
# gem install tzinfo -y
# gem install ruby-yadis -y
# gem install ruby-openid -y

Obviously, the last 2 gems aren’t REQUIRED, but why the hell aren’t you using OpenID in your rails application!? You should now have a fully functional Ruby on Rails system. What’s next? Well, I’m sure you have your application that your DIEING to get running, so let’s pretend your application is called chunky_bacon for the rest of this tutorial and we’ll get started setting up Apache. I won’t be going over deployment with Capistrano or anything because I’ve never used it (yet). I’ll definitely update with a new article when I finally learn the ropes.

Uploading Your Application

Setting up Apache as a proxy for Rails is actually pretty simple. Let’s upload chunky_bacon somewhere. Most Gentoo systems have their apache documents in /var/www/yourdomain.com/. Let’s go ahead and pretend like our domain is chunkybacon.com for the time being and let’s create an environment for our chunky_bacon application.

# mkdir /var/www/chunkybacon.com
# cd /var/www/chunkybacon.com

Now copy your application here. However you feel comfortable. FTP, SSH, SFTP, WebDAV… Whatever works for you. So long as in the end, you have something like /var/www/chunkybacon.com/chunky_bacon/ as the root of your rails application. Since the database is pretty much up to you to pick. I’ll assume you know at least the basics of setting up your database of choice and creating the production database. Remember, we’re in production mode now, so make sure you give root a password and it’s a pretty good idea to use a different user to access your database.

# rake db:migrate RAILS_ENV=production

Apache Setup

This step is up to you. edit /etc/apache2/httpd.conf to suit your needs and your server. The entire configuration file is very well documented so take the time to read through it and set everything up for your server.

All done? Ok. Let’s move on. Let’s edit the default virtual host that’s going to proxy our traffic to our mongrel cluster. Again, you have some choice here. I’m editing the default virtual host, but if you’d like to create a new one for a different subdomain or whatever, feel free. If you don’t know much about virtual hosts, you should read up on the apache documentation for them.

# vim /etc/apache2/vhosts.d/00_default_vhost.conf
<IfDefine DEFAULT_VHOST>
NameVirtualHost *:80

<VirtualHost *:80>
    ServerName chunkybacon.com
    ServerAdmin admin@chunkybacon.com
    DocumentRoot /var/www/chunkybacon.com/chunky_bacon/public
    <Directory /var/www/chunkybacon.com/chunky_bacon/public>
        Options FollowSymLinks
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>

    RewriteEngine On
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteRule ^/(.*)$ balancer://chunky_bacon%{REQUEST_URI} [P,QSA,L]

    ProxyPassReverse / balancer://chunky_bacon
    ProxyPreserveHost on

    <Proxy balancer://chunky_bacon>
        BalancerMember http://localhost:8000
        BalancerMember http://localhost:8001
        BalancerMember http://localhost:8002
    </Proxy>

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    # Makes sure any .svn folders won't be accessible.
    <DirectoryMatch "^/.*/\.svn/">
        ErrorDocument 403 /404.html
        Order allow,deny
        Deny from all
        Satisfy All
    </DirectoryMatch>
</VirtualHost>
</IfDefine>

This in itself isn’t going to help us. We need the mongrel cluster!

Setup a Mongrel Cluster

Good thing for us, setting up the mongrel cluster is the easiest part!

# cd /var/www/chunkybacon.com/chunky_bacon
# mongrel_rails cluster::configure \
-e production -p 8000 -a 127.0.0.1 -N 3 \
-c /var/www/chunkybacon.com/chunky_bacon

This will create a file in your config directory called mongrel_cluster.yml. You don’t need to worry about manually editing it at all. What we are saying here is we want to configure a cluster for production. We want to start at port 8000 on 127.0.0.1 (localhost) and set up 3 mongrels (8000-8002, as seen in the virtual host configuration). Now, we have a few loose ends to clean up and we’ll be all ready to go.

Clean Up!

First, it’s a good idea to run services as something other than root. Apache is nice enough to give us the apache user and group to use for running apache, but lets make a new user for running our application.

# adduser -m chunkybacon
# passwd chunkybacon
# chown chunkybacon:chunkybacon /var/www/chunkybacon.com -R

Now let’s start up Apache and add it to a default runlevel. If you stopped your database, you’ll want to start that up again too.

# /etc/init.d/apache2 start
# rc-update add apache2 default

The first time I tried this, I included 2 extra options in the mongrel_rails command for creating the cluster configuration. --user and --group for changing the user and group. I figured this would be useful for the day I decided to write an init script to start mongrel automatically. The problem was, even though the mongrels were run by the new user, the home directory was never reset so any configuration files needed were being looked for in /root. You may not run into this, but mephisto definitely had a problem with it so I recommend just using a regular user for your applications. Let’s fire up our new application and see her in action!

# su chunkybacon
# cd /var/www/chunkybacon.com/chunky_bacon
# mongrel_rails cluster::start
Starting 3 Mongrel servers...

Cross Fingers

Now point your browser to http://chunkybacon.com and you should see your application! That’s all there is to it! Note. This is pretty basic for setting up your application. You should definitely do some research about virtual hosts and other things to make sure everything is working just the way you need it to. That’s the great thing about SliceHost, your not limited to just what your host wants you to have control of, you have complete control! Now that I got you started, venture off into the real world and show it what you can do! Leave some comments if I made any mistakes here (a lot of this was from memory) or if something doesn’t work for you.

DONE!

P.S. I’m in no way affiliated with chunkybacon.com but if you haven’t read the Why’s Poignant Guide to Ruby, it’s definitely a fun read!