Installing Ruby on Rails on Debian Sarge

How to install and run Ruby on Rails applications on Debian Sarge.

Install Rails

1. Install ruby

First, you'll need Ruby.

apt-get install irb1.8 libreadline-ruby1.8 libruby libruby1.8 rdoc1.8 \
  ruby ruby1.8 ruby1.8-dev

2. Install gems

Gems is a package manager. It is to Ruby what CPAN is to Perl or PEAR is to PHP. You will use it a lot to install Ruby extensions - or in this case, install Rails with all the necessary dependencies. Go to the RubyGems website on RubyForge and download the latest version:

cd /usr/local/src
wget http://rubyforge.org/frs/download.php/5207/rubygems-x.x.xx.tgz
tar zxf rubygems-x.x.xx.tgz
cd rubygems-x.x.xx
ruby setup.rb

Note that this will install RubyGems to /usr, which is convenient, but theoretically wrong. I personally feel that this is ok, since RubyGems does not exist as a Debian package and it would otherwise require some effort ensuring that the libraries are found. If you insist on installing RubyGems to /usr/local, read the Installing RubyGems under /usr/local guide on the Rails Wiki.

You should now have a gem command. Check with which gem that it is available on your system.

3. Install rails using gems

Now install Rails.

gem install rails --include-dependencies

You should now have a rails command. It is used to create new Rails applications. Check with which rails that it is on your system.

4. Install database bindings for ruby

Your Rails applications are going to require a database. I suggest you to install support for SQLite3 and MySQL, as the former is very useful for testing purposes or creating ad-hoc databases, and the latter is what you are probably going to use in a production environment.

Two steps are required to make the database bindings work: First, the header files have to be installed (these are the packages that end in -dev), then we are installing the Ruby bindings for the particular databases. The header files are required because the Ruby bindings contain C code to which has to be compiled first.

For MySQL:

apt-get install libmysqlclient14-dev
gem install mysql

For SQLite3:

apt-get install sqlite3 libsqlite3-dev
gem install sqlite3-ruby

For the installation, you will be presented with a list of versions. Pick the highest version for (ruby). In this case, this would be choice number 2. Don't worry about installing the wrong version - gem can install multiple versions in parallel.

Select which gem to install for your platform (i386-linux)
 1. mysql 2.7.1 (mswin32)
 2. mysql 2.7 (ruby)
 3. mysql 2.6 (ruby)
 4. mysql 2.5.1 (ruby)
 5. Cancel installation
>

5. Troubleshooting

Obviously, things can go wrong.

"extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)"

This probably means that you forgot to install the ruby1.8-dev package. Just do an apt-get install ruby1.8-dev to fix this.

"Could not create Makefile due to some reason [..] Check the mkmf.log file for more details. [..]"

You should do what the error message tells you: check the mkmf.log! Search for this file using find /usr/lib/ruby/gems/1.8/gems/<package name> -name mkmf.log. Usually, this error message appears because you forgot to install the -dev package for the extension you were trying to install. So if you wanted to install the mysql gem, you probably forgot to install the libmysqlclient14-dev first. Do an apt-cache search <nameofprogram> | grep dev to find the appropriate packages.

"installation or configuration problem: C compiler cannot create executables."

Make sure you have a compiler installed. Also, an important package that is often forgotten is libc6-dev. It contains the header files for the GNU LIBC, which is required by about every program out there.

apt-get install gcc make libc6-dev

And if you want to be sure:

apt-get install g++ automake autoconf

Rails Applications

General information on Rails applications.

Rails applications can be run in three modes: production, development and testing. This is controlled via the RAILS_ENV environment variable (the default mode is development). This allows you do define different behaviour for different environments. For example while developing an application, it is desirable that all the source files are reloaded every time the page is executed to reflect the changes that have been made to the code. However, in a production environment this behaviour could mean a performance bottleneck and the files could be kept in cache instead to speed things up. In practice, however, most applications seem to use development and production interchangeably and they forget about testing, which is meant to be used by the unit tests.
Database settings are kept in config/database.yml. This is the only place where the Rails developers are lying, because their claim is that everything in Rails is written in Ruby - well, except this file, which is written in the YAML syntax. Don't worry, it is very intuitive.

A typical configuration for MySQL looks like this:
```
development:
    adapter: mysql
    database: joeapp
    username: joe
    password: 123
    socket: /var/run/mysqld/mysqld.sock
```
Instead of socket: you could also write host: localhost. In most cases, you can leave the testing: untouched. For production:, you can either copy the same block from above or make a reference to it:
```
production:
    development
```
A typical configuration for SQLite3 looks like this:
```
development:
    adapter: sqlite3
    database: db/production.db
```
The database has to be created manually, but the schema can be loaded from the application using rake db:schema:load (rake is the Ruby equivalent of make). This requires that the developer has made a dump of the database schema beforehand using rake db:schema:dump. This dump is then written to db/schema.rb as database independent Ruby code. If the file contains such definitions, you're lucky, if it just contains an empty class definition the developer (for whatever reason) might have thought of another way to create database schema.
All Rails applications have a built-in webserver. You can start it with script/server (make sure the file is executable using chmod +x script/server). This will bind a webserver to port 3000 and your application is ready to launch.

Last modified on 09.09.2006 at 09:38 GMT