Ruby on Rails on DreamHost Installation

I’m no Rails expert, nor a Ruby expert, and this is only my second installation of Rails in 4 years, and my first on DreamHost.  So no promises.  But here are the steps I went through to get Rails working on DreamHost with MySQL.

1. Set up a domain and directory. This where your Rails installation will live.  DreamHost’s preferred method of running Rails is now officially with Passenger (aka mod_rails) which they have on all their Apache 2 servers. You can use the DreamHost admin panel to set this up: go Domains->Manage Domains->Add New Domain/Sub-Domain and make sure to check off on “Ruby on Rails Passenger (mod_rails)”. If you plan on making ~/path/to/rails/root your root directory for your Rails installation, then you need set the web root directory to ~/path/to/rails/root/public when you add this domain using the DreamHost admin panel.

2. Set up a database. You can do this through DreamHost’s admin panel as well.  Goodies->Manage MySQL->Create a new MySQL database.

3. Set up Rails. Go to the directory you’re going to run your Rails installation out of (~/path/to/rails/root from step 1) and run:

   rails . -d mysql
   

   (Note the dot for ‘current directory’.)  This will create all the Rails directory structure and default starter files.

4. Set the permissions. I’m not sure what the exact minimum possible permissions are to run Rails on DreamHost, but this created an acceptable situation for me for now: (note that I ran step 3 with a umask of 0027)

   find ./ -type d -exec chmod o+x {} \;
   find ./ -type f -exec chmod o+r {} \;
   chmod o-r config/database.yml
   

   You would absolutely want to lock these permissions down further if your application involved any sensitive data or services whatsoever. Leaving all your scripts world-readable allows any other DreamHost user to potentially scan your code and look for vulnerabilities.

5. Do an intermediate test. At this point you should be able to navigate to your domain and see the Rails welcome page.  Note that the “About your application’s environment” link will not work in ‘production’ mode, DreamHost’s default. If things aren’t working, your friends are the logs in ~/logs/your.rails.domain.com/http and ~/path/to/rails/root/log.

6. Set up the database connection. This involves editing the file config/database.yml.  DreamHost has its Virtual Hosts set up to default your Rails installation to run as ‘production’, but you can change this by setting ENV['RAILS_ENV'] in config/environment.rb.  Here’s a good way to do this automagically once you have development/staging/production sites all set up. After editing any of your Rails config files, you need to do:

   touch tmp/restart.txt
   

   to make sure Apache reloads the Rails config files on the next HTTP request.

7. Test it. My test was to get the ’skeleton’ version of this project up and running by copying a few files into the Rails directory structure in the appropriate places.

Probability I find something wrong with these instructions in the next week or so?  ~80%.  I’ll update this post when I do.

Update:

Fyi, if you run the Webrick server in script/server, a DreamHost bot will auto email you telling you to please stop it:

From: DreamHost Policy Bot <support@dreamhost.com>
To: Michael Fogel <******@gmail.com>
Our automated system has come across the following activity under your account that is in violation of our Terms of Service.
We request that you take any necessary action to cease the activity as quickly as possible or we will be forced to take further action. If you were not aware of any such activity, please feel free to contact support and we can look into the issue further.

User **** running “ruby ./script/server”. This process is against our policies.

Please run ruby via cgi, not the built-in Webrick web server

They should add to this email a thinger about mod_rails being their preferred way to run Rails.

Update 2:

Ug, you can’t use HTTP Basic Auth with mod_rails (as of version 2.0.6). Note this is what DreamHost will set up for you if you use their web panel to set up authentication. Here’s a relatively simple if not elegant solution to the problem while we wait for mod_rails 2.1 to be released.