Ubuntu 9.04 : How to Install Ruby on Rails 2.3.3 [15th August 2009]

CCH : These are the steps that I took to install Ruby on Rails to an IBM Thinkpad with 1G RAM and a 75G Hard Disk and installed with Ubuntu 9.04.

Ruby installation

Firstly, I clicked Applications/Accessories/Terminal to launch the Terminal and typed the following command to update the repositories.

sudo apt-get update

next, to upgrade the system :-

sudo apt-get dist-upgrade

The installation took afew minutes and also required approximately 100 MB disk space.
On succesful updating, I started to install Rails.
sudo apt-get install ruby ri rdoc irb libopenssl-ruby ruby-dev

Note : Rails prerequisites include :-
ruby = An interpreter of object-oriented scripting language Ruby
ri = Ruby Interactive reference
rdoc = Generate documentation from ruby source files
irb = Interactive Ruby

Ruby Gem installation

Next, I started to install the Ruby gem package manager by firstly downloading ad the latest Ruby gems .35 via the following link.
http://rubyforge.org/projects/rubygems/

Download and extract the files.

tar xvzf rubygems-1.3.5.tgz
cd rubygems-1.3.5
sudo ruby setup.rb

I then deleted the .tgz file and rubygems directory.

cd ..
rm -r rubygems-1.3.5 rubygems-1.3.5.tgz

Next, I set out to create a set of simlinks. Otherwise it will be a tedious task to type commands with the version (1.8). For an example if we need to call the gem command we’ve to type gem1.8.

sudo ln -s /usr/bin/gem1.8 /usr/local/bin/gem
sudo ln -s /usr/bin/ruby1.8 /usr/local/bin/ruby
sudo ln -s /usr/bin/rdoc1.8 /usr/local/bin/rdoc
sudo ln -s /usr/bin/ri1.8 /usr/local/bin/ri
sudo ln -s /usr/bin/irb1.8 /usr/local/bin/irb

Rails Installation

I then installed Rails using gem.

sudo gem install rails

Server Installation

FYI, Rails by default comes with the WEBrick server. But like most Rails developers, I prefer the Mongrel server and typed the following command to install Mongrel server as well as passenger 2.2.4 and capistrano 2.5.8 for deployemnt purposes

sudo gem install mongrel passenger capistrano

TIP : If you got any error while installing the Mongrel server, install the ruby-dev / ruby1.8-dev and try again.

sudo apt-get install ruby-dev

Database Installation
Rails 2.3 shipped with SQLite3 as it’s default database instead of MySQL. You can install SQLite3 libraries by following commands.

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

Since I prefer MySQL,

sudo apt-get install mysql-client libmysqlclient15-dev
sudo gem install mysql

Create Ruby on Rails App

With no error mesages, I proceeded to create a new Ruby on Rail application by following command :-

rails test_app

As I needed MySQL support, I typed :

rails test-app -d mysql

Run the app

cd test_app
script/server

I then point FireFox to http://localhost:3000
and bingo I succeeded in launching my first RoR apps on Ubuntu :-)

Announcements : Instant Rails 2.0 Released on 28th December 2007

Rob Bazinet has announced on 28/12/07 the release of Instant Rails 2.0. This is his first release after taking over the project for Curt Hibbs.

This release is part of bringing the environment up-to-date, no earth shattering changes but the following is updated:
- Ruby 1.8.6 Patch Level 111 with tons of bug fixes and new updated gems
- Ruby on Rails 2.0.2
- RubyGems 1.0.1
- Rake 0.8.0
- Mongrel 1.1.2
- SQLite3

Instant Rails 2.0 can be downloaded from RubyForge now<http://rubyforge.org/frs/?group_id=904>

For the Release Notes, go to <http://instantrails.rubyforge.org/wiki/wiki.pl?Release_Notes_For_Instant_Rails_2.0>to see all the updates.

Questions should be submitted to the Instant Rails list <http://rubyforge.org/mail/?group_id=904>


-Rob Bazinet http://www.accidentaltechnologist.com/

Advanced Rails : Why you should not use Global Variables ! [Updated 12th Sept 2009]

What are global variables in Ruby ?

A global variable has a name beginning with $. It can be referred to from anywhere in a program. Before initialization, a global variable has the special value nil.

Global variables should be used sparingly. They are dangerous because they can be written to from anywhere. Overuse of globals can make isolating bugs difficult; it also tends to indicate that the design of a program has not been carefully thought out. Whenever you do find it necessary to use a global variable, be sure to give it a descriptive name that is unlikely to be inadvertently used for something else later (calling it something like $foo as above is probably a bad idea).

When a global variable has been rigged to work as a trigger to invoke a procedure whenever changed, we sometimes call it an active variable. For instance, it is useful for keeping a GUI display up to date.

There is a collection of special variables whose names consist of a dollar sign ($) followed by a single character. For example, $$ contains the process id of the ruby interpreter, and is read-only. Here are the major system variables and their meanings (see the ruby reference manual for details):

$! latest error message
$@ location of error
$_ string last read by gets
$. line number last read by interpreter
$& string last matched by regexp
$~ the last regexp match, as an array of subexpressions
$n the nth subexpression in the last match (same as $~[n])
$= case-insensitivity flag
$/ input record separator
$\ output record separator
$0 the name of the ruby script file
$* the command line arguments
$$ interpreter's process ID
$? exit status of last executed child process

In the above, $_ and $~ have local scope. Their names suggest they should be global, but they are much more useful this way, and there are historical reasons for using these names.

Why you should not not use Global Variables

Let us assume that on login (say using Acts As Authenticated), you may be tempted to initialise say $is_admin = current_user.isadmin and then use $is_admin to control access to modules or whatever. This will work very nicely in development mode or even production mode under say Apache 2.x + 1 mongrel process.

However, once you use Apache 2.2x + a pack of mongrel processes, your security measure will fail miserably ! Why ?

Prior to using Apache+a pack of mongrels, I was succesfully using a home-made role-based authentication in conjunction with AAA.

What I did basically was to add roles in users (AAA table) via adding fields (such as is_admin, is_marketing, is_finance etc). The result is that a user can can have one or many roles.
With this concept, I could control access to modules using layouts and within each controller or model I can control access to specific actions.


1. Control access to specific actions via controller.

EXAMPLE in customers_controller.rb
layout 'customers'
active_scaffold :customer do config

if User.current_user.is_admin
config.nested.add_link("Receivables", [:receivables])
end

2. Control access to specific actions via model

has_many :receivables

def authorized_for_update?
current_user.is_finance
end

def authorized_for_destroy?
current_user.is_admin
end


Using 1-3 works perfectly on Apache+1 mongrel on a Windows 2003. But once I activate Apache + 2 or mongrels, the whole security system got thrashed !


Response from Jan (Mongrel FAQ)

Globals are not shared across different instance of mongrel. To have a global appear in all instances you need some form of permanent storage (filesystem or database). If it doesn't need to change over the lifetime of the program you can pass in the global at startup in an environment variable.

You would not want to use a global in this case, since it needs to change after start up and the other mogrels would not be aware of the change. Use permanent storage. File system, database, or perhaps even a cookie

Response from Luis (author of mongrel windows service)

As Jan pointed, global variables aren't shared across processes.
You need rely your authorization schema in something else instead a global variable, since 2 users could hit the same mongrel instance and both get great as admin.
You need to investigate further about authorization schemas and how session is handled (and could be used for your purpose).

First you need to move your session storage to ActiveRecord or cookie based (in case of 1.2.5 or edge). Then I suggest you take a look at the following plugins for Authentication:

RESTful Authentication:
http://railsify.com/plugins/3-restful-authentication

Acts as Authenticated: http://technoweenie.stikipad.com/plugins/show/Acts+as+Authenticated

Later you will need some role management (to handle is_admin?) Take a look at the suggestion and the "Elsewhere" part from the Acts as Authenticated stikipad page.


My solution was to use the role_requirement plugin by Tim Harper.

This link is also relevant to our discussion here.