Upgrading Request Tracker

I recently upgraded a Request Tracker (RT) environment from version 3.2.2 to version 3.8.7. These are my learnings and thoughts from the experience.

The environment that RT 3.2.2 was running on was an old hand rolled from source deployment on Fedora Core 3. The database was on a separate Debian 4 host running a backported MySQL 4.1.

A new web hosting and database back end was available based on Ubuntu 10.04 LTS and MySQL 5.1. This was the target environment for the upgraded RT.

Based on the available target environment the simplest approach to deliver this upgrade was to:

  • Install and configure RT 3.8.7 from packages on Ubuntu 10.04 LTS. Instructions here.
  • Dump the database using mysqldump from the old MySQL server.
  • Load the DB into the new database server.
  • Run the upgrade steps.
  • Validate the data and functionality.

As I tested and read up on the upgrade steps I soon found that this wasn’t going to be the big hassle I first imagined it to be. The details of the migration went like this:

  • Turn off all inbound SMTP email to the primary mail server. This is necessary as I want any emails bound for our ticketing system to queue up at the senders end as my migration involved a change of host for the ultimate destination for ticket emails.
  • Shutdown the old RT apache instance on the old web server and its MTA as well.
  • Shutdown the new RT apache instance on the new web server and its MTA as well.
  • Use mysqldump to copy the prod RT database to a .sql file on the new database server.

mysqldump –user={rtuser} –password={rtuserpasswd} –host={oldrtdbhost} –opt –skip-lock-tables –single-transaction –default-character-set=binary –databases {rtdbname} > {pathto .sql file}

  • Use mysql to load the .sql file into the new database server.

mysql –user={rtuser} –password={rtuserpasswd} –host={newrtdbhost} < {pathto .sql file}

  • Use the rt-setup-database script on the new RT web server to upgrade the DB from 3.2.2 to 3.7.87.

rt-setup-database –action upgrade –dba {rtuser} –prompt-for-dba-password

  • Build the schema upgrade script.

perl /usr/share/request-tracker3.8/etc/upgrade/upgrade-mysql-schema.pl {rtdbname}:{dbhost} {rtusername} {rtuserpasswd} > {path to schema .sql}

  • Apply the schema upgrade script.

mysql –user {rtuser} –password={rtuserpasswd} -h {newrtdbhost} {rtdbname} < {path to schema .sql}

  • Use the rt-setup-database script on the new RT web server to upgrade the DB from 3.7.87 to 3.8.7.

rt-setup-database –action upgrade –dba {rtuser} –prompt-for-dba-password

  • Start the web server and MTA on the new RT web server
  • Logged in to the new RT instance and made sure it all looked okay. I had to tweak settings in the following locations:
    • The rights all needed redoing. I blew them all away and reassigned rights to my groups from scratch.
    • Because I had started using Exim4 integration I had to go through each queues config and update its correspondence and comment address.
    • I tuned the default dashboard to look more like our original 3.2.2 dashboard. All the new stuff can be turned on later. I didnt want to move the agents cheese too much at first.
  • I then had to jump on our primary MX and fix up all its forwarder configs for our queue email addresses so that emails addressed to our queues would be delivered to the new host.
  • Turned in bound email on the primary mail server back on.
  • Sent and received test messages.

That was it. Of course there were teething problems from the migration. These included:

  • I hadn’t checked the $Organization value in the config of our new RT to make sure it matched the value in the old config. I ended up having to fix it.
  • I had a few problems with the change of the queue correspondence and comment address. The exim4 integration expects a comment address of {queuename}-comment@host.domain.com.au. Our comment addresses didn’t match this and I had to quickly update our forwarder configs to deliver to the correct address on the RT host.
  • I needed to give all the agents the ModifyCustomField right.
  • In my original exim4 reconfigure I hadnt configured exim to rewrite outbound emails from the host so all emails sent from RT left with an address of queuename@host.domain.com.au when what I wanted was queuename@domain.com.au. A quick `dpkg–reconfigure exim4-config` allowed me to turn on the rewriting of sent emails and the address they should be rewritten as.
  • RT will truncate ticket transactions with large bodies. See the MaxInlineBody RTConfig option or have your agents adjust their settings in their preferences.
  • Agents didnt have the right to modify requestor details. Had to grant them the AdminUsers and ShowConfigTab rights.

Somethings I learnt and knowledge I want to retain:

  • To test how exim4 will handle an email address on a host use this command

exim -d -bt {email address}

That’s it. So far things have been running really well.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: