5.5. Day-to-Day Management

Most days, you won't need to think about RT management. Sometimes, you'll need to reset a user's password, add a queue, or update someone's permissions, but RT generally takes care of itself. In this section, we'll show you how to take care of a few of the most common day-to-day tasks you'll encounter.

5.5.1. Setup External Authentication

Some organizations invest a fair amount of time to set up a single sign-on system of one sort or another. While there are many different ways to get RT to support single sign-on, the easiest is to configure RT to let your webserver deal with authentication; most single sign-on frameworks already have a good solution for Apache authentication. If you set $WebExternalAuth to 1 in RT's configuration file, RT will trust whatever your webserver says about who is currently logged in. If the webserver tells RT that a user RT's never heard of has logged in, it's possible to have RT automatically create the user. To do this, just set $WebExternalAuto to 1.

5.5.2. Remove a Transaction

Sometimes, someone puts something into RT that really should never have been there in the first place, like the entire company's salary list or the CEO's baby pictures. When you absolutely need to make sure that content is purged from RT, it's possible, though not encouraged. First, find the transaction's ID. You can do this by looking at the URL for the # anchor next to the transaction. Let's say that it reads http://rt.example.com/Ticket/Display.html?id=3700#txn-33070. That means you want to get rid of transaction 33070.

The following code will take care of it for you:

     perl -I/opt/rt3/lib -MRT -e '         RT::LoadConfig(  ); RT::Init(  );         my $t = RT::Transaction->new($RT::SystemUser);         $t->Load(33070);         print $t->Delete;         ' 

5.5.3. Track Email Sent

RT logs information about each message it sends out, as well as each message it considers sending out. All outgoing mail about a given ticket update is sent by a scrip. Each scrip evaluates some sort of condition, such as Is this a new ticket being created? or Is this a private comment? If the answer to the question is Yes, then RT moves on to whichever action you've associated with that scrip. It might be an action such as notify the requestor or notify the owner. RT then sets up an email message using the template you've defined for the scrip and checks to make sure that it's actually being sent to someone. RT logs this process using its standard logging framework. Log messages about scrip-generated email are keyed by the outgoing message's Message-Id header. You can use that identifier to trace a message RT sends as it makes its way across the Internet from your RT server to the recipient's local email server. The example below shows an autoreply being sent out to [e-mail].

  Jul 4 22:15:53 pallas RT: <[e-mail]> #5813/28448 - Scrip 22  Jul 4 22:15:53 pallas RT: <[e-mail]> sent To: [e-mail] Cc: Bcc: 

Let's take a look at these log messages in a bit more detail. The first message gives us a heads-up that RT is considering sending some sort of email. In this case, scrip 22 sends an autoreply to the ticket's creator when a ticket is created. This scrip is acting on transaction 28448 on ticket 5813. The second message tells us that RT has sent out this email to just one person, [e-mail]. If RT had decided to scrap the email, we'd see a different second message:

  Jul 4 22:15:53 pallas RT: <[e-mail]> No recipients found. Not sending 

This usually means that you have a scrip set up to notify a ticket's Owner or AdminCc or manually entered Cc or Bcc recipients, but there weren't any.

5.5.4. Report Failed Logins

RT reports all failed logins at the error log level. Generally, failed logins can be found in /var/log/syslog. Depending on how you've configured the syslog service, errors might turn up in different places, but they'll all look something like this:

     Jul  4 21:08:01 pallas RT: FAILED LOGIN for root from 209.6.22.246 

You can use standard log summarizing tools to automatically extract all RT login failures from your syslog. A quick and dirty shell script to send you mail about all failed RT logins today would look something like this:

     #!/bin/sh     grep `date +%b%e` /var/log/syslog  \         | grep RT:\ FAILED\ LOGIN \         | mail -s "Today's failed RT logins" rt-admin-user