RT

The Wikimedia Operations team is experimenting with Request Tracker for managing day to day tasks. RT lives at http://rt.wikimedia.org. The process definition and documentation is at RT Flow.

Wishlist & annoyances

• If you (accidently) click on any link while updating a ticket, and hit the browser Back button, your entered text is gone. Very annoying.
• Set($NotifyActor, 1) should be a personal user preference.

Installation

RT is installed on streber, and is mostly setup using Puppet class misc::rt::server. It uses the standard Ubuntu packages request-tracker3.8 and rt3.8-db-mysql. The database lives on the misc DBs cluster, db9 and db10.

Configuration

Site specific configuration is done in /etc/request-tracker3.8/RT_SiteConfig.pm, which again is generated by the command update-rt-siteconfig from the files in /etc/request-tracker3.8/RT_SiteConfig.d/ - a directory which is populated by Puppet.

Web server setup

The web server used is lighttpd, serving RT using the FastCGI protocol. The configuration lives in /etc/lighttpd/conf-available/10-rt.conf. Almost all URIs are served directly by Mason over FastCGI, except for the prefix ^/NoAuth/images/, which is served directly from lighttpd.

Mail server setup

To perform its duty of e-mail ticket tracking, RT of course needs to receive mails from the mail servers. The RT server is running a specially configured Exim MTA. Most of the Exim configuration follows the configuration of the other Mail servers, and only the RT specifics will be described here. The MTA is configured by Puppet, using the exim::rt class.

Exim is configured by Puppet to listen on the SMTP port using:

$exim_queuerunner = 'combined'

In /etc/exim4/exim4.conf, the following nonstandard configuration is used for RT:

Mail for the RT domain @rt.wikimedia.org is delivered by the mail relay to the RT server. This configuration is decribed in Mail.

RT mail is only received on the domain @rt.wikimedia.org:

domainlist rt_domains = rt.wikimedia.org
hostlist rt_mail_from_hosts = mchenry.wikimedia.org

RT mails on this domain are then picked up by a pair of routers:

# Mail destined for RT

# This router checks whether the local part consists of solely digits,
# and assumes this is the ticket number of an existing ticket if this is
# the case. It rewrites the address to the general queue, and puts the
# ticket nr in $address_data, where the rt_pipe transport can access it.

rt_ticket:
        driver = redirect
        domains = +rt_domains
        local_part_suffix = -comment
        local_part_suffix_optional
        condition = ${if match{$local_part}{\N^\d+$\N}{yes}{no}}
        address_data = EXTENSION=$local_part
        data = general$local_part_suffix@$domain
        redirect_router = rt
        no_verify

rt:
        driver = accept
        domains = +rt_domains
        local_part_suffix = -comment
        local_part_suffix_optional
        transport = rt_pipe

The first router accepts mail for ticketnr@rt.wikimedia.org, and hands the appropriate information to the RT transport. Other mails that do not follow this format are sent on to the next router, which simply delivers the full message to the RT transport.

# RT transport
rt_pipe:
        driver = pipe
        command = /usr/bin/rt-mailgate --queue $local_part \
                --action "${if eq{$local_part_suffix}{-comment}{comment}{correspond}}" \
                --extension ticket --url http://rt.wikimedia.org
        environment = $address_data
        user = mail
        group = mail
        return_fail_output

The RT transport delivers a message to the /usr/bin/rt-mailgate program, using the e-mail address local part as the queue name. If the local part consists of a ticketnr, this is handled properly as well, because of the --extension ticket<tt> parameter, which uses the <tt>EXTENSION environment variable which was previously set by the rt_ticket router.

If the RT transport pipe returns an error code, the message is bounced with an error message.

Usage

Merging

Duplicate tickets should not be deleted but merged instead.

How to Merge Request Tracker (RT) Tickets

Priorities

Example priority scale

• Priorities 11-20 : A minor inconvenience. There is a good workaround
• Priorities 21-30 : An inconvenience. There is a workaround
• Priorities 31-40 : A major inconvenience. There is a troubling workaround
• Priorities 41-50 : A real problem. Someone can not do part of his work until this is resolved.
• Priorities 51-60 : A disaster. Someone can not work at all until this is resolved.

from [1]