Request Tracker (RT) is an “enterprise-grade issue tracking system. It allows organizations to keep track of their to-do lists, who is working on which tasks, what’s already been done, and when tasks were completed. It is available under the terms of version 2 of the GNU General Public License (GPL)”. Every system administrator should read The Practice of System and Network Administration, which outlines the need for request tracking. Never hire and promptly fire any system administrator unwilling to use the trouble ticket system.
- Book on RT: RT Essentials.
- Documentation: RT Wiki.
RT supports approvals, so can be used to implement Sarbanes-Oxley (SOX) change control requirements.
Requirements
RT requires a database, a web server, and e-mail support. Some operating systems, such as Debian Linux or FreeBSD, can install RT via their ports system. This greatly simplifies installation.
- Database
- Web Server
MySQL is recommended, though others, such as PostgreSQL, are also supported. I currently run RT with PostgreSQL.
Under PostgreSQL, to use the local socket instead of the network port, set $DatabaseHost to an empty string in RT_SiteConfig.pm.
Set( $DatabaseHost, '' );
Either run a Mail Transport Agent (MTA) on the RT server, or use fetchmail to transfer e-mail from a mail server to rt-mailgate. If using sendmail, ensure smrsh allows rt-mailgate via a symbolic link in the smrsh directory (/etc/smrsh on RedHat Linux). With CFEngine, maintaining a link on current or future request tracker class systems can be accomplished via:
links:
app_sendmail.rt_server::
/etc/smrsh/rt-mailgate ->! ${rt_install_dir}/bin/rt-mailgate
Apache with mod_perl or FastCGI must be used. I use mod_perl1. If running Apache 2, consider using FastCGI instead. When using external authentication such as mod_auth_kerb, the NoAuth areas will need to bypass this authentication. Example configuration for mod_perl1 follows.
<VirtualHost _default_:443>
ServerName www.example.org
AddDefaultCharset utf-8
<IfModule mod_perl.c>
PerlRequire @@RT_INSTALL_DIR@@/bin/webmux.pl
<Location "/rt/REST/1.0/NoAuth">
Order allow,deny
Allow from all
Satisfy any
</Location>
<Location "/rt/NoAuth">
Order allow,deny
Allow from all
Satisfy any
</Location>
Alias /rt "@@RT_INSTALL_DIR@@/share/html"
<Directory "@@RT_INSTALL_DIR@@/share/html">
SetHandler perl-script
PerlHandler RT::Mason
Options Indexes SymLinksIfOwnerMatch
AllowOverride All
AuthType KerberosV5
AuthName "Kerberos Login"
Krb5Keytab /etc/krb5.keytab.apache
KrbAuthAuthoritative on
KrbAuthRealm EXAMPLE.ORG
require valid-user
<Limit GET PUT POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET PUT POST OPTIONS PROPFIND>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
</IfModule>
SSLEngine on
…
</VirtualHost>
Queues
Queue setup depends on the site. For educational departments, consider a different queue for each lab group, so the lead faculty can have oversight rights on all activity related to the lab. For systems administrators, create groups with rights to at minimum see what goes on between the different queues, to help share knowledge. The following shows example aliases(5) entries for RT.
rt-admin: "/etc/smrsh/rt-mailgate --queue Admin --action correspond↵
--url https://www.example.org/rt"
rt-admin-comment: "/etc/smrsh/rt-mailgate --queue Admin --action comment↵
--url https://www.example.org/rt"
rt-test: "/etc/smrsh/rt-mailgate --queue TEST --action correspond↵
--url https://www.example.org/rt"
rt-test-comment: "/etc/smrsh/rt-mailgate --queue TEST --action comment↵
--url https://www.example.org/rt"
For finer control over what gets to RT, feed incoming requests through procmail.
Debugging
The rt-mailgate script can be tested from the command line. Also be sure to review the logfiles for the webserver for errors. RT logging options are detailed in the RT_Config.pm file, though should be set in the RT_SiteConfig.pm file.
$ (echo Subject: test; echo; echo test) | \
rt-mailgate --queue TEST --url https://www.example.org/rt --action correspond
More information on debugging Unix systems is available.
Upgrading
The RT documentation covers this, though an often missed step is the upgrade of the database schema using the rt-setup-database command. Once the database from the old server is available, run the rt-setup-database command with the --action schema, --action acl, and --action insert options in turn, for every directory under etc/upgrade under the RT sources.
