Satya's blog - 2011/05/
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: wget http://production.cf.rubygems.org/rubygems/rubygems-update-1.6.2.gem 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://github.com/wayneeseguin/rvm.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 cd RAILS_ROOT script/plugin install git://github.com/rails/rails_upgrade.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 http://basedotextend.com/, 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 make install cd ~/.rvm/src/ruby-1.9.2-p180/ext/readline ruby extconf.rb make 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 \
~/.rvm/gems/ruby-1.9.2-p180/gems/passenger-3.0.7/ext/apache2/mod_passenger.so
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 => 'http://github.com/paneq/calendar_date_select', :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
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:
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:
|
|