Wednesday, February 06, 2013

Redmine migration tips and tricks

At work we have a really ancient instance of Redmine (0.8.4) married to a mysql database. Since Redmine has already gone through 1.x versions and is now at 2.x - I decided it was time to move on - at the same time I moved the instance to a new machine running nginx and mysql server 5.1. I followed these instructions to get Redmine behind an nginx instance. * I produced a mysql dump of the old instance and moved it over to the new server. * I then generated the secret token (in older versions it is "rake generate_session_store" and in 2+ it is "rake generate_secret_token") * After that I ran the normal "rake db:migrate RAILS_ENV=production" on an empty database (make sure you created the database in Redmine and the redmine user and granted the privileges to the database to the said user!) I did the last step to be able to get the "users" table from the 2.x+ Redmine version which adds a "salt" column to the table - this salt is used to hash the passwords. This table will only have one use upon a fresh install - the "admin" with the default "admin" password which is properly hashed and stored. After this was done I proceeded to launch the mysql client and drop and recreate the Redmine database and re-grant all the privileges. The next step is to load the dump from the 0.8.4 database and run the migrate script again ("rake db:migrate RAILS_ENV=production" and re-generate the token as above). The mysql database now has the "old" 0.8.4 data that has been migrated. However, you will NOT be able to log in since the migration script does not know how to use the salt to recreate the hashed passwords properly. Use the users table you dumped from the fresh 2.x+ install that has the "admin" user and its credentials and associated salt in it to replace the migrated user's table's "admin" hashed_password and salt fields. Exit mysql client, restart nginx and point your browser to the instance - it should all work now!