Monday, February 11, 2013

openSUSE 12.2: How I installed and set up Request Tracker

One of my projects at work is to learn Request Tracker. Here's how I installed it and got it running on openSUSE 12.2.



NOTE TO USERS OF OPENSUSE 12.3
For a description of how I did this procedure on openSUSE 12.3, go HERE, instead!

DISCLAIMER: This is only a description of something that I did. It is not intended to serve as a guide or instructions. If you decide to imitate me by following these steps, you do so at your own risk. Since I am not providing you any service, I am under no obligation to provide you with support.

This job recently got a lot easier with the addition of the request-tracker package to the Open Build Service. To get the package and install it, I went to software.opensuse.org and typed "request-tracker". In the results, I clicked on openSUSE 12.2 and noticed that the package is "unstable", which sounds worrisome but did not deter me.

In practical terms, what "unstable" means in the case of request-tracker is that installing it involves adding a development repository -- specifically devel:languages:perl. This is because request-tracker is written entirely in Perl and depends on a large number of Perl modules, which are all packaged individually and some were only recently added to the "devel:languages:perl" repository, which is a staging area where packages accumulate while the maintenance team works on possibly including them in the main distribution.

Anyway, all that aside, installing request-tracker is simple thanks to the selfless labors of the package maintainers and the magic of YaST's "1 Click Install". Installing the request-tracker package and all its dependencies is just the beginning, however. My goal was to get RT running, and by "running" I mean logging in and displaying the "RT at a glance" page in the web browser. For this, I needed to set up MySQL and Apache2. Later, I'll set up RT to handle incoming and outgoing emails.

MySQL


After installing the request-tracker package, I installed MySQL. Here's a list of all the MySQL-related packages I had installed when I was done:
# rpm -qa | grep mysql
libqt4-sql-mysql-32bit-4.8.1-2.12.1.x86_64
mysql-community-server-errormessages-5.5.28-1.4.1.x86_64
libmysqlclient18-5.5.28-1.4.1.x86_64
mysql-community-server-client-5.5.28-1.4.1.x86_64
mysql-community-server-5.5.28-1.4.1.x86_64
request-tracker-db-mysql-4.0.10-1.1.noarch
libreoffice-base-drivers-mysql-3.5.4.13-1.4.5.x86_64
libqt4-sql-mysql-4.8.1-2.12.1.x86_64
perl-DBD-mysql-4.021-25.2.x86_64
libmysqld18-5.5.28-1.4.1.x86_64
libmysqlclient18-32bit-5.5.28-1.4.1.x86_64

Once I had MySQL installed, the first thing I did was "secure" it by running:
# mysql_secure_installation

At first I got an error that said: "Can't connect to local MySQL server through socket 'blah blah'". All this means is that the MySQL server is not running. Upon first being installed, MySQL is not set up in any way. So the daemon ("service") does not run. I found I could check whether the service is enabled or not with the command:
# chkconfig mysql
mysql   off

So I enabled the service ("enabled" means the service is set to start at boot):
# systemctl enable mysql.service
mysql.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig mysql on

I also found that the service can be enabled via YaST -> System -> System Services (Runlevel).

Next I confirmed that the MySQL service is enabled and running:
# chkconfig mysql
mysql  on
# rcmysql start
redirecting to systemctl
#

Just to be 1000% sure I did a systemctl status mysql.service and noted that the service is listed as "loaded" and "active (running)".

Apache2


Next I installed Apache2. Again, I won't go into the exact commands, but I will list the Apache2-related packages I had installed when I finished:
# rpm -qa | grep apache2
apache2-2.2.22-4.10.1.x86_64
apache2-prefork-2.2.22-4.10.1.x86_64
apache2-mod_fcgid-2.3.6-9.1.2.x86_64
apache2-mod_perl-2.0.6-71.1.x86_64
apache2-utils-2.2.22-4.10.1.x86_64

Configuring Apache2 is, well, not as bad as it looks. Since my goal was merely to get RT up on the screen, I didn't have to get my hands too dirty. For the sake of simplicity, I will access RT only from the local host (localhost, a.k.a. 127.0.0.1). The URL will be http://rt (hard to get any simpler than that).

First, set up "rt" as an alias for "localhost":
# vim /etc/hosts
... find the line that says "127.0.0.1    localhost"
and change it to "127.0.0.1    localhost  rt" ...

Then, I went to the directory /etc/apache2/vhosts.d and made a file rt.conf with the following contents:
<Virtualhost rt:80>
    AddDefaultCharset UTF-8
    HostnameLookups Off 
    DocumentRoot /usr/share/request-tracker/html
    <Location />
        Order allow,deny
        Allow from all

        SetHandler modperl
        PerlResponseHandler Plack::Handler::Apache2
        PerlSetVar psgi_app /usr/sbin/rt-server
    </Location>
    <perl>
        use Plack::Handler::Apache2;
        Plack::Handler::Apache2->preload("/usr/sbin/rt-server");
    </Perl>
</Virtualhost>

Finally, I had to add mod_perl to the list of modules that apache2 loads. In openSUSE this is in the /etc/sysconfig/apache2 file, specifically in the line that looks like APACHE_MODULES="..." -- that list of modules must include perl. On my system it looks like this, except of course all the modules are on a single line:
APACHE_MODULES="authz_host actions alias auth_basic authz_groupfile authn_file 
authz_user autoindex cgi dir include log_config mime negotiation setenvif 
status userdir asis imagemap perl reqtimeout authz_default"

At this point I tried starting the apache2 daemon:
# rcapache2 start
redirecting to systemctl
# rcapache2 stop
redirecting to systemctl
#

All green so far.

RT itself


We're almost there, but not quite. We still haven't configured RT itself. That, too, is simple - RT uses only one configuration file, called RT_SiteConfig.pm. You will find it in /etc/request-tracker. Here's mine (of course, I recommend reading the comments in the RT_SiteConfig.pm included with the distribution, but for brevity I am leaving them out here):
Set($rtname, 'Smithfarm');
Set($Organization, 'TheBrain');
Set($WebDomain, 'rt');
Set($WebPath, "");
Set($Timezone, 'Pacific/Rarotonga');
Set($SendmailPath, '/usr/sbin/sendmail');

1;

(Actually, I don't live in Rarotonga. I consulted /usr/share/zoneinfo and chose the appropriate value for where I live.)

After setting up the basic RT configuration, I configured MySQL to work with RT by running:
# rt-setup-database --action init

Then I fired up Apache:
# rcapache2 start

and pointed my browser (running on the local host) to http://rt. First, the RT login screen appears. After entering user root and password password, I finally saw the "RT at a glance" page in the browser window.

10 comments:

  1. Thanks for the walk through but it seems to be failing for me. I followed the directions and matched or exceeded all of the MySql and Apache2 libraries you have installed. I configured the rt.conf file as displayed and all I get it "It works!" in the browser when i hit http://rt or 127.0.0.1. This tells me apache2 is running and it didn't error out on start. How can I check to see if RT is running right?

    ReplyDelete
    Replies
    1. This is on openSUSE 12.2, right?

      Delete
    2. Ya this is OpenSuse 12.2. I rechecked all of the configuration files and everything matches up. I did see that in the RT_Config file the $RTName and Organization were double quotes but changing that did nothing. I didn't set the timezone or the send mail as I am EST and not configured for mail yet. I did everything else you have listed. A friend recommended checking the DocumentRoot but that checks out with everything I would expect. I am seeing that PerlResponseHandler didn't show in green in VIM when I created the rt.conf file. My APACHE_MODULES is different than yours but it does include perl. Any suggestions?

      Delete
    3. http://rt showing "It works" would seem to indicate the problem is in your Apache configuration. If it were me, I would look in the logs (/var/log/apache2). A useful trick is to first run "tail -f" on the logfile you're interested in, then browse to http://rt -- if you have both the browser and the terminal window open at the same time, you will see in real time what the apache2 daemon writes to the logfile. You can also consult the Apache documentation to find out what other debugging options there are. Good luck!

      Delete
  2. Please note that the RPM named "request-tracker" already contains two different apache2 configurations that normally just need to be linked from their initial directory /etc/request-tracker/apache2/ into /etc/apache2/conf.d/ - so if you want to go with apache2 using mod_perl, just log in as root and do something like:


    ln -s /etc/request-tracker/apache2/apache2-modperl2.conf /etc/apache2/conf.d/


    That allows you to benefit from changes in the RPM automatically without the need to change anything in an additional configuration file.

    ReplyDelete
  3. I followed your instructions to the tee and it works. Thank you Smithfarm. Just one question though. My server is on LAN and has 192.168.10.120 as its IP address. I would like our staff to access the RT by typing this IP address within the LAN. How do I change the http://rt to http://192.168.10.120. Thank you for your reply.

    ReplyDelete
    Replies
    1. Can't be sure without testing, but I'd start by changing this line:

      Set($WebDomain, 'rt');

      Try replacing 'rt' with '192.168.10.120' - Let me know how it works

      Delete
    2. No idea if it will work, but I'm thinking you'll also need to rename the virtual server configuration file 'rt.conf' to '192.168.10.120.conf' and edit the first line of that file to:

      <Virtualhost 192.168.10.120:80>

      Delete
    3. I have tried all combinations. This is the warning message shown everytime a click a link on the site.

      RT has detected a possible cross-site request forgery for this request, because the Referrer header supplied by your browser (192.168.12.120:80) is not allowed by RT's configured hostname (rt:80). A malicious attacker may be trying to create a ticket on your behalf. If you did not initiate this request, then you should alert your security team.

      Any help you can offer ??

      Delete
    4. Look in RT_SiteConfig.pm for the Set($WebDomain, 'rt'); line, like I wrote above.

      Delete