Many hosting resellers (sadly, even mine) are behind the times on Rails. If you aren’t a Rails developer, it may not seem like a big deal to not upgrade from Rails2 to Rails3 — but believe you me, it is hugely different. (The closest comparison I could make is like how WordPress changed from version 2 to version 3) I understand that there are issues with Passenger, particularly on shared hosting instances, but to me, I perceive this as “it’s not enough of a priority for us”.
If you’re on a shared hosting instance, that means you’re almost completely screwed.
On a VPS, where you have root access, you can get out of it.
So here, to the best of my recollection of the past week, are the steps I took to get Ruby 1.9 and Rails 3 operational on a CentOS 5 server (provider: Hostgator), without using RVM. Strictly native, baby.
Step 1: Obliterate Existing Ruby / Rails instance
Ruby 1.8.7 was nice, and we’re all thankful for its contributions to science, the war, cinema, blah blah blah. It’s old and busted.
Ruby 1.9 is the new hotness. It has Rubygems bundled with it, some new methods, and I’m pretty sure that you need it for a current installation of Rails 3. (3.1 most definitely needs it, at least).
I’m just going to assume you’re doing this as root. Otherwise, assume you’ll need to prepend sudo in front of the commands. Tread carefully if you are root, of course.
CentOS uses yum.
root:~# gem uninstall rails root:~# yum remove ruby
If you had previously tried, and failed, to use RVM, be sure to remove that too. (Check in your .bashrc and .bash_profile files for references to it — remove them or comment them out, and then log out and log back in.)
After both commands have finished (a few minutes at most) confirm that you are bare with:
root:~# rails -v root:~# gem -v root:~# ruby -v
You should get confused looks from your terminal in all cases.
Excellent. Now, we need to install Ruby.
Step 2: Installing Ruby 1.9.x
Normally, I try to use the package management system wherever possible. In this case, though, CentOS is apparently behind the curve with its available Ruby versions. So we’re going to download the source, compile it ourselves, and rock out. (reference source)
I’m going to download the source to /usr/share/src — feel free to put yours wherever you like.
root:~# cd /usr/share/src root:~# curl ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p0.tar.gz -o ruby-1.9.3-p0.tar.gz root:~# tar xvf ruby-1.9.3-p0.tar.gz
Before we get any further, we need to formally add libyaml. YAML is necessary for the psych/syck features, which are necessary in Rubygems. (reference source)
Again, assuming you’re doing this in /usr/share/src.
root:~# cd /usr/share/src root:~# wget http://pyyaml.org/download/libyaml/yaml-0.1.4.tar.gz root:~# tar xzvf yaml-0.1.4.tar.gz root:~# cd yaml-0.1.4 root:~# ./configure --prefix=/usr/local root:~# make && make install
This gave me a little bit of difficulty, but appeared to resolve after I logged out and logged back in. Check the –prefix that you use for this. It will need to mesh with the argument you use with the Ruby configuration.
Back to Ruby.
root:~# cd /usr/share/src/ruby-1.9.3-p0/ root:~# ./configure --prefix=/usr/local --enable-shared --disable-install-doc --with-opt-dir=/usr/local root:~# make && make install
This will take a while. I think it took about 10 minutes. Maybe a little longer. Go do something else in the meantime. When you’re done, check your installation:
root:~# ruby -v ruby 1.9.3p0 (2011-10-30) [x86_64-linux] root:~# gem -v 1.8.11
If the latter command gives you error messages (probably complaining about libyaml) try logging out and logging back in. If that still doesn’t work, you’ll need to do a
make clean in the Ruby source directory, then go back to libyaml,
make clean there, and then try yet again, tweaking the settings. It took me a few times, but I was able to get it to work, eventually, with the options above.
Next up, we install rails.
Step 3: Installing Rails
This is actually really easy.
root:~# gem install rails
Takes a couple minutes. When it’s finished:
root:~# rails -v Rails 3.2.8
The rest of the stuff I like to do as my normal user, which means that sudo will be required. If you haven’t already, you should probably configure your sudoers file to have your normal user. Let’s take a moment to do this (if you and sudo are old pals, you can skip this step)
OPTIONAL Step Π: Configuring sudo
Because giving all privileges to a normal user on a remote server is kind of a bad thing, we want to restrict the sudoers list so that our normal user account (we’ll call it “mortimer”) only has access to stuff that it needs to. In this case — some rails features and convenience features.
First, load up the sudoers file:
This will load the sudoers file in your default editor. I’m going to assume you have not previously touched this. Find a spot that looks fitting and add a line like this (we’ll add “sampson” to the list too):
## User Alias - Developers User_Alias DEVS = mortimer, sampson
This creates a grouping alias called DEVS.
Now create a commands alias for Rails. We will want to specify every command that Rails might need elevated permissions to run. You may need to come back and edit this in the future.
I had to add a separate group (I called it “FILES”) for
/usr/bin/mv — doing
bundle install seemed to want to do file moving. I’m not entirely happy with having to expose this (if anyone has a better suggestion for this, I’m open to it!)
## Command Alias: File utilities Cmnd_Alias FILES = /usr/bin/mv ## Command Alias: Rails Cmnd_Alias RAILS = /usr/local/bin/gem, /usr/local/bin/bundle
(check the path for your executables with the which command, like
which gem and
Look at the other command aliases that might be commented out presently. If any of them have commands you think seem reasonable to give to a normal user, go ahead and uncomment those, noting the alias name. I liked LOCATE (/usr/bin/updatedb, for the locate command). There might also be a SOFTWARE alias (
/usr/bin/yum), which would allow the user to install/remove software.
Whatever you choose, make another definition line, beneath the previous ones created, like this:
DEVS ALL = LOCATE, RAILS, FILES
You could do
LOCATE, RAILS, FILES, SOFTWARE, etc.
Switch over to your normal user account and test out a command:
$ sudo locate ruby
It should prompt you for your normal user password, then a bunch of stuff should appear. If it tells you something about the incident being reported, then the changes did not take correctly.
Back to Rails!
Step 4: Final Rails Details
You’ll need the sqlite3-dev package, or Rails will complain. Either as root, or with sudo if you gave your normal user SOFTWARE permissions:
$ sudo yum install sqlite3-dev
(If that doesn’t work, you can try to find it with:
yum search sqlite3 ).
Now create your first Rails app. We’ll say you’re reinventing Twitter, because every single effing Rails tutorial re-invents Twitter. In fact, we’re going to call it Twitter2.
$ mkdir ~/rails $ cd ~/rails $ rails new twitter2
A lot of stuff should happen. When it gets to bundler it should prompt you for your password to continue. Enter your normal user password and it should complete installing its gems without a problem.
, it will puke a bunch of errors, the first of which advising you to visit the execjs repo on Github. While you are free to grab whichever library you want, I'm going to use the Google V8 engine, called therubyracer here.
Edit your Gemfile and add these lines right below the Rails gem.
gem 'therubyracer' gem 'execjs'
Then install them with Bundler
$ sudo bundle
It should install the missing files.
Test it again with
rails s. It should load up WEBrick and you're all set! You can verify it works by logging into your server with a separate terminal, and doing