December 5, 2011

One of the first things that Tom Limoncelli talks about in the "Practice of System and Network Administration" is getting a request tracking system in place. While you are not always tracking requests per-say, I have never seen an environment that didn't have tasks, work orders, requests, tickets or some other variant on that theme. Because my roles have always been rather customer facing, whether internal or external, the idea of a ticket system always appealed to me, so here are my reasons you should dive head first into a ticket system, why I chose Request Tracker by Best Practical, and a quick HOWTO on getting RT up and running on Ubuntu/Debian.

Why a Ticket System?

A ticket system is important because email, conversations, sticky notes, etc get lost and forgotten. That is it, plain and simple, but that just scratches the surface of the real power of a ticket system. For starters, tickets make great collaboration spaces for dealing with issues. Everyone involved gets updated when new info is available, and it provides a great blow by blow when you are dealing with the postmortem. The other thing that comes from all of this effort is metrics: Metrics about which users or customers make the most requests, what kinds of requests happen with what frequency, and how long it takes to get certain tasks accomplished. These metrics provide an easy way to justify the need for improvements in ticket throughput like more staff or more staff in specific areas.

Why RT?

Request Tracker, or RT, is fairly simple to get up and running and is extremely easy to bend to meet the needs of most environments. I personally chose RT because of the general ease of setup and the feature fit: Debian has packages for it, it is email based, it has a REST API, and there is a mobile interface and iPhone app.

Sure, there are a bunch of other way cool things you can do with it, but the above are my personal reasons. Being email-based is a huge advantage because of the limited amount of training required to get people started. Instead of sending mail to you, they are going to send to a special email address you create. The REST API is rather new, and I am looking forward to being able to automate ticket creation from scripts and events from Nagios and Munin.

Getting Dirty

The easiest way to get this up and running is using Vagrant. If you aren't familiar with Vagrant, I highly suggest taking a look at the Vagrant site to get it running, as it is much easier to use Vagrant to start playing with RT. Otherwise, I will provide instructions below on getting it installed on Ubuntu and Debian.

Now you should be able to browse to http://[systemname]/rt to get started.

First Steps

If you used Vagrant to bootstrap a test instance, the default password is root:password. Once you are in there are a few things that are worth taking a look at:

Start by going to Tools > Configuration > Global > Group Rights and granting 'Everyone' the right to create tickets. This will allow for people to send mail and create tickets. You may want to revisit this setting once you have a better handle on how you are going to break up your ticket queues.

Add a group for administrative users. The interface for this can be found at: Tools > Configuration > Groups > Create

Go back to Tools > Configuration > Global > Group Rights. Type the name of the new group you just created in the box below 'Add Groups'. Then grant all of the permissions to that group as you see fit.

Add a user for yourself. The interface for this is located Tools > Configuration > Users > Create. Once the user is created, you will likely want to visit the Memberships tab and add the user to the new admin group.

Goto Tools > Configuration > Queues > Select. From there, choose the 'General' queue and then the 'Watchers' tab. Find the new user you created and add them as an 'AdminCC'. This will cause that user to receive email messages when tickets are created or updated.

And welcome to RT!

Notes About Going Production

Make sure that the $rtname setting (what shows up in the ticket subject when dealing with mail) is set correctly. It breaks things if you change it after you have a number of tickets in the system.

The postfix configuration that makes this all work will likely need a bit of tweaking to fit into any given environment.

The actual configuration file for RT is located in the /etc/request-tracker4/RT_SiteConfig.d directory. The update-rt-siteconfig-4 command builds the `/etc/request-tracker4/RT_SiteConfig.pmq file.

Because of the credentials and other potentially sensitive information, you should get an Apache vhost setup with SSL for this site.

For those sites that are heavy Python users, the Roundup Issue Tracker might be useful too -- it's designed to be customised, has web and e-mail input vectors, and both CLI and XML-RPC access. And of course, it's open source too. Check out roundup.sf.net