Security Advancements at the Monastery

Building on my previous posts, “Request Tracker Installation (Part 1 of 2)” and “Request Tracker Installation (Part 2 of 2),” today we are going to discuss how to get programs interacting with Best Practical’s Request tracker (RT). In later posts, we will build upon this to start having our security processes log information to RT. Keep in mind, tickets do not need to only be done as part of a manual process. Tickets can be generated by processes running on the system. The tickets can also be updated by other processes.

The Database

A few diagrams of the RT’s database schema are available:

• Steve Turner’s Model
• The official RT 3.4 schema
• Jesse Vincent’s model (pdf)

If you are unfamiliar with some of the keys and conventions used in Visio graphs, the below table provides some helpful information. Mandatory (not null) columns are displayed in bold.

Further clarification can be found in chapter 8 titled “Architect” of the “RT Essentials” book from O’Reilly. Look for the section “Logical and Object Model” which takes a tour of RT’s logical and object models.

Perl Module

Referring once more the the “RT Essentials” book’s chapter 8 on architecture, the below diagram maps the layers involved with RT.

A quick overview of what the provide:

1. Allowing a database independent interface to Perl is the DBI module.
2. DBIx::SearchBuilder encapsulate SQL queries and rows in simple perl objects allowing object-oriented applications like RT to talk to a table-oriented relational database.
3. The RT application platform libraries provide database connectivity, logginng infrastructures, users, groups, access control, links, etc. Basically it is the guts of RT.
4. The RT ticketing system libraries uses the RT application platform.
5. The Mason handler run on top of the RT core libraries and provides a wrapper around the Mason templating system. The Mason templates consists of the user interface templates, which designed for end users to interact with their browsers, and the REST templates, which are designed to be easy for other software to interact with RT.

Creating, querying, and editing tickets in an RT instance could be done by using RT Command Line Interface (CLI) calls embedded in programs. Or, one could directly plug into the RT libraries. To maintain compatibility with future releases of RT, we will be using RT’s built in REST interface.

Fortunately, Dmitri Tikhonov has created the RT::Client::REST. If Ruby is your preferred language, Tom Lahti has cared a Ruby library to interface with RT.

Jesse Vincent posted recently on the Best Practical blog, “RT 4 – status report.” While it will be awhile before RT4 is out, Jesse has written that “RT4 is based on Jifty and serves up both the legacy /REST/1.0 interface and Jifty’s much more modern REST interface.” End result is that compatibility will be maintained.

Perl Modules Installation

Make sure to follow the instructions from “Request Tracker Installation (Part 2 of 2).” The Perl foundation defines kwalitee as “a set of formalities that tend to coincide with quality, according to consensus. It is of course much less useful than quality, but at least it can be measured.” Install the Perl module Module::CPANTS::Analyse and Test::Kwalitee, along with supporting modules, for quality testing.

 /usr/local/src root# perl -MCPAN -e 'install Module::CPANTS::Analyse'
 /usr/local/src root# perl -MCPAN -e 'install Test::Kwalitee'

If you have read any of Terry Goodkind’s Sword of Truth series of books, you maybe familiar with his character Zedd saying, “If the road is easy, you’re likely going the wrong way.” No where is this more true than in IT. Life is made a bit easier if you check active bugs when setting up software. Fortunately, RT-Client-REST does have an active bug listing.

There is a bug involving CustomFields change in RT 3.8 and how RT matched on the # symbol. RT incorrectly matched when using the REST interface because RT::Client::REST had a CustomField with a # at the end. Jerrad Pierce has just posted that the necessary changes were mote extensive and the code should be pulled down from SVN. We will pull the code from there.

/usr/local/src root# svn checkout \
     http://rt-client-rest.googlecode.com/svn/trunk/ rt-client-rest-read-only
/usr/local/src root# cd  rt-client-rest-read-only/rt-client-rest
/usr/local/src/rt-client-rest-read-only/rt-client-rest root# perl Makefile.PL
/usr/local/src/rt-client-rest-read-only/rt-client-rest root# make
/usr/local/src/rt-client-rest-read-only/rt-client-rest root# make test
/usr/local/src/rt-client-rest-read-only/rt-client-rest root# make install

Connecting up through SSL requires a few additional steps. make sure to install the Perl module Crypt::SSLeay.

 /usr/local/src root# perl -MCPAN -e 'install Crypt::SSLeay'

Ruby

If you need to install Ruby please see my earlier post “Implementing Puppet: Act One.” Ruby 1.9.x is a fairly significant change. See Josh Haberman post “Ruby 1.9.1 released,” Markus Prinz post “Ruby 1.9 – What’s new? What’s changed?“, and Peter Cooper’s post “23 Useful Ruby 1.9 Links and Resources.” If you are working with Ruby, you need Dave Thomas‘ book “Programming Ruby 1.9: The Pragmatic Programmers’ Guide,” which is about to be released and is available in electronic format.

When you issue the “gem install rt-client,” errors involving the TMail file tmailscanner.c will occur. First, it was looking for header files in directory /usr/local/include/ruby-1.9.1 instead of /usr/local/include/ruby-1.9.1/ruby and complaining about “re.h: No such file or directory“. As Zedd would say, “Nothing is ever easy.” If you fix that problem, TMail will complain about “struct RString.” This is a show stopper if you want to use Ruby 1.9.x. When this gets fixed, I will try and come back and update this post.

Connecting Securely

Modify the RT_SiteConfig.pm to use port 443.

Before (Without SSL): Set($WebBaseURL , " http://rt.yourdomain.com");
After (With SSL): Set($WebBaseURL , " https://rt.yourdomain.com:443");

Please change rt.yourdomain.com to the appropriate host value for your organization.

The REST Interface does not support HTTP-Authentication. If your web server requires users to log in, you will end up with authentication problems. As of this writing, there are problems when when both authentication mechanisms are used together. A work around, if your program is running on the same machine as the web server, is to setup a virtual host for 127.0.0.1 that does not use HTTP-Authentication. Make sure to connections are allowed from client 127.0.0.1 only. The outside world interface can continue to be forced to use HTTPS and HTTP-Authentication.

Sample Program

With the supporting software in place, we can now write a program. Below is a simple program that connects up to OpenSSL’s RT site, pulls out all new and open tickets belonging to the OpenSSL-Bugs queue, and prints out the id, subject, owner, status, and when the ticket was created.

#!/usr/local/bin/perl -w

  use strict;
  use Error qw(:try);
  use RT::Client::REST;
  use Data::Dumper;

  my %Config = (
      server      => 'http://rt.openssl.org/',
      username    => 'guest',
      password    => 'guest',
      queue       => 'OpenSSL-Bugs'
  );
  my $rt = RT::Client::REST->new(
    server => $Config{server},
    timeout => 30,
  );

  try {
    $rt->login(username => $Config{username}, password => $Config{password} );
  }
  catch Exception::Class::Base with {
    die "problem logging in: ", shift->message;
  };

  my @ids;
  try {
    @ids = $rt->search(
        type    => 'ticket',
        query   => qq[
            (Status = 'new' or Status = 'open')
            and
            Queue = '$Config{queue}'
        ],
    );
  }
  catch Exception::Class::Base with {
    die "search failed", shift->message;
  };
  for my $id (@ids) {
    my $ticket = $rt->show(type => 'ticket', id => $id);
    print "ID: $id\n";
    print Dumper($ticket);
   }

Final Thoughts

One of the more difficult aspect of connecting several different open source projects is what to do with various versions of the software. While it is unfortunate that we will have to wait for software to get updated on the Ruby side, we are now ready to start working with Perl. In the next post, we will go through the steps to take a program that monitors activity and informs administrators via email, to a system that uses RT to perform this function. By doing so, we gain operational tracking capability. We are about to start having some fun.