 Print-friendly Version
RT: Request Tracker, Part 1By Amy Rich Part II: RT Concepts and Configuration A good ticketing system is vital for keeping track of the flood of requests users and machines generate for system administrators. If an organization is operating without some sort of tracking software, requests tend to get lost, forgotten, or buried under the day-to-day workload. If an organization lacks this sort of tracking system, it should be a priority to install something immediately. If done correctly, training members of an organization to use a ticketing system improves communication and customer satisfaction. Tracking requests cuts down on the amount of time spent hunting down old information and leaves a clear history that also provides a crude form of documentation if the organization has nothing better in place. The productivity of the support people therefore improves and more time exists for project work and capacity planning. There are a number of options available for helpdesk/ticketing systems, and they range in price and complexity from free and very simple to extremely expensive and involved. Some popular options include Remedy, Clarify, Quantum, and RT. My preference leans towards RT, coming in at free and extremely flexible on the cost and complexity spectrum. RT works well in small, mid-sized, and some larger environments. Jesse Vincent, author of RT: Request Tracker, founded Best Practical Solutions, LLC in 2001 to offer support and custom development consulting to RT users. Jesse -- and now Best Practical Solutions, LLC -- releases each version of RT under the GNU GPL so it's free to install, modify, and redistribute. In this and the next article, I'll offer an overview of how RT works, detail installation instructions, and cover the basics of configuration. How RT WorksRT uses a back-end database, a perl-based main engine, and front-end web and mail interfaces. The recommended database for use with RT is MySQL, but it also works with PostgreSQL. The recommended web interface is the Apache web server with mod_perl or mod_fastcgi. Virtually any MTA will work for the mail gateway, because all interaction with RT happens through aliases that pipe to a perl program.The number of options and customizations available can make RT installation and configuration appear daunting, but the way most organizations will use RT is actually fairly simple to set up. Later in this article, I'll walk through installing RT and all of its dependencies. The next article will describe the options to RT in-depth and walk through a simple configuration. For now, here's a simple example of how a user would interact with a sysadmin team using RT. Bob, an engineer at Organization X, needs a new test system set up in his lab, so he sends email to machine-installs@organizationx.domain to open a ticket. The machine that runs the ticketing system receives the mail, looks it up in the aliases file, and pipes it to one of RT's perl programs. A ticket opens in the queue "machine-installs" with Bob as the requestor and a status of "new." This ticket is stored in the database, along with its associated information. The opening of the ticket triggers an email, with the body of Bob's email, to the sysadmin staff in charge of building new machines. Bob also receives an automated email from RT informing him that a ticket has been opened and that further email correspondence about the ticket should contain a specific Subject: prefix. This ensures that Bob doesn't open up multiple tickets for the same issue. Jane, one of the sysadmin staff who builds new machines, uses the web interface to interact with RT. She sees the email from RT and goes to take ownership of the ticket. She realizes that there are a number of things that have to happen before Bob's machine can be built.
To start, Jane changes the ticket status from "new" to "open" and adds ticket 123 to the "Depends on" field of Bob's ticket. She then responds to the ticket request, via the web interface of RT, asking Bob for the information she needs to create the jumpstart profile. Jane also needs the NOC to activate that port, so she can either open up a new ticket with the NOC (and also add that ticket to the "Depends on" field of Bob's ticket), or she can respond with this request to Bob's ticket and Cc: the NOC. She may also temporarily turn over ownership of the ticket to the NOC until the drops are activated. At that point, the NOC could change the ownership back to Jane. How to best accomplish the interaction between the NOC and Jane will differ from site to site. Meanwhile, Bob responds, via his mail client, to Jane's request for more information, and she gets started on building the profile. The NOC activates the drops, and now Jane waits on for the old machine to come out of service. An issue arises with taking the old machine out of service, so Jane gets the OK to order a new machine. Jane removes the dependency of ticket 123 and replies to the ticket, letting Bob know what's going on. She also changes the status of the ticket from "open" to "stalled" while she waits for the new hardware to be delivered. When the new machine arrives, Jane changes the status of the ticket back to "open" and builds Bob's machine. After the machine is finished and installed in Bob's lab, Jane resolves the ticket. The ticket's history shows all the ownership, status, and dependency changes as well as the bodies of each of the email messages and any extra notes that Jane made. If there's a problem with the machine, Bob can simply send in another email (with the correct Subject: prefix) and the ticket will be reopened with all of its history available. Should Bob open a separate ticket, it can easily be merged into the original ticket if desired. The exchange of email between Bob, Jane, and the NOC keeps the necessary people in the loop and makes Bob feel like his needs are recognized and important to the sysadmin staff. The sysadmin staff keeps track of progress on the ticket, even if Jane takes vacation or sick leave. Keeping important information in the ticket allows for later review in case of problems or if the sysadmin team needs to justify to upper management how the company time and money was spent. Everyone wins. Installing RT's DependenciesAs mentioned above, installing RT requires a database, a web server, perl, and many perl modules. I started with a clean (full) install of Solaris 9 Operating System, and installed and compiled packages to create a machine devoted to running RT. Some sites may already have a few or many of the prerequisites and can skip these steps. Some sites may also want to tweak selected instructions to better meld into the existing environment. The first task was to install a compiler, a new version of perl, and a few necessary tools. I obtained pre-made gcc, flex, and perl packages for Solaris 9 OS from www.sunfreeware.com. These packages install into /usr/local so that they do not conflict with Sun's stock packages or the third-party tools installed into /usr/sfw. Install the gcc Package I always remove /usr/ucb/cc, usually as part of my jumpstart install, because it causes an inordinate number of headaches if Sun's compiler isn't installed on the machine. rm /usr/ucb/ccThen I downloaded, unzipped, and installed the package, using pkgadd: ncftpget ftp://ftp.sunfreeware.com/pub/freeware/sparc/9/gcc-3.2.3-sol9-sparc-local.gz gunzip gcc-3.2.3-sol9-sparc-local.gz pkgadd -d gcc-3.2.3-sol9-sparc-localInstall the Flex Package Again, installing a Sunfreeware.com package was pretty straightforward: ncftpget ftp://ftp.sunfreeware.com/pub/freeware/sparc/9/flex-2.5.4a-sol9-sparc-local.gz gunzip flex-2.5.4a-sol9-sparc-local.gz pkgadd -d flex-2.5.4a-sol9-sparc-localCompile and Install Berkeley DB Berkeley DB is required by Sunfreeware.com's perl. Because it's easier to do all of the perl installation and configuration at once, I paused in my installation of Sunfreeware.com packages to compile and install DB. I obtained the source code and necessary patches from http://www.sleepycat.com/download/patchlogs.shtml. Once there, I downloaded the following: db-3.3.11.tar.gz patch.3.3.11.1 patch.3.3.11.2Then unpacked the src and patched it: gtar zxf db-3.3.11.tar.gz mv patch* db-3.3.11 cd db-3.3.11 gpatch -p0 < patch.3.3.11.1 gpatch -p0 < patch.3.3.11.2When built with no options, Berkeley DB installs into its own directory in /usr/local. The sunfreeware.com version of perl looks for the libraries in /usr/local/lib (as will many other programs that try to link with -ldb). Instead of modifying -L and -R for each piece of software that needs to be built, or creating a symlink tree, I prefer to just set DB's prefix to /usr/local so it follows the traditional GNU-style layout: cd build_unix sh -c "CC=gcc ../dist/configure --prefix=/usr/local" make make installSome organizations may also wish to create a Solaris package for portability to other machines and for use with jumpstart. Install the perl Package I chose to install the perl package from Sunfreeware.com for two reasons. First, Sun's perl is compiled with Sun's compiler. This creates problems when trying to install new perl modules with gcc since perl attempts to compile new modules with the same compiler that compiled perl itself. One way to try and work around that is to install the Solaris-PerlGcc module located at http://cpan.org/modules/by-authors/id/ABURLISON/, but I ran into compilation issues with some perl modules when trying to use gcc combined with Sun's perl. Secondly, if multilingual support in RT is wanted/needed, it's strongly recommended that perl 5.8.0 be used instead of Sun's older 5.6.1. ncftpget ftp://ftp.sunfreeware.com/pub/freeware/sparc/9/perl_s-5.8.0-sol9-sparc-local.gz gunzip perl_s-5.8.0-sol9-sparc-local.gz pkgadd -d perl_s-5.8.0-sol9-sparc-localMake sure /usr/local/bin is in the path before /usr/bin and /bin for the user building all of the software necessary for RT. This insures that perl 5.8.0 is used instead of Sun's default perl. Or, if you're opting to try to use Sun's perl with Solaris-Gcc, instead of installing the Sunfreeware.com perl, set the environment variable PERL5LIB to /usr/perl5/site_perl/5.6.1/Solaris/PerlGccafter installing the module. Configure CPAN CPAN stands for the Comprehensive Perl Archive Network. With some configuration, perl can be run from the command line (using the CPAN shell) on any machine to search for and install new modules. I've found that the CPAN shell is often a mixed blessing. If the machine is not running the newest version of perl, CPAN can upgrade it on the fly while trying to solve dependencies for just one module. This is hardly optimal if the machine should really be running the version of perl that's already installed. On the other hand, using the CPAN shell can, as evident with the RT installation, saves a lot of time and effort by automatically resolving dependencies and installing things without much user intervention. Since I opted to use the latest version of perl for this installation, I was reasonably comfortable that CPAN wouldn't yank the rug out from under me. Invoking the CPAN shell for the first time requires doing some configuration. The syntax to start the shell is: perl -MCPAN -e shell
Here's an example configuration dialog. Commonly, I would suggest answering "ask" to the question Another caveat with the CPAN shell is that using a mirror with a stale, out of date package database causes much grief. The first time through this test installation, I chose a mirror that was, unbeknownst to me, 54 days out of date. I had trouble downloading and building a large number of modules. I finally noticed that the CPAN shell was complaining of the stale mirror, and things went much smoother after I eliminated the culprit from my list of mirrors. Are you ready for manual configuration? [yes] CPAN build and cache directory? [/root/.cpan] /usr/local/cpan Cache size for build directory (in MB)? [10] Perform cache scanning (atstart or never)? [atstart] Cache metadata (yes/no)? [yes] Your terminal expects ISO-8859-1 (yes/no)? [yes] Policy on building prerequisites (follow, ask or ignore)? [follow] Where is your gzip program? [/usr/bin/gzip] Where is your tar program? [/usr/bin/tar] /usr/sfw/bin/gtar Where is your unzip program? [/usr/bin/unzip] Where is your make program? [/usr/xpg4/bin/make] Warning: lynx not found in PATH Where is your lynx program? [] Where is your wget program? [/usr/sfw/bin/wget] Where is your ncftpget program? [/usr/sfw/bin/ncftpget] Where is your ftp program? [/usr/bin/ftp] What is your favorite pager program? [/usr/bin/less] What is your favorite shell? [/bin/tcsh] Your choice: [] Your choice: [] Your choice: [] Timeout for inactivity during Makefile.PL? [0] Your ftp_proxy? Your http_proxy? Your no_proxy? Select your continent (or several nearby continents) [] 5 Select your country (or several nearby countries) [] 3 Select as many URLs as you like, put them on one line, separated by blanks [] 28 9 44 Enter another URL or RETURN to quit: [] Your favorite WAIT server? [wait://ls6.informatik.uni-dortmund.de:1404]With the CPAN shell configured, I was ready to install some initial packages. Any lines below that start with cpan> are commands run within the CPAN shell. While running the CPAN shell, the install command downloads, unpacks, builds, tests, and installs a module or bundle. The get command downloads the src and unpacks it. The look command opens a UNIX shell in the unpacked source directory. To get back to the CPAN shell after using the look command, just issue an exit from the subshell.
A couple of modules, such as Term::ReadKey and IPC::ShareLite, would not, for varied reasons, install straight from the CPAN shell. I downloaded these with CPAN, but built and installed them by hand. The commands not prefixed by cpan> get Term::ReadKey cpan> look Term::ReadKey perl Makefile.PL make make test make install exit cpan> install Bundle::CPANAfter reinstalling the CPAN bundle, reload the CPAN shell: cpan> reload cpanIn a few cases, installing a module means answering questions. In cases other than those I specifically mention below, I chose the default answer.
cpan> install IPC::ShareLite
Directories to use for library searches?
[/usr/local/lib /lib /usr/lib /usr/ccs/lib /usr/ucblib] \
/usr/local/lib /usr/sfw/lib /lib /usr/lib /usr/ccs/lib /usr/ucblib
Your void support flags add up to what? [0] 15
Press return or use a shell escape to edit config.sh: !vi config.sh
IPC::ShareLite refused to acknowledge that my compiler was actually gcc, so I had to break out of the default install and edit config.sh with vi (as shown above). I changed gcc='' to gcc='/usr/local/bin/gcc', saved the file, and exited vi. Everything went fine from there.
cpan> install DBI cpan> install Net::SSLI also had issues getting FCGI to install via the RT dependencies run, which I'll describe later. So, once again, I used CPAN to grab the module here, and then installed it by hand: cpan> get FCGI cpan> look FCGI perl Makefile.PL make make test make install exit cpan> quitThat concludes the CPAN shell work that I did by hand, but there were a number of modules still left to go that would be handled by one of the RT install scripts at a later point. Install MySQL Solaris binaries are available from MySQL's web site, so installation is fairly simple. The gzipped tar file is just a directory structure that contains the entire MySQL tree. I chose to put mine in /usr/local, but it can be relocated anywhere. First, I made a mysql group and user: groupadd -g 88 mysql useradd -u 88 -g 88 -d /usr/local/mysql -c "mysql user" mysqlThen I went to the MySQL mirrors page and chose a mirror close to me. I downloaded the latest MySQL into /tmp, and then unpacked it, set up the default databases, and fired up the daemon: cd /usr/local gtar zxf /tmp/mysql-3.23.56-sun-solaris2.9-sparc.tar.gz ln -s mysql-3.23.56-sun-solaris2.9-sparc mysql cd mysql scripts/mysql_install_db chown -R root:mysql . chown -R mysql data bin/safe_mysqld --user=mysql &It's customary to change the administrator password for MySQL at this point, but the RT install will try to connect to the MySQL instance with no password, so I left that task till later. As it stands now, MySQL will not start on the next reboot. A startup/shutdown script should be written and added to /etc/init.d and linked to from the appropriate rc directories to make the installation complete. Compile and Install OpenSSL Because RT requires a username and a password to access the queues via the web, I wanted to make sure that I installed an SSL-capable web server. This meant that I needed to link with the SSL library at compile time. I chose to compile OpenSSL from source, but Sunfreeware.com also has an OpenSSL package. ncftpget http://www.openssl.org/source/openssl-0.9.7b.tar.gz gtar zxf openssl-0.9.7b.tar.gz cd openssl-0.9.7b ./config -fPIC make make installCompile and Install mm I wanted to compile Apache with mm, so I downloaded, compiled and installed that next: ncftp ftp://ftp.ossp.org/pkg/lib/mm/mm-1.3.0.tar.gz gtar zxf mm-1.3.0.tar.gz cd mm-1.3.0 ./configure --disable-shared make make test make installCompile and Install Apache+mod_ssl As mentioned above, I wanted to compile Apache with SSL support. Since Apache 1.3.x seemed to work better for RT at this point, that meant I also needed mod_ssl. For those who've never done it, compiling Apache and mod_ssl together is a bit different than the standard GNU style install. First, obtain and unpack the source for both: ncftpget http://www.modssl.org/source/mod_ssl-2.8.14-1.3.27.tar.gz ncftpget http://www.apache.org/dist/httpd/apache_1.3.27.tar.gz gtar zxf mod_ssl-2.8.14-1.3.27.tar.gz gtar zxf apache_1.3.27.tar.gzThen (when building the dynamic mod_ssl shared object (DSO) the easy way) Apache is configured and built from within the mod_ssl source directory instead of its own source directory. The configuration settings below will build mod_ssl as a DSO and install Apache into /usr/local/apache (the default installation directory).
cd mod_ssl-2.8.14-1.3.27
./configure --with-apache=../apache_1.3.27 \
--with-ssl=../openssl-0.9.7b \
--with-mm=../mm-1.3.0 \
--enable-shared=ssl \
--disable-rule=SSL_COMPAT
There also are two other ways to compile Apache (with a static mod_ssl and with a DSO that's configured from within the mod_ssl directory but built inside the Apache directory), but this way incorporates flexibility (DSO) with ease (one configure step). If additional Apache configuration needs to be done, one of the other two build methods might be more appropriate. For additional configuration options, run configure with the --help switch and see the Apache installation documentation.
I ran make to build the src. At this point, before installation, I created both the certificate authority (CA) key and the server key. I chose to use a self-signed certificate instead of buying one from a company like Verisign or Thawte. This SSL Certificates HOWTO document is a decent primer on SSL certificates. To create the certificates, I ran the command:make certificate TYPE=customThe dialog for creating the keys was: Signature Algorithm ((R)SA or (D)SA) [R]: 1. Country Name (2 letter code) [XY]:US 2. State or Province Name (full name) [Snake Desert]:California 3.Locality Name (e.g., city) [Snake Town]:Palo Alto 4. Organization Name (e.g., company) [Snake Oil, Ltd]:YourCompany, Inc. 5. Organizational Unit Name (e.g., section) [Certificate Authority]:YourCompany CA 6. Common Name (e.g., CA name) [Snake Oil CA]:YourCompany CA 7. Email Address (e.g., name@FQDN) [ca@snakeoil.dom]:ca@your.domain 8. Certificate Validity (days) [365]:3650 Certificate Version (1 or 3) [3]: 1. Country Name (2 letter code) [XY]:US 2. State or Province Name (full name) [Snake Desert]:California 3. Locality Name (e.g., city) [Snake Town]:Palo Alto 4. Organization Name (e.g., company) [Snake Oil, Ltd]:YourCompany, Inc. 5. Organizational Unit Name (e.g., section) [Webserver Team]:RT Server 6. Common Name (e.g., FQDN) [www.snakeoil.dom]:rt.your.domain 7. Email Address (e.g., name@fqdn) [www@snakeoil.dom]:sysadmin@your.domain 8. Certificate Validity (days) [365]:3650 Certificate Version (1 or 3) [3]: CA Encrypt the private key now? [Y/n]: y Server Encrypt the private key now? [Y/n]: nBe sure to leave the server's private key unencrypted, otherwise someone must retype the passphrase whenever Apache restarts. Now I created a group and user for the web server: groupadd -g 80 www useradd -u 80 -g 80 -h /usr/local/apache -c "apache" wwwAnd, finally, installed Apache and the newly created certificates: make installCompile and Install mod_fastcgi Since mod_perl tends to be used by a number of other packages and can only be used by one package per web server instance, I opted to use FastCGI for RT instead. To install mod_fastcgi:
ncftpget http://www.fastcgi.com/dist/mod_fastcgi-2.4.0.tar.gz
gtar zxf mod_fastcgi-2.4.0.tar.gz
cd mod_fastcgi-2.4.0
/usr/local/apache/bin/apxs -o mod_fastcgi.so \
-c *.c /usr/local/apache/bin/apxs -i -a \
-n fastcgi mod_fastcgi.so
Compile and Install RTAt last I'd made it to the point where I needed to obtain the RT source code and unpack it: ncftpget http://www.bestpractical.com/pub/rt/release/rt-3-0-2.tar.gz gtar zxf rt-3-0-2.tar.gz cd rt-3-0-2RT wants its own group, so I picked 90 (it can be any GID that isn't already in use): groupadd -g 90 rtI then ran configure with the --help switch to see all of the options available. I decide to do a fairly vanilla install, so I ran configure as follows: ./configure --with-db-rt-pass='rtpasswd' --prefix=/usr/local/rt3The next step was to resolve all of the other perl module dependencies. First, I wanted to see what was left to install, so I ran: perl sbin/rt-test-dependencies --with-mysql --with-fastcgiThen, to have it actually install all of the dependencies, I added the --install flag to the above command: perl sbin/rt-test-dependencies --with-mysql --with-fastcgi --installAfter all of the perl dependencies are satisfied, I ran: make install What's NextThough RT was installed, it still wasn't functional. In the next article I'll cover RT's concepts and configuration settings and actually go through a simple site configuration, including screen shots.Resources
Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License. |
 |
 | |