Satya's blog - 2011/05/

May 29 2011 16:03 Rails 3 upgrade on ubuntu

Spent several hours yesterday upgrading an Ubuntu running Ruby on Rails 2.x to Rails 3.

Starting with an Apache running passenger, ruby from Ubuntu repositories, and Rails 2.x from gems, we'll end with a fully rvm'd system, bundler, etc.

First upgrade rubygems to 1.6.2 by downloading, because ubuntu rubygems packages are hopelessly outdated:

sudo gem install rubygems-update-1.6.2.gem
sudo /var/lib/gems/1.8/bin/update_rubygems

Verify with gem -v, which should produce 1.6.2.

Install rvm and other dependencies. You need readline, and the dev libs to compile it. Install it now, save headaches later.

sudo apt-get install git-core tig libreadline-ruby \
    libncurses-dev libreadline-dev

Install rvm via git:

mkdir -p ~/.rvm/src/ && cd ~/.rvm/src && rm \
    -rf ./rvm/ && git clone \
    git:// && cd \
    rvm && ./install

Add this line to the end of .bashrc. See the rvm web site for details on why and how.

[[ -s "~/.rvm/scripts/rvm" ]] && source "~/.rvm/scripts/rvm"

Install ruby 1.9.2, passenger, and the rails upgrade checker plugin, and set up Gemfile. The first step, i.e. the ruby 1.9.2 install, takes time. This sets the new ruby as the default, installs newest rails and passenger, goes back to old ruby to install the rails upgrade helper plugin, sets 1.9.2 as the default for everyone plus passenger, pulls new Rails skeleton into your app, and installs bundler.

rvm install 1.9.2
rvm 1.9.2 default
gem install rails passenger
rvm system
script/plugin install git://
rake rails:upgrade:backup 
rvm 1.9.2 --default --passenger
rails new .
# (bunch of fiddling with environment.rb, application.rb, routes.rb)
gem install bundler

Add required gems to Gemfile in RAILS_ROOT, so you get non-broken mysql and rake:

gem 'mysql2', '< 0.3'
gem 'rake', '0.8.7'

Set the Gemfile.lock file with correct permissions. Then install the gems.

touch Gemfile.lock
sudo chown www-data.YOURUSERLOGIN Gemfile.lock
sudo chmod 664 Gemfile.lock
bundle install

Run `bundle check` in a rails application's directory (RAILS_ROOT) to find out what gems to install. It'll tell gem name and version number.

Thanks to, I found out how to compile openssl support in order to install passenger properly. Compile readline while you're at it:

cd ~/.rvm/src/ruby-1.9.2-p180/ext/openssl
ruby extconf.rb
make install

cd ~/.rvm/src/ruby-1.9.2-p180/ext/readline
ruby extconf.rb
make install

Now the actual passenger install. This will ask to install some development libraries, so install them using "sudo apt-get install list of packages that it gives" and run it again (i.e. run once to find out what it wants, install the dev libs, run again):

~/.rvm/src/rvm/binscripts/rvmsudo  passenger-install-apache2-module

It should eventually spit out the right Apache config, something like this:

LoadModule passenger_module \

PassengerRoot ~/.rvm/gems/ruby-1.9.2-p180/gems/passenger-3.0.7
PassengerRuby ~/.rvm/bin/passenger_ruby

The LoadModule line should go in /etc/apache2/mods-enabled/passenger.load and the other two will go in /etc/apache2/mods-enabled/passenger.conf. It doesn't matter, both files are loaded, but that's how Apache is organized on Ubuntu.

Remove passenger and readline compilation libraries:

sudo apt-get remove build-essential libcurl4-openssl-dev libssl-dev \
    zlib1g-dev libopenssl-ruby apache2-prefork-dev libapr1-dev \
    libaprutil1-dev libncurses-dev libreadline-dev

If you're using calendar_date_select on Rails3, there's a gotcha. Some weird interaction between git and bundler on rails 3 causes issues, so you have to muck with the Gemfile. First put this in the Gemfile (all one line):

gem 'calendar_date_select', :git =>
:branch => 'rails3test'

Then install the source, compile the gem and inject the gem into rvm:

bundle install
cd ~/.rvm/gems/ruby*/bundler/gems/calendar_date_select*
gem build calendar_date_select.gemspec
gem install ./calendar_date_select
# Change Gemfile to:
gem 'calendar_date_select'

You have to switch the gemfile around every time you run bundle install. Ugh.

Last updated: May 29 2011 16:49

Tag: rails3 howto

May 20 2011 07:33 Password storage security

I have a system that stores passwords encrypted, with a one-way algorithm (meaning that in most cases, it's nigh-impossible to get the password back from what is stored).

e.g. "password" becomes 286755fad04869ca523320acce0dc6a4i (the "hash"), but given what's stored in the database: 286755fad04869ca523320acce0dc6a4, it's almost impossible for anyone to know that the password is "password". So if the database is stolen, no one can read the passwords. (That hash was possibly generated with a newline.)

When someone registers their account, the password they type is stored as a hash. When they log in, the password they type is hashed and compared (along with the login) with the database. Match, means they are who that database record says they are, and can log in.

Problem: there are available "rainbow tables". These are huge computer-generated lists of common words and phrases that people use as passwords. All an attacker has to do is compare the tables with the database, and see that the database contains 286755fad04869ca523320acce0dc6a4 and the table maps that to "password". The username and email are there already, so now they can try this info at a banking site. Most people use the same or similar passwords everywhere.

These attacks have happened on other sites.

A solution: instead of hashing "password", combine it with something else like "s3cret". This is called a salt. So now we hash "s3cretpassword". If someone's password is swordfish, we hash "s3cretswordfish". The hash for both of these is:
dba68374e08f8757483a58fa7550d803 s3cretpassword
8a8e32bdfe2504db405cb0fa004d0026 s3cretswordfish
and also:
286755fad04869ca523320acce0dc6a4 password

Of course we choose something a little more complicated than s3cret. So generating rainbow tables using all possible salts is impossible, so we're back to storing in the database an impenetrable string, which is also unique to our site. So someone who has stolen our database (it happens, not to us because we don't leave our database on thumb drives and laptops) will not be able to decrypt even lame passwords like "password". Our password checker does not even allow "password" but now there is an extra and better layer of security.

So, we have:

  • salted passwords against rainbow table attacks
  • password strength requirement (which security experts say is lame, and I agree, because it actually reduces the number of possible passwords, making automatic guessing easier. And also encourages people to use the same password everywhere, and write it down, etc.)
  • and password guess throttling (you get locked out temporarily after a small number of bad logins) to defend against automatic guessing.

Tag: howto password