Installing and Implementing RT: Request Tracker Guy Dickinson New York University Information Technology Services Technology

Security Services guy.dickinson@nyu.edu October 2005 Revised April 2006 Disclaimer For Public Release: This document, its contents, and instructions are supplied without a warranty of any kind. Neither the author nor New York University take any responsibility for consequences resulting the use of any of the included code snippets or configuration examples. This is intended as a case study and basic configuration guide for interested parties, not a replacement for commercial support, or the Best Practical FAQ, Wiki, and documentation. Please refer technical questions to Best Practical, at http://www.bestpractical.com

Outline I. Introduction a. About RT b. Purpose and Scope c. Goals, Requirements and Pre-Install Considerations d. Limitations e. Testing Prerequisites a. Hardware b. Operating System c. Software Dependencies Installation a. Procedure Customization a. Queues b. Users and Permissions c. AdminCCs d. Templates e. Scrips f. Web Interface Known Problems and Solutions Acknowledgements, Further reading

II.

III. IV.

V. VI.

I. Introduction This paper is designed to give some insight into the procedures used to implement the RT ticketing system for Technology Security Services at NYU. In the event of catastrophic failure or any other need to duplicate this setup, it is hoped that this document will provide the necessary and relevant information to understand the methods used to create this installation of RT. It is assumed that the reader of this document has a basic to intermediate knowledge of *NIX-type operating systems, and at least a rudimentary knowledge of Perl. Helpful references to have on hand when attempting this installation may be Learning the bash Shell and Programming Perl (OReilly Press). This paper denotes shell commands with fixed width font preceded by a dollar sign ($) to represent the shell prompt, and configuration file lines by this font. a. About RT RT (Request Tracker) is an open-source, enterprise-grade ticketing system. Its function, at a most basic level, is to keep track of tickets, each of which represents a task to be completed, a conversation to be had, or a similar trackable item. RT has many advantages over other ticketing systems, most notably its open architecture and emailfriendly interface. RT is developed by Best Practical, Inc. New York University currently has a bronze support contract with Best Practical, allowing for a set amount of questions to be asked per year. As of this writing (October 2005), no questions have been asked for this year. b. Purpose and Scope The user of the RT system in this case is NYU ITS Technology Security Services (TSS). TSS had for some time been using a customized version of RT designed for Incident Response, known as RTIR. While it was hoped that the RTIR model would work well for TSSs tasks, in practice, the interface and architecture was found to be too overcustomized for TSSs requirements. RT itself, however, seemed to be a solid backend product that could be adapted for the needs of TSS. Before TSS used any sort of ticketing system, each staff member would be subscribed to the organizational list security@nyu.edu. This was a high-volume list that also received mail sent to abuse@nyu.edu and copyright.info@nyu.edu. Correspondence to this list would be relayed to every staff member, and by convention, each staff member would CC security@nyu.edu on any outgoing correspondence with a From: line of security@nyu.edu. The general work structure of TSS has each permanent staff member rotated through an on-call position on a weekly basis. This staff member is responsible for dealing with all incoming email messages to security@nyu.edu, and delegating tasks when appropriate. A ticketing system lends itself naturally to this division of labor, as well as seamlessly tracking conversations with outside parties week-to-week, regardless of the staff member on call. Additionally, the often-time sensitive nature of Incident Response dictates that critical interactions with outside parties end with a successful resolution of the problem. A well functioning ticket system assists with this goal as well.

c. Pre-Installation Considerations There were a number of considerations to be taken into account before installation began: The system should have an open architecture that would fit the workflow of TSS in general, and allow the user to use the system in a manner that fits their work pattern. The system should be as transparent as possible for external correspondents The systems internal email interface should be as transparent as possible. The system should lend itself to scripting via the shell for automatic notification of outside parties. RT, in its un-customized state, fits most of these requirements already. Only a few changes to the RT system were required to get the system to function in the most efficient manner for the requirements of TSS. d. Testing Before installation of RT began on real hardware, several test installations were made on a VMWare virtual host running CentOS Linux 4.1. This allowed fast reversion of changes in the event that catastrophic errors occurred. CentOS (http://www.centos.org) is a free version of Red Hat Enterprise Linux, compiled directly from the public sources available from Red Hat. Given our intention to eventually use Red Hat AS 4.1 for our final installation, it made sense to use the most compatible OS possible. Testing repeatedly, while frustrating at times, was ultimately extremely helpful in finding the inevitable bumps in the road during the installation procedure. Similar testing is recommended for future installations of RT on different hardware or with a different operating system backend. II. Prerequisites 1. Hardware Best Practical does not explicitly list hardware requirements for RT. However, since it is a database-driven application, it is logical to assume that the greater the amount of RAM and CPU available to RT, the smoother it will run. For this installation the following hardware was used: Dell PowerEdge 1650 2GB RAM Dual CPU (Intel Xeon) 2x 30GB IDE Hard Drives in a RAID-1 array

2. Operating System RT is highly dependent on Perl for its backend. While, in theory, it is possible to run RT on an array of operating systems, it is logical to run RT in Perls native environment, *NIX/Linux.

In this instance, RT is running on Red Hat Enterprise Linux AS 4.1. The OS is locked down in accordance with the standard TSS Linux server lockdown procedure. See the appropriate documentation for details on the security measures in place on this server. 3. Sofware Dependencies RT requires a number of dependencies to be satisfied for a successful installation: Apache httpd MySQL Mod_perl Mod_ssl (Version 2.0.52) (Version 4.1.10a) (Version 2.0.1) (Version 2.0.52)

Additionally, these Perl module are required. RT has a built in script that is run at installtime to download these dependencies via CPAN, but they are explicitly stated here. Core Dependencies Text::Template File::Spec 0.8 HTML::Entities HTML::Scrubber 0.08 Net::Domain Log::Dispatch 2.0 Locale::Maketext 1.06 Locale::Maketext::Lexicon 0.32 Locale::Maketext::Fuzzy MIME::Entity 5.108 Mail::Mailer 1.57 Net::SMTP Text::Wrapper Time::ParseDate Time::HiRes File::Temp Term::ReadKey Text::Autoformat Text::Quoted 1.3 Tree::Simple 1.04 Scalar::Util Module::Versions::Report Cache::Simple::TimedExpiry XML::Simple Mason Dependencies Params::Validate 0.02 Cache::Cache Exception::Class 1.14 HTML::Mason 1.23 MLDBM Errno FreezeThaw Digest::MD5 2.27 CGI::Cookie 1.20 Storable 2.08 Apache::Session 1.53

Other Dependencies Other additional parts of this RT installation have separate dependencies. These will be covered later in this document. A note on mod_perl As of this writing, the RT Documentation suggests that mod_perl 1.x is still supported. This is not the case! Make sure to use mod_perl 2.x, from http://perl.httpd.org. III. Installation Procedure The following instructions are adapted from RT Essentials (Vincent, Spier, Rolsky, Chamberlain, Foley 2005) and an RT Wiki post at http://wiki.bestpractical.com/index.cgi?RHEL4InstallGuide a. Pre-installation Install prerequisite packages with up2date: o httpd o httpd-devel o mysql o mysqlclient10 o mysql-server o mysql-devel o gcc o sendmail-cf Uninstall mod_perl 1.x if it was installed automatically Install mod_perl from source o See the mod_perl documentation. Note that mod_perl must be compiled as a dynamic shared object (DSO) unless you have an httpd source tree on hand. By default, RHEL places apr-config and apxs in /usr/bin and /usr/sbin, respectively. Turn on the mySQL and httpd servers. Ensure that they are started at boot time: o $ chkconfig httpd on $ chkconfig mysqld on $ service httpd start $ service mysqld start Set the mySQL root password o $ mysqladmin u root password somepassword Set up CPAN o $ perl MCPAN e shell o Follow the on-screen prompts Add an unprivileged user for rt o $ useradd rt Disable SELinux o $ vi /etc/sysconfig/selinux o Change SELINUX=enforcing to SELINUX=permissive or SELINUX=disabled

b. Installing RT Download and unpack the latest version from the Best Practical website o $ wget http://download.bestpractical.com/pub/rt/release/ rt-nnn.nn.n.tar.gz o $ tar xzvf rt-nnn.nn.n.tar.gz o $ cd rt-nnn.nn.n Run the configure script with the correct options o $ ./configure --with-db-rt-pass=<somepass> o <somepass> will be the password for the RT user of the mySQL database. Make sure to make it a good password, as this user will have access to the entire RT database schema. Satisfy some perl module dependencies before running the RT-provided script. On RHEL, these depencies must be satisfied first or your script will error out. o $ perl -MCPAN e install MIME::Base64 o $ perl MCPAN e install MIME::Entity o $ perl MCPAN e install Log::Dispatch Run the RT-provided Perl script to satisfy the remaining Perl dependencies. This will be laborious if you set CPAN to check with you every time another module needs to be added to the queue before adding it. o $ perl sbin/rt-test-dependencies -with-mysql -with-modperl2 install o It may be advantageous to run this script a couple of times to make sure everything was installed correctly o Ensure that you have a sufficiently large CPAN cache set up (100M is a good minimum), since some of the dependency chains are quite lengthy. Once all the dependencies are satisfied, run the installation itself o $ make install You should now have an RT installation in the default location (/opt/rt3/bin/rt3) Initialize the database o $ make initialize-database Edit the RT configuration file in /opt/rt3/etc/. There are two files here that are relevant: RT_Config.pm and RT_SiteConfig.pm. Never edit RT_Config.pm! The SiteConfig file overrides any variables in RT_Config.pm. When you upgrade RT, anything in RT_Config.pm will be overwritten by the upgrade. SiteConfig, however, is preserved. o Make sure these variables are set to the appropriate values for your installation1:

$WebBaseURL $WebPath $rtname

Edit your httpd configuration (On RHEL, its in /etc/httpd/conf/httpd.conf) o Remove the Listen 80 line if you only want this installation responding via SSL (recommended).

These are the barest minimum you need for the web interface to show up and verify your installation was successful. Youll need to change much more than this later on.

In the module load section of the config, make sure mod_perl is being loaded:
LoadModule perl_module module/mod_perl.so

Scroll all the way to the bottom where the VirtualHosts are configured. Turn on vHosts for SSL:
NameVirtualHost *:443

o It is nice to have your vhost config files in a separate directory, so use an include statement to have them slurped into the config:
Include vhosts/*

Create a file in that vhosts directory named something appropriate (like /etc/httpd/vhosts/rt-ssl) and insert the following lines:
<VirtualHost your.host.name:443 > ServerName your.host.name DocumentRoot /opt/rt3/share/html/ AddDefaultCharset UTF-8 SSLEngine on SSLCertificateFile /path/to/ssl/cert SSLCertificateKeyFile /path/to/ssl/key

PerlSetVar MasonArgsMethod CGI PerlModule Bundle::Apache2 Apache2::compat PerlModule Apache::DBI PerlRequire /opt/rt3/bin/webmux.pl <Location /> SetHandler perl-script PerlHandler RT::Mason </Location> </VirtualHost>

This assumes, of course, that you are using the default RT installation path of /opt/rt3/. Substitute in the appropriate path if you are not. Restart Apache o $ service httpd restart

At this point, you should be able to log into the RT web interface at https://your.host.name/. Give it a shot using the default username and password of root

and password. If you get errors, or nothing at all, check the httpd error logs at /var/log/httpd/error_log (on RHEL). You may also find the Known Problems and Fixes section of this reference helpful. Set up sendmail Edit /etc/mail/sendmail.mc o Change the line
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

to read:
dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

Rebuild sendmail.cf: o $ m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf Add rt server alias to /etc/mail/local-host-names o Add Line:
your.host.name.nyu.edu

Restart Sendmail o $ service sendmail restart Configure sendmail to hand messages to RT upon arrival o Put a symlink to /opt/rt3/bin/rt-mailgate in /etc/smrsh/ $ ln s /opt/rt3/bin/rt-mailgate /etc/smrsh/ Add the appropriate aliases to /etc/aliases o Add line (substitute your hostname)
correspond: |/opt/rt3/bin/rt-mailgate --queue general --action correspond --url https://your.host.name/rt/"

Run the newaliases command to update all the new aliases o $ newaliases

Now, messages sent to correspond@your.host.name will be pushed into the queue general. You can change this line to point to different queues, duplicate it to provide different aliases, and so on. Modify the RT Configuration File Open up /opt/rt3/etc/RT_SiteConfig.pm in your favorite text editor. Reprinted here is the RT_SiteConfig file used on someserver.nyu.edu. It contains a reasonable set of configuration variables. You may need to customize for your installation

Set( $rtname, 'NYU ITS SECURITY'); Set( $Organization, "nyu.edu"); Set( $Timezone, 'US/Eastern'); Set( $OwnerEmail , 'gfd212@its.nyu.edu'); Set( $WebBaseURL, 'https://someserver.tss.its.nyu.edu' ); Set( $MailCommand, 'sendmailpipe'); Set( $SendmailPath , "/usr/sbin/sendmail"); Set( $SendmailArguments , "-oi -t"); Set( $CorrespondAddress , 'security@nyu.edu'); Set( $CommentAddress, 'security.comment@nyu.edu'); Set($ParseNewMessageForTicketCcs , 1); Set($RTAddressRegexp , '^security\@nyu.edu$|^copyright\.info\@nyu.edu$|^abuse\ @nyu\.edu$'); Set($UseFriendlyFromLine , 0); Set($MyRequestsLength, 20); 1;

See the RT Wiki and/or RT Essentials for details on the purpose of each configuration variable. Note that this configuration file is actually a Perl module. It must return true at the endhence the 1; at the end of the file. Your version of RT should now be installed at its most basic state. Installation from scratch is complete at this point. Have a look in your httpd error logs to make sure nothing strange is going on, poke around with the web interface to make sure everything is looking the way it should. Send some test emails back and forth. IV. Customization RT lends itself to customization based on an organizations own workflow. This section deals with the customizations that were implemented in TSS installation of RT. Before delving into customizing RT, it is worth pointing out the value of the /local/ directory in the RT folder. The /local/ directory is processed last by the Mason html handler at httpd start time. Essentially, everything placed in there overrides the original RT file. For example, if I want to override the file /opt/rt3/share/html/index.html, I would name the file I want to override it with /opt/rt3/local/html/index.html. This allows RT to be cleanly customized in a single location while maintaining the integrity of the original installation in case you need to roll back something quickly. Additionally, in the event that you upgrade RT, your customized files will be preserved.

a. Queues 1. Create different queues for different task groups In the initial design phase, the need became evident for several different queues to keep tasks with different work processes completely separate. To that end, TSS created 8 discrete queues: Incoming o This is the default queue for most incoming correspondence. The on-call staff person sorts out tickets into their respective queues from this one. Abuse o Tickets dealing with abuse of network resources by humans. Harassment falls into this category, for example. Consult o Longer term inquiries and projects asking for the technical assistance of TSS. Copyright o Tickets dealing with users copyright infringements. These tickets are usually started by an external complainant, generally the RIAA. Incident o This is the most heavily used queue. A security incident could be an infected computer, an account compromise, a DoS attack, and so on. This category is intentionally vaguewed rather spend our time dealing with incidents than subcategorizing them. Query o Simple questions with (hopefully!) simple answers. ResNet o Tickets in this queue are generally virus-related and are eventually bound for the established ResNet Quarantine process which is dealt with though the existing ticket process at the helpdesk. 2. Push copyright complaints directly into the Copyright queue. Add a new alias in /etc/aliases: o Copyright.correspond: |/opt/rt3/bin/rt-mailgate --queue
Copyright --action correspond --url https://someserver.nyu.edu

Run newaliases o $ newaliases Forward messages sent to copyright.info@nyu.edu to copyright.correspond@someserver.nyu.edu

b. Groups and Permissions 1. Create logins for each individual staff member and assign them to a group with unified permissions across all queues for which they need access.

Use the web interface to create the appropriate accounts. o Use Configuration->Users->New User o Fill in the form with as much detail as you like o Check the boxes marked Let this user access RT and Let this user be granted rights o Set a password Create a group for the security staff o Use Configuration->Groups->New Group o Add the appropriate members to the group

2. Assign Group and Role Permissions to your queues Use Configuration->Queues->Group Rights and Configuration->Global->Group Rights o Assign the following permissions Global Everyone: o CreateTicket o ReplyToTicket Requestor o ReplyToTicket Security Group o ShowOutgoingEmail Every Queue Everyone o CreateTicket Requestor o ReplyToTicket Security Group o CommentOnTicket o CreateTicket o ModifyTicket o OwnTicket o ReplyToTicket o SeeQueue o ShowOutgoingEmail o ShowTicket o ShowTicketComments o StealTicket o TakeTicket o Test that each member of the group can deal with the queue and the permissions are not too lax or restrictive.

c. AdminCCs In order to mimic the original behavior of security@nyu.edu, where every member of the list was copied on all correspondence, AdminCCs were set up. Simply put, AdminCCs get a copy of all correspondence on a ticket. RT was set to transparently add an organizational alias, security.correspond@nyu.edu as an adminCC on all tickets. 1. Add an adminCC on all queues. If your adminCC does not already have an account with RT, create one using the process above, but do not allow the user to access RT, and do not grant the user rights. Be sure the email address is correctly set. This must be done via the web interface. For every queue in Configuration->Queues->Watchers, add your adminCC as a watcher. d. Templates Some of the email templates that come with RT by default lack sufficient information, have too much information, and so on. As such, the TSS templates have been tweaked to provide the appropriate level of detail, especially in the Transaction template. Addtionally, the AdminCC messages have had the To: lines modified so they appear to come from the original sender, rather than from security@nyu.edu. This helps with browsing email correspondence in an email client rather than with the web interface. Change the Transaction template o In Configuration->Global->Templates->Transaction, replace the default value with:
From: "{$Transaction->CreatorObj->RealName}" <{$Transaction->CreatorObj->EmailAddress}> RT-Attach-Message: yes

{ if( my $tra = $Ticket->RequestorAddresses ) { "Ticket To: ". $tra } } { if( my $tcc = $Ticket>CcAddresses ) { "\Ticket Cc's: ". $tcc } } <URL: {$RT::WebURL}Ticket/Display.html?id={$Ticket>id} > {$Transaction->CreatedAsString}: Request {$Ticket->id} was acted upon. Transaction: {$Transaction->Description} Queue: {$Ticket->QueueObj->Name} Requestors: {$Ticket->RequestorAddresses} Ticket <URL: {$RT::WebURL}Ticket/Display.html?id={$Ticket->id} > {$Transaction->Content()}

Change the Admin Correspondence Template o Replace the default value of the template with
From: "{$Transaction->CreatorObj->RealName}" <{$Transaction->CreatorObj->EmailAddress}> RT-Attach-Message: yes

{ if( my $tra = $Ticket->RequestorAddresses ) { "Ticket To: ". $tra } } { if( my $tcc = $Ticket>CcAddresses ) { "\Ticket Cc's: ". $tcc } } <URL: {$RT::WebURL}Ticket/Display.html?id={$Ticket>id} > <Requestor: {$Ticket->RequestorAddresses}> {$Transaction->Content()}

Change the Admin Comment Template o Replace the default value of the template with
From: "{$Transaction->CreatorObj->RealName}" <{$Transaction->CreatorObj->EmailAddress}> Subject: [Comment] {my $s=($Transaction>Subject||$Ticket->Subject); $s =~ s/\[Comment\]//g; $comment =~ s/^Re//i; $s;}

{$RT::WebURL}Ticket/Display.html?id={$Ticket->id} This is a comment. It was not sent to the Requestor(s): {$Transaction->Content()}

e. Scrips Scrips are custom bits of Perl code that fire at the time a transaction takes place. Usually, they send email using the templates we just customized, but they can do pretty much anything that Perl can. The RT default Scrips have a few idiosyncrasies that can be ironed out with minor code changes. All the scrips were going to deal with are global scrips, so they apply to all the queues. Scrips can be assigned to individual queues, and so on. The global scrips are all in the same place: Configuration->Global->Scrips

Disable On Resolve Notify Requestors with template Resolved o Open the scrip o Under stage choose Disabled o Click Submit Change the AutoRespond scrip to notify requestors only if the creator of the ticket was privileged, with a blank template instead of the default template, which seems robotic at best. o Open the scrip o The Scrip Fields should be as follows: Condition: On Create Action: Notify Requestors Template: Correspondence Stage: TransactionCreate o Add this custom condition:
package RT::Condition::OnPrivCreate; use strict; use base 'RT::Condition::Generic'; sub IsApplicable { my $self = shift; return 0 unless ($Transaction->CreatorObj->Privileged); return 1; } 1;

f. Web Interface RTs web interface is quite robust, and the Mason-based code is modular enough to be customized. TSS required a few distinct modifications to the code to make their work easier. All backend code modifications were placed in the /local/ directory to override existing programming, rather than modifying code in-place. Code changes here are shown as diff-style details between the old and the new code. The diff line is shown to illustrate which file is which. Add Reject link on index page o Override /share/html/Elements/MyRequests o Diff output

# diff /opt/rt3/local/html/Elements/MyRequests /opt/rt3/share/html/Elements/MyRequests 50c50 < Format => "'<a href=\"$RT::WebPath/Ticket/Display.html?id=__id__\">__id__</a>/TIT LE:#', '<a href=\"$RT::WebPath/Ticket/Display.html?id=__id__\">__Subject__</a >/TITLE:Subject', QueueName, ExtendedStatus, CreatedRelative, '<A HREF=\"$RT::WebPath/Ticket/Display.html?Action=Take&id=__id__\">". loc('Take')."</a>/TITLE:&nbsp;', '<A HREF=\"$RT::WebPath/Ticket/Display.html?Status=rejected&id=__id__\ ">".loc('Reject')."</a>/TITLE:&nbsp;' ", --> Format => "'<a href=\"$RT::WebPath/Ticket/Display.html?id=__id__\">__id__</a>/TIT LE:#', '<a href=\"$RT::WebPath/Ticket/Display.html?id=__id__\">__Subject__</a >/TITLE:Subject', QueueName, ExtendedStatus, CreatedRelative, '<A HREF=\"$RT::WebPath/Ticket/Display.html?Action=Take&id=__id__\">". loc('Take')."</a>/TITLE:&nbsp;' ",

Change default values on Ticket Create Page to Owner: Currently logged in user Requestor: null o Modify /share/html/Ticket/Create.html o Diff output:
$ diff /opt/rt3/local/html/Ticket/Create.html /opt/rt3/share/html/Ticket/Create.html 72c72 < <& /Elements/SelectOwner, Name => "Owner", QueueObj => $QueueObj, Default => $ARGS{Owner}||$session{'CurrentUser'}->Id, DefaultValue => 0 &> --> <& /Elements/SelectOwner, Name => "Owner", QueueObj => $QueueObj, Default => $ARGS{Owner}||$RT::Nobody->Id, DefaultValue => 0 &> 80c80 < <INPUT Name="Requestors" Value="<% ($ARGS{Requestors}) %>" SIZE=40> --> <INPUT Name="Requestors" Value="<% ($ARGS{Requestors}) || $session{CurrentUser}->EmailAddress %>" SIZE=40>

Change Tabs on ticket display page to show Quick Reject and Quick Resolve as well as modify other actions to be more descriptive Override /share/html/Ticket/Elements/Tabs:
# diff /opt/rt3/local/html/Ticket/Elements/Tabs /opt/rt3/share/html/Ticket/Elements/Tabs 155,161c155 < title => loc('Resolve With Comment') }; < < $actions->{'Ba'} = { < < path => "Ticket/Display.html?Status=resolved&id=" . $id, < title => loc('Quick Resolve') }; < --> title => loc('Resolve') }; 167,178d160 < if ( $Ticket->Status ne 'rejected' and $Ticket->Status ne 'resolved' ) { < $actions->{'Ca'} = { path => "Ticket/Display.html?Status=rejected&id=" . $id, < title => loc('Quick Reject') }; < < $actions->{'Cb'} = { < < path => < "Ticket/Update.html?Action=Comment&DefaultStatus=rejected&id=" . $id, < title => loc('Reject With Comment') }; < < < }

Add Change Assigned Queue menu to the ticket display page Override /share/html/Ticket/Elements/ShowSummary and create a new Mason element: /share/html/Ticket/Elements/ChangeQueue
# diff /opt/rt3/local/html/Ticket/Elements/ShowSummary /opt/rt3/share/html/Ticket/Elements/ShowSummary 73,84d72 < <FORM METHOD=POST ACTION="Display.html" ENCTYPE="multipart/form-data"> < <INPUT TYPE=HIDDEN NAME=id VALUE="<%$Ticket->Id%>"> < <& /Elements/TitleBoxStart, title => loc('Change Assigned Queue'), < title_class=> 'inverse', < color => "#003333" &> < <& /Ticket/Elements/ChangeQueue, Ticket => $Ticket &> < <& /Elements/TitleBoxEnd &> < <& /Elements/Submit, Label => loc('Change'), Caption => loc("If you've changed the queue, save your changes:"), color => "#003333" &> < </form> < <BR> < <

# cat /opt/rt3/local/html/Ticket/Elements/ChangeQueue <TABLE> <TR> <td class="label"><&|/l&>Queue</&>:</td> <td class="value"><%$SelectQueue|n%></td> </TR> <& /Elements/Callback, _CallbackName => 'EndOfList', TicketObj => $TicketObj, %ARGS &> </TABLE> <%INIT> $m->comp('/Elements/Callback', TicketObj => $TicketObj, %ARGS); my $SelectQueue = $m->scomp("/Elements/SelectQueue", Name => 'Queue' ); </%INIT> <%ARGS> $TicketObj => undef </%ARGS>

V. Known Problems and Solutions Perl modules Mime::Entity and Log::Dispatch fail to install o Install MIME::Base64 first. Try again. If it still fails, force the installation. Fairly exhaustive testing has demonstrated no noticeable failures in RT due to the force-install of this module Graphics do not show in the RT web interface o Make sure $WebBaseURL and $WebPath are set correctly in your RT_SiteConfig.pm o Make sure you do not have any URL rewriting turned on in Apache. Some RT documentation suggests using it, however it seems to break more than it fixes. The web interface doesnt display, and an error message like this occurs in the httpd_error log
[Mon Oct 10 14:35:14 2005] [crit]: The 'comp' parameter (undef) to HTML::Mason::Request::CGI->new() was an 'undef', which is not one of the allowed types: scalar object Stack: [/usr/lib/perl5/site_perl/5.8.5/HTML/Mason/CGIHandler.pm:127] [/usr/lib/perl5/site_perl/5.8.5/HTML/Mason/CGIHandler.pm:63] [/opt/rt3/bin/webmux.pl:123] [-e:0] (/opt/rt3/bin/webmux.pl:125)

o Upgrade your CGI.pm module from CPAN o Use $ perl -MCPAN eshell install CGI The httpd error log complains about not being able to find Apache2.pm o Check that apache2.pm is actually installed via CPAN o Sometimes CPAN puts the module in a Bundle/ directory. Youll need to call the module as Bundle::Apache2 Other strange mod_perl errors o Make sure that Apache2::compat is installed for backwards-compatibility with older mod_perl code. o Mod_perl can be tricky. Consult the mod_perl documentation and associated mailing lists.

VI. Acknowledgemens and Further Reading RT and the >>|<< logo are trademarks of Best Practical Solutions, LLC. 1996-2005. RedHat is a trademark of Red Hat, Inc. Parts of this text were adapted from Wiki posts by Jesse Vincent made at http://wiki.bestpractical.com, and RT Essentials by Jesse Vincent, Robert Spier, Dave Rolsky, Darren Chamberlain, and Richard Foley (OReilly 2005).