How To Configure Request Tracker For Keeping Track Of User Support Requests

Keeping track of support requests and bug reports, if not handled properly, can take away from otherwise productive work time. If you have to handle thousands of user requests, keeping track of which problems are more important than others could be a full time job. A request tracking system can simplify tracking and recording of transactions on those requests. This is where Request Tracker comes in. Best Practical Solutions, LLC has created Request Tracker (typically abbreviated RT) to handle this task quickly and easily.

Features
Request Tracker started from a need to track user requests. In version 1, RT was very basic. Requests were divided into queues, and each staff member was given rights to the queues they were responsible for. In a setup with many staff members, setup was tedious. Thankfully, RT gained a large community of users to give feedback on how to handle requests. As it has matured, additional features have been added to simplify setup and administration. When RT version 2 (commonly called RT2) was released, user defined groups greatly simplified user administration. The web interface was completely redesigned for RT2. RT3 revamped the searching interface, with another search upgrade in the works for the upcoming 3.2 release. As of RT2, the ability to have "RT Self Service" has also been available.

To understand self service, first we need to look at the different types of RT users. RT classifies users as either privileged or unprivileged. Typically, privileged users are staff members, while unprivileged users consist of everyone else who has submitted a request. RT3 automatically creates unprivileged users whenever a request is submitted by a new user. Self service is useful when you allow these unprivileged users to log in and view requests which they submitted. Instead of continuing to ask "Is this done yet?" they can see for themselves what progress has been made.

Setting up RT - Requirements
Installing and configuring RT is fairly straightforward, but it is a long process. This article will discuss the installation of RT version 3.0.9 on a system running Apache 1.3.29 with mod_perl, MySQL, and the Sendmail mail transfer agent. RT is written entirely in Perl, which means it will run on Linux and most Unix systems. The system I will describe is not the only option, however, it is probably the most common. RT can be installed with any combination of the services listed here:

Web server: Apache 1.3.x/2.0.x, or any webserver capable of running with FastCGI

Database: MySQL, Postgres, Oracle (as of 3.x), and Informix

Mail Transfer Agent: Sendmail, Exim, Postfix, or any other sendmail compatible agent

Perl: Perl 5.8.3 is recommended, any 5.8.x version will work

Configuring the web server, database, mail transfer agent, and Perl are beyond the scope of this article. I am assuming that you will be installing RT on an already running web server, which is the easiest and fastest way to set up.

Since RT is written in Perl, it will require some Perl modules. The list is rather long, but RT can automatically install most of them for you.

Let's download RT and start installing it. You can download RT from the company web site. Unpack the distribution, and enter the directory it created (should be rt-3-0-9).

Installing RT and Required Modules
The first thing we want to do is configure RT. There are many options to the ./configure script, but they are very self explanatory. I would recommend creating a system group called rt, and adding RT administrators to that group. Next, run ./configure:

./configure --prefix=/opt/rt3 --with-rt-group=rt --with-db-type=mysql --with-db-host= --with-db-rt-host=localhost --with-db-dba=your database admin username --with-db-database=rt3 --with-db-rt-user=rt3user --with-db-rt-pass=some password --with-web-user=your web user (like httpd or www) --with-web-group=your web group

No, the --with-db-host= is not a mistake. If you are running MySQL on the same host as the webserver, this will make the database interaction faster, because it knows you want to connect to the local MySQL server.

Once ./configure has run, you need to check the perl module dependencies. Simply run perl sbin/rt-test-dependencies --with-mysql --with-modperl1 and it will display a list of required modules, and if a module is not found, it will display MISSING instead of the module version number. If you are missing dependencies (which you almost certainly will be), rerun the dependency script with the --install option. This will use Perl's CPAN module to automatically download and install the missing modules.

Modify RT's Defaults
RT's defaults are set up for most systems, but there are a few variables which need to be modified. The easiest way to change default settings is to change to the /opt/rt3/etc directory and look at RT_Config.pm. Any configuration changes should be made in the file RT_SiteConfig.pm. Copy any lines from Config to SiteConfig and change them as you need to. The options are all well commented in the configuration file, so you should not have problems seeing what needs to be changed. Note: Make sure that RT_SiteConfig.pm has 1; as the line of the file. The configuration file is a Perl module, and all Perl modules end with 1;.

Creating the Database
When the dependency script is finished, run it one more time without the --install option, just to make sure everything is set to go. If everything is found, you may run make install to copy RT into /opt/rt3. The next step is to create the database, which RT will tell you how to run. Simply type make initialize-database, and another perl script will start to create the RT database. If the initialization fails, type make dropdb and correct any problems listed. The most common error is not setting the db-host and db-rt-host options correctly in the ./configure script.

Update Webserver Configuration
Once the database is done, we can modify Apache's configuration file to run RT. If you want to run RT as a subdirectory of your main webserver (which I recommend, since the webserver is already configured that way), you need to make only minor changes to your configuration. Open your httpd.conf file, and add the following lines (preferably in an SSL-enabled section, if you have one):

Alias /rt3 /opt/rt3/share/html
PerlModule Apache::DBI
Location /rt3
   PerlRequire /opt/rt3/bin/webmux.pl
   SetHandler perl-script
   PerlHandler RT::Mason
/Location

Run apachectl configtest to ensure that your configuration file is valid, and if so, run apachectl restart. Note: Running apachectl graceful will not work, as it does not cleanly restart mod_perl.

Configuring Mail Transfer Agent
Still with me? This is the last part of the system configuration: Sendmail. In general, you want to allow users to create requests which automatically are placed in the correct queue. To do this, you use the rt-mailgate program as part of an email alias. You will add one alias for each queue you want to allow users to create requests in. For example, if you have the General (default), unix, and micro queues, you could setup [email protected] to create General requests, [email protected] to create unix requests, and [email protected] to create micro requests. Since the names of the aliases and queues are entirely unrelated, you can use any alias to point to any queue, however, to keep your sanity, you should use a similar term for each alias. In your alias file (such as /etc/mail/aliases) you will need to add the following lines: helpdesk: |/opt/rt3/bin/rt-mailgate --queue General --action correspond --url http://yourcompany.com/rt3 helpdesk-comment: |/opt/rt3/bin/rt-mailgate --queue General --action comment --url http://yourcompany.com/rt3 Now restart your mail transfer agent. When someone send an email to [email protected], RT will create a request in the General queue, and a default auto-response will be sent to the sender announcing that a request was created. Each request is assigned a unique serial number which is placed in the subject of the auto-response. If the user responds, if the serial number exists in the subject, the email will automatically be attached to the pre-existing request. If an email is sent to helpdesk-comment and has a serial number, the email will be attached as a comment, which is not visible to requesters.

Login and Configure Queues, Groups, and Users
When you first browse to http://mycompany.com/rt3, you should be presented with a login screen. The default username is 'root' and the password is 'password'. Change this in the preferences immediately upon logging in! Not changing this leaves your RT system open to anyone who tries to log in with the default information.

Now that you can log in to RT, you should enter the Configuration menu on the left side of the screen. There, you will find options for handling queues, users, groups, templates, and scrips. Scrips are the scripts set up to handle the auto-replies and other automated functions of RT. Templates are the mail templates used when RT sends mail to a user. Queues, users, and groups are self explanatory.

Creating new users, queues, and groups is very simple. Click on which you want to create, and select 'New <item>' on the left side of the screen. Enter the details for the item, and click submit.

I recommend creating queues first, then groups, and finally users. Once you have all those created, you can set permissions on the queues. The easiest way to do this is to modify group rights for each queue and then add users to the proper groups. To modify the group rights, click on 'Queues', select the queue you want to modify, and select 'Group rights' in the menu. You will see a screen with several scroll boxes full of options. You should grant the 'CreateTicket' right to everyone, or no one can create tickets in the queue. Then scroll down to the user defined groups and grant the appropriate group the rights you want. There are many options, but they have descriptive names which help you decide who needs each right. Keep in mind that not every right needs to be granted.

Pros and Cons
RT has many benefits, but it is not without drawbacks. When first installed, RT requires very few resources. As the number of tickets grows, the requirements grow. If you optimize your database, you can increase the speed of searches and information display. Another drawback and benefit is that all data is stored in the database. This makes the database slower as it collects more data, but it allows searches on more data. The first version of RT stored emails and comments in a directory on the file system. It was still possible to search for data, but much slower, since the data was not indexed.

Aside from these minor performance drawbacks (which typically are not very noticeable even with over 40,000 tickets), the benefits greatly outweigh them. The ability to track problems and store them for future reference is invaluable. In my experience, RT has greatly improved productivity by giving a graphical interface to the work to be done. Once people are shown the power of RT, they often can't imagine handling requests without it. It truly is an amazing and powerful tool for anyone who handles any number of requests.

Jeremy Baumgartner ([email protected]) is a UNIX systems administrator for the College of Engineering at the University of Wisconsin Madison. He maintains the college's jabber and web servers as well as developing site specific software.