Sun and Oracle Channel Sun How to Buy Log In United States [Change] English

BigAdmin System Administration Portal
Feature Article
Print-friendly VersionPrint-friendly Version

RT: Request Tracker, Part 2

By Amy Rich, July 2003

Part I: RT Overview

In the previous article, I gave an overview of RT, and I installed all of the dependencies and RT itself from a bare Solaris 9 OS install. At that point, I still didn't have a functioning RT installation since I hadn't done any configuration. In this article, I'll cover RT concepts and configuration options, and walk through a simple setup.


Initial RT Configuration

I used the RT layout and installed RT into /usr/local/rt3, so my configuration files were located in the directory /usr/local/rt3/etc/. The default configuration, /usr/local/rt3/etc/RT_Config.pm, contained a number of variables that had to be set before I could even bring up the web interface. Instead of making changes to the default config file that might get overwritten by an upgrade, I copied this to the site config file and made my changes there: 
cp /usr/local/rt3/etc/RT_Config.pm /usr/local/rt3/etc/RT_SiteConfig.pm
vi /usr/local/rt3/etc/RT_SiteConfig.pm
I left only those lines I changed, and the last line, ";1". When I was done, my /usr/local/rt3/etc/RT_SiteConfig.pm contained the following: 
Set($rtname , "your.domain");
Set($Organization , "your.domain");
Set($OwnerEmail , 'rt-sysadmin');
Set($RTAddressRegexp , '^rt\@your.domain$'); 
Set($CorrespondAddress , 'rt@your.domain'); 
Set($CommentAddress , 'rt@your.domain');
Set($CanonicalizeEmailAddressMatch   , 'subdomain.your.domain$');
Set($CanonicalizeEmailAddressReplace , 'your.domain'); 
Set($SendmailPath , "/usr/lib/sendmail"); 
Set($WebBaseURL , "https://rt.your.domain"); 1;
I then initialized the RT database from inside the RT source tree: 
 make initialize-database
In the previous article, I mentioned that I didn't want to set an administrative password for MySQL when I did the MySQL install, because RT would try to connect to the database without a password. Now that RT has done that and created its databases, I'm free to change the MySQL password: 
/usr/local/mysql/bin/mysqladmin -u root password 'YourPasswd'

Configuring Apache

Now that I had finished the initial config file setup for RT, I needed to modify /usr/local/apache/conf/httpd.conf. Because I didn't want any unencrypted connections, I only wanted to run a server on port 443 of this machine. To do this, I removed the line "Listen: 80" from the SSL definition in httpd.conf: 

Listen 443
I also wanted Apache to run as the user www and the group www, since that is what the default RT installation expects. I also set the ServerAdmin to webmaster@your.domain: 
User www
Group www
ServerAdmin  webmaster@your.domain
The only service I wanted running under Apache was RT, so I modified the virtual host _default_:443 and made the RT html directory my docroot. In addition, I needed to add a handler for fastcgi, specify the fastcgi server, and add a script alias so that everything went through the mason fastcgi: 
 
 DocumentRoot "/usr/local/rt3/share/html"
 ServerName rt.your.domain
 ServerAdmin webmaster@your.domain
 FastCgiServer /usr/local/rt3/bin/mason_handler.fcgi
 AddHandler fastcgi-script fcgi
 ScriptAlias / /usr/local/rt3/bin/mason_handler.fcgi/
After saving these changes, I ran a configuration test to verify that the config file contained no errors: 
/usr/local/apache/bin/apachectl configtest
The test passed, so I started the web server: 
/usr/local/apache/bin/apachectl startssl
As a side note, with no startup/shutdown script in place, Apache won't exit cleanly on shutdown or start on reboot. I generally remove the <IfDefine SSL> blocks from httpd.conf, copy the apachectl script from /usr/local/apache/bin into /etc/init.d, and link to it from the appropriately named files in the rc directories.

RT Concepts

Before I walk through a setup of RT via the web interface, let me detail the basic RT entities. The internals of RT are a number of perl scripts designed around the following concepts:
  • User - A person who has an RT account and password. Rights can be granted to users on a global or per-queue basis.
  • Groups - A collection of Users. Rights can be granted to groups on a global or per-queue basis.
  • Rights - The abilities granted to users and/or groups on a global or queue basis. RT supports the following rights:
    • AdminAllPersonalGroups - Change name, description, and members of any personal group.
    • AdminCustomFields - Add, delete, and modify custom fields.
    • AdminGroup - Create groups; change group names, descriptions, and rights.
    • AdminGroupMembership - Add and remove members from a group.
    • AdminOwnPersonalGroups - Change name, description, and members of personal groups.
    • AdminQueue - Create, enable, and disable queues; change queue names, descriptions, reply and comment addresses, priority, and due dates.
    • AdminUsers - Create users; change anything on a user's Basics screen (username, email, name, nickname, Unix login, address, phone numbers, comments about the user, signature, password, and rights).
    • CommentOnTicket - Add comments to tickets.
    • CreateTicket - Create tickets.
    • DelegateRights - Assign one's own rights to other users.
    • DeleteTicket - Delete tickets.
    • ModifyACL - Change users' and groups' rights. (Users with this right should also have the right Show ACL.)
    • ModifyOwnMembership - Add or remove oneself from a group.
    • ModifyQueueWatchers - Add and remove Ccs and AdminCcs.
    • ModifyScrips - Add, delete, and change the content of scrips.
    • ModifySelf - Modify one's own email address, real name, nickname, extra contact information, password, organization, address, phone numbers, and signature.
    • ModifyTemplate - Create, modify, and delete scrip templates.
    • ModifyTicket - Change a ticket's subject, status, time worked, time left, priorities, queue, dates, watchers, owner, and relationships to other tickets; add comments and replies to tickets.
    • OwnTicket - Own (be responsible for) a ticket.
    • ReplyToTicket - Add replies to a ticket.
    • SeeQueue - Know that a queue exists; queues will appear in visible listings for this user.
    • ShowACL - See the rights granted to users and groups.
    • ShowScrips - See scrips.
    • ShowTemplate - See a scrip's email template.
    • ShowTicket - See tickets.
    • ShowTicketComments - See comments attached to tickets.
    • SuperUser - Everything; this user has all possible rights within RT.
    • Watch - Sign up as a requestor or Cc.
    • WatchAsAdminCc - Sign up as an AdminCc.
  • Queue - The central administrative domain of RT. The queue is the organizational container of a collection of tickets waiting to be worked on. Queues often correspond to groups of services, groups of machines, or organizational units. The creation and naming of queues will depend on how the organization splits its work flow.
  • Ticket - The central object in RT. Each ticket defines a task to do or a problem to solve. One ticket is opened for each issue, regardless of how many notes or interactions happen with users about said issue. A ticket includes associated metadata such as an owner, watchers, status, and queue.
    • Ticket Requestor - The person or people who opened the ticket.
    • Ticket Owner - The person responsible for working on the ticket.
    • Watcher - Someone interested in keeping track of the ticket. The owner and requestor(s) of the ticket automatically become watchers, and the following additional watcher categories are also available:
      • Cc: The person or people who receive copies of any replies that go to the requestor. Someone on the Cc list sees email but may not have permission to modify the ticket.
      • AdminCc: a Cc or Ccs that also gets copies of comments and are usually permitted to modify the ticket.
    • Ticket status - The status of a ticket, identified by one of the following drop-down menu choices:
      • new: The ticket has been created but not acted on.
      • open: The ticket is being worked on.
      • stalled: The ticket isn't getting worked on right now. It will open again when someone adds a comment or reply.
      • resolved: Work on the ticket has been completed.
      • rejected: The ticket is not going to be resolved, but is, for some reason, worth recording in the system. This can be useful for tracking users that make unreasonable requests.
      • deleted: The ticket should never have entered the system (spam, sensitive information, etc), and has been removed.
    • Time worked - The amount of time spent on the ticket.
    • Time left - The amount of time left to work on the ticket.
    • Ticket priority - The importance of a ticket, represented as a numerical scale from 0-99, with 99 being the highest priority. The initial and final ticket priorities should follow a predetermined company-wide standard. By setting a final priority, RT makes a ticket's priority increase or decrease as its due date draws closer.
    • Ticket comments - A note about the ticket that will not be sent to the requestor.
    • Ticket correspondence - An email to the requestor and possibly some or all of the ticket watchers.
    • Ticket relationships - Links to other tickets or external items such as URLs, shipping tracking numbers, and so on. RT allows the following relationship types:
      • merge into: The current ticket becomes part of the ticket listed here.
      • depends on: The current ticket can't be resolved unless the ticket listed here is also resolved. (The converse is "depended on by".)
      • depended on by: The current ticket is a requirement for the completion of the ticket listed here.
      • refers to: The listed ticket contains information pertinent to the current ticket. (The converse is "referred to by.")
      • referred to by: The current ticket contains information pertinent to the listed ticket.
      • parents: The listed ticket is a large general ticket that contains a number of sub-tickets, including the current ticket. This is useful for a breaking down a large project into component tasks.
      • children: The listed tickets are sub-tickets of the current ticket.
    • Ticket history - Everything that's happened to a ticket since creation. Facets of ticket history include creation time and date, status changes, ownership changes, comments, correspondence, priority changes, and so on. The ticket history can not be modified after the fact.
  • Templates - Generalized action notifications, created and applied on a global or queue basis. Custom templates can be created after installation, but the default templates provided with RT are:
    • Blank - A blank template.
    • Autoreply - Default Autoresponse template.
    • Transaction - Default transaction template.
    • Admin Correspondence - Default admin correspondence template.
    • Correspondence - Default correspondence template.
    • Admin Comment - Default admin comment template.
    • Status Change - Ticket status changed template.
    • Resolved - Ticket Resolved template.
  • Scrips - Triggers that will automatically take a specified action in response to a given condition. As with templates, scrips can be created and applied on a global or queue basis. Also like templates, custom scripts can be created after installation. The default scrips that ship with RT are:
    • On Correspond Open Tickets with template Blank
    • On Create Autoreply To Requestors with template Autoreply
    • On Create Notify AdminCcs with template Transaction
    • On Correspond Notify AdminCcs with template Admin Correspondence
    • On Correspond Notify Requestors and Ccs with template Correspondence
    • On Correspond Notify Other Recipients with template Correspondence
    • On Comment Notify AdminCcs as Comment with template Admin Comment
    • On Comment Notify Other Recipients as Comment with template Correspondence
    • On Resolve Notify Requestors with template Resolved
  • Custom fields - Database fields that an organization can populate according to its needs.

RT Setup Via the Web

Now that I've discussed the basic building blocks of the RT configuration, here's the simple set up I went through. The first step was to point my web browser at https://rt.your.domain/. This presented me with a login screen asking for a username and a password. I logged in with the username root and the password specified at configuration time.

login

Now I got my first view of the RT GUI. Since RT hadn't received any tickets yet, most of the columns to the right were empty. There were no tickets that root owned or requested, and no tickets populated the default "General" queue. At this point, what was of interest to me was the configuration option on the left menu bar.

main

Setting up RT generally involves creating, at minimum, some users, some groups, and some queues. More advanced usage might go beyond that and involve making some custom templates and/or scrips. Create Users
I started by making a user, so I wouldn't have to log in with the root account anymore. Here are the steps I took:
  1. On the left hand menu bar, I clicked Configure.
  2. Then I clicked Users.
  3. Then I clicked New user.
  4. I filled in user information and made sure the checkboxes next to Let this user access RT and Let this user be granted rights were checked off.
  5. I clicked Submit at the bottom of the main frame.

Create Users

Create Groups
Next, I created a custom group so that I can later assign permissions to a number of users at once on a per-group basis.
  1. In the left hand menu bar, I clicked Groups.
  2. Then I clicked on New group in the left hand menu bar.
  3. I filled in the new group information and clicked Submit at the bottom of the main frame.

Create Groups

Next I populated the new group with my new user.

  1. Under the group name in the left hand menu bar, I clicked Members.
  2. I then clicked on and highlighted the new user, testuser, under the Add Members selection box in the main frame.
  3. At the bottom of the main frame, I clicked Submit.
Assign Rights
Now that I had populated my "RT Administrators" group, I wanted to globally assign every possible right to users in that group.
  1. I clicked on Global in the left hand menu bar.
  2. I selected Group Rights in the main frame.
  3. I highlighted SuperUser Rights for group "RT Administrators."
  4. I clicked on Submit at the bottom of the main frame.

Assigning rights.

Depending on how I was setting up RT, I might also want to assign various rights to the predefined system groups on this screen. For example, if I was setting up a ticketing system where people without RT accounts could also submit tickets, which is a fairly common scenario, I'd want to give the group "Everyone" the ability to create tickets.

Create Queues
I wanted to create a custom queue just for handling the administration of RT.
  1. I selected Queues from left hand menu bar.
  2. I clicked New queue.
  3. Then I filled in the new queue information.
  4. I clicked on Submit at the bottom of the main frame.

Creating the queue

I wanted the rt admin queue to be monitored for new tickets by all the users in my "RT Administrators" group, so I added that group as AdminCc watchers. I chose AdminCc because one of the default scrips that ships with RT sends an email to the AdminCc users upon creation of a new ticket.

  1. I clicked on Watchers in the left hand menu bar.
  2. Under Find group whose, I chose Name and contains.
  3. I filled in the last field with RT Administrators.
  4. I clicked Go!, which brought up the group I wanted, under the Groups section in the main frame.
  5. I selected AdminCc from the drop down menu under Groups.
  6. I clicked Submit at the bottom of the main frame.

Creating watchers.


Mail Gateway Setup

Finishing my very basic RT web setup meant that I was ready to add in the mail gateway portion. This required that mail be deliverable to the machine. Since sendmail is already installed by default on the Solaris 9 Operating System, I went with that as my MTA. I started up the daemon so that it accepted local and remote connections, and I added two aliases to the /etc/mail/aliases file and ran newaliases: 
rt-admin: "|/usr/local/rt3/bin/rt-mailgate  \
          --queue 'rt admin' --action correspond \
          --url https://rt.your.domain/"
rt-admin-comment: "/usr/local/rt3/bin/rt-mailgate \
                  --queue 'rt admin' \
                  --action comment \
                  --url https://rt.your.domain/"
Both of these aliases pipe the mail to the perl script rt-mailgate. Extra documentation on this program is available by reading the source or via perldoc: 
perldoc /usr/local/rt3/bin/rt-mailgate
The first alias tells RT that the mail applies to the queue rt admin and that the action is correspond. This means that the scrips that apply to correspond for the queue rt admin will be triggered by an incoming message. By default, these scrips are:
  • On Correspond Open Tickets with template Blank/li>
  • On Correspond Notify AdminCcs with template Admin Correspondence
  • On Correspond Notify Requestors and Ccs with template Correspondence
  • On Correspond Notify Other Recipients with template Correspondence
The second alias applies to the same queue, but sets the action to comment. The set of default scrips that applies to an incoming message would instead be:
  • On Comment Notify AdminCcs as Comment with template Admin Comment
  • On Comment Notify Other Recipients as Comment with template Correspondence

Since I used a space in my queue name when I created it, I need to put single quotes around it in the aliases file. If I had named the queue rt-admin instead, I wouldn't need the quotes.


Ticket Creation

At this point, RT was installed, configured, and set up with a new user, group, and queue. I was ready to create a few test tickets just to make sure everything was working ok. First, I made a new ticket via the web interface.
  1. In the left hand menu bar I selected Home.
  2. From the drop down menu next to the New ticket in button, I chose rt admin.
  3. Next, I clicked the New ticket in button.
  4. Then I filled out the ticket information.
  5. Finally, I clicked Submit at the bottom of the main frame.

Creating a ticket.

This created the ticket in the rt admin queue and brought up the ticket display page. On the left hand menu bar, there were a number of other choices under the ticket number. When I clicked Home again, it showed a ticket listed under 10 highest priority tickets I own... and 10 highest priority tickets I requested.... It also showed a ticket under the New column of the rt admin queue off to the right.

With the web interface working fine, I tested the email interface by sending an email to rt-admin@rt.your.domain. When I refreshed the Home view, I saw another ticket waiting in the rt admin queue, just as expected. My install was completely functional.


Pre-Installation Planning

Now that I've covered installing and configuring RT, I'll offer a few words about pre-configuration preparation. Before configuring RT, invest some care and forethought in planning the layout and deciding how RT will work for a site. The organization of groups, queues, and permissions often determines the effectiveness of a ticketing system. A haphazard installation that operates against the work flow of the organization ends up causing problems. When creating queues and groups, consider how people and systems work together.

If one queue exists for mail systems and one exists for backups, where does a ticket about backups causing load and failure on the mail systems belong? Who should be dealing with the problem? Is the site small enough that these two queues should actually be one, or do two different teams of people handle backups and general system health? If two different teams exist, were they granted permission to view each other's queues? If the teams don't communicate well, sometimes two tickets about the same issue are opened in different queues.

Also carefully consider which users should have rights on which queues. While sysadmins might need full rights on various queues, helpdesk staff or frontline support people might only need minimal access, i.e., to see but not modify tickets. When creating groups and watchers, determine whether it makes sense to copy the entire staff on each ticket update, or to copy only the owner and requestor. Custom scrips and templates can help streamline the automation such that the necessary people see all or only selected ticket actions.


Having Trouble?

Be sure to read through the README, HOWTO, and doc files that come with the RT tar ball. Some documentation and the current list of known bugs is available on the RT web site. There's also a hacker's guide that deals primarily with RT 2 that may be of some use.

Additionally, there are four mailing lists about RT and their archives. Direct questions about installing or configuring RT belong to the rt-users mailing list, while any RT development questions and discussions belong on the rt-devel mailing list.

For those sites that need or prefer to pay for a support contract, Best Practical Solutions, LLC offers four levels of service. In addition, the company also offers installation support and custom development services.


Resources

 

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.


BigAdmin
  
»  Search the HCL
 
BigAdmin Subscriptions
BigAdmin Areas
BigAdmin Sun Center
BigAdmin Topics