(Edited 2001/10/24 to add apache notes at end.)
Rails isn’t always an easy proposition on Dreamhost, and this was no exception. BTW, this is *not* the rvm version. I wanted to get the Dreamhost default setup working before I started playing with rvm. I’ll probably post an rvm-related set of instructions later.
In this case, I wanted to move some sites over to NginX as a trial, because the apache/passenger combination had been seeming rather slow and memory-intensive of late. I wanted to see how much time and RAM NginX would save me.
The first bits were simple. Setting up the VPS using the Dreamhost CP went easily, then came time to configure it. The settings are pretty much self-explanatory, as you can see. The idea is to select the NginX web server, then turn mod_php off. (I did the latter just because I’m anal-retentive: mod_php is an apache module, so it wouldn’t work with NginX anyway. But even if it did, I wouldn’t want it; I want to run PHP as a fastCGI/FPM process, anyway.)
Setting those gives you the basic setup for the domain. Unfortunately, that in itself isn’t enough to get the default Rails setup on Dreamhost (Rails 3.0.3 at the time of this writing) working properly. The fun starts now.
rails new appname --database=mysql
builds the rails app, but there are more issues to come. The first is that Passenger doesn’t find the bundler to load. This is because it’s not looking for it (and, by extension, all your site’s gems) in the right place.
I recommend covering this in a couple of places, because this is something that will end up biting you again and again if you don’t. So, first, in the .bashrc file of your home directory you’ll want:
This will make sure your deployment tools, like capistrano, will see the gems. The ‘/user/lib/ruby/gems/1.8’ path is the default path Dreamhost is storing its own set of gems. You should check to ensure that’s where it is on your system, and if it’s different change it to whatever it is on your site.
Then you need to do something similar in /config/setup_load_paths.rb (you’ll need to create the file yourself, it’s not in the standard Rails 3.0.3 setup):
# You can also set GEM_PATH if needed
You need it here, so that Rack can find the gems; it loads before Rails, after all, so putting them in the Rails config area wouldn’t help.
You’re probably not done yet. There’s another bug waiting to bite you in your Gemfile. I built this Rails app for mySQL, remember? This line:
was put in the Gemfile by Rails as a default. It resulted (in my case) in bundler using the Dreamhost-supplied mysql2-0.3.7 gem. And you’ll probably trigger an ActiveRecord error with that, along the lines of “this version of mySQL2 doesn’t ship with the ActiveRecord adapter.” Oops.
The solution is to drop back to a previous version of the mysql2 adapter for this, by changing the mysql2 line in your Gemfile to be
gem 'mysql2', '< 0.3'
That tells bundler you want one earlier than 0.3. I've seen it work with 0.2.7 and 0.2.13, so it doesn't seem to be too picky. It may even work with later ones than that; all I can say is I know 0.3.7 doesn't work with it.
That was the extra work it took me up front to get just a vanilla Rails install functioning on Dreamhost VPS. Hope it saves someone else the hours of searching and trial and error I spent getting it to work.
And Of Course Apache Is Different
It can't be so simple as to be the same changes with both. With apache, you need to place the gem path code at the top of config.ru:
# You can also set GEM_PATH if needed
and it doesn’t need the setup_load_paths.rb file to be present.
Of course, you can always put the path code in both places. Having the setup_load_paths.rb file doesn’t seem to disturb apache and the extra code in config.ru doesn’t bother NginX. It’s not DRY, no, but it’s also not something that will be changing very often, if at all, so I can live with it.