Sunday, 18 August 2013

How to set up RT part 5: Exim setup

Ultimately we need to get our email client/MUA to send an email to its MTA which sends it to the RT server which gets picked up by exim which sends it to rt-mailgate which sends it to rt to make a ticket.
That should be easy, right?



Configure exim to send and receive email


First of all, the MTA needs to be set up. Since I'm using Debian Squeeze I will be configuring exim4, which comes installed.


To get your bearings, type
# exim -bV
or
# update-exim4.conf -v
to see where exim is reading its config from. Since I've not touched any settings yet, this directs me to /var/lib/exim4/config.autogenerated, which is generated from the config files in /etc/exim4/.


To configure exim, start by using dpkg-reconfigure:
# dpkg-reconfigure exim4-config

I entered the following:
  • type of mail config: mail sent by smarthost, received by SMTP
  • system mail name: same as the server name, tickets.company.com
  • IP addresses to listen on: 127.0.0.1; ::1
  • other domains for which mail is accepted: tickets.company.com
  • machines to relay mail for: blank
  • outgoing smarthost: smtp.company.com
  • hide local mail name: no
  • keep number of dns queries minimal: no
  • mailbox in /var/mail
  • split configuration: yes

At the end of the configuration, exim will restart.


Test the new configuration:
# exim -bt anna@company.com
which ought to return details of the router and mail server that will be used to deliver mail to this address.


Next, test that exim can deliver an email to this address:
# echo 'hello' | mail -s "Test subject" anna@company.com
Next we'll look at configuring RT and rt-mailgate to interact with exim.

Thursday, 15 August 2013

How to set up RT part 4: LDAP authentication

To authenticate users against LDAP, the Apache config needs tweaking as follows:
  <Location />
    SetHandler modperl
    PerlResponseHandler Plack::Handler::Apache2
    PerlSetVar psgi_app /usr/share/request-tracker4/libexec/rt-server
    AuthType Basic
    Require valid-user

# Comment out the htpasswd section
#    AuthName "Restricted Resource"
#    AuthUserFile /etc/apache2/htpasswd

# Replace it with LDAP authentication
    AuthName "company.com AD"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    AuthLDAPGroupAttributeIsDN on
    AuthLDAPBindDN "CN=apache,CN=Users,dc=company,dc=com"
    AuthLDAPBindPassword "your password here................"
    AuthLDAPURL "ldap://dc.company.com:389/CN=Users,DC=company,DC=com?mail?sub?(objectClass=*)"

  </Location>

The advantage to using LDAP over htpasswd is that (a) if you have more than a couple of users to add it's much faster and (b) if LDAP-authenticated users email a ticket to RT their user profile will be automatically set up.

How to set up RT part 3: Basic Request-Tracker configuration

Now that we have Apache configured and working,  we can set up the basics of RT mostly via the web interface.

1. Make a super-user

To make the first super-user, you need to be logged in as root; you’ll have to have apache configured to authenticate against htpasswd (see example config above).
  • Make a new group called, for example, ‘Super-Users’.
  • Add the user you want to be made super-user to this group.
  • Go to Tools / Configuration / Global / Group rights, select the Super-Users group on the left-hand side, and under ‘rights for administrators’ select ‘do anything and everything’.
  • Now you should be able to log out as root, and log in as your new super-user. If the new super-user exists in ldap rather than htpasswd, remember to switch out that part of the apache config.

Note: Logging out
Using apache, I found I was unable to logout - I would click on the logout button, and be immediately logged back in again. In actual fact, using this apache configuration, where authentication is either via a list in htpasswd or with ldap, RT should not present the logout button at all. It can be disabled in RT_SiteConfig.pm by setting
Set($WebFallbackToInternalAuth, 0);
To actually logout, clear the browser cache, and the login box asking for your credentials should be displayed.


2. Groups and Queues

The first bit of configuration you’ll need to do is make some groups, so that when you add users you have somewhere to put them.
  • “Tools / Configuration / Groups / Create”
  • enter the name and description of each new group.
We also need to make some queues so that the tickets can go somewhere.
  • “Tools / Configuration / Queues / Create”
  • enter the name and description of each new group.
There are a bunch of other fields, but you probably don’t need to worry about them right now. Just make sure the ‘enabled’ box is ticked so that your queues are active.

For any given queue, you’re likely to want to assign the following rights:
  • create ticket (by email or ui)
  • reply to a ticket
  • view queue (so they can see their ticket when they log into the selfservice UI)
  • view ticket summary (so they can see the ticket details in the UI)
You can do this by going to each queue, selecting “Everybody” and then assigning rights, or if want to grant the same rights to every queue, assign them via “Tools / Configuration / Global / Group rights”.
A point to note: if you apply rights here they DO NOT show up as ticked at the queue level, even though they are applied.

You’ll also probably want to grant additional rights to the group that will be actioning the tickets. Still under “Tools / Configuration / Global / Group rights”, add the group on the left, and then select appropriate rights. Which will probably be most things. 

The most important ones to grant are probably
  • own ticket
  • take ticket
  • delete ticket (in case of spam)

The requestor(s) of a given ticket will want to be given special rights over that ticket. (A requestor is a person who is waiting for the ticket to be resolved.) Still under “Tools / Configuration / Global / Group rights”, select “Requestor” and grant
  • reply to ticket

Now test making a ticket using the interface on the homepage dashboard.



3. Users

You can create users in a similar manner to groups and queues, ie
  • “Tools / Configuration / Users / Create”
making sure that the apache configuration uses “htpasswd” to store the users and their hashed passwords.

Test that a given user can access / not access the various pages as appropriate. Top tip: to save having to clear your cache to log in as another user, use a different browser.

Wednesday, 14 August 2013

How to set up RT part 2: Configure Apache

After installing the basic triptych of Mysql, Apache and Request-Tracker4, the first of these that needs real attention is Apache.

1. Configure apache to use a cgi handler
I chose modperl (vs. fastcgi).

The modular Apache setup puts configs under /etc/apache2/sites-available, and then symlinks to them from sites-enabled to make them live. So we need to make a config for RT under /etc/apache2/sites-available/tickets.company.com. This is the basic setup, authenticating against htpasswd. I'll cover AD authentication at a later date.


<VirtualHost *:80> 
             # General info
   ServerName tickets.company.com
   ServerAdmin systems@company.com
   AddDefaultCharset UTF-8
   PerlSetEnv RT_SITE_CONFIG /etc/request-tracker4/RT_SiteConfig.pm
   Alias / /usr/share/request-tracker4/html
   Errorlog /var/log/apache2/error.log
   Transferlog /var/log/apache2/access.log
             #Assign perl handler
   <Perl>
      use Plack::Handler::Apache2;
      Plack::Handler::Apache2->preload("/usr/share/request-tracker4/libexec/rt-server");
   </Perl>
   <Location />
      SetHandler modperl
      PerlResponseHandler Plack::Handler::Apache2
      PerlSetVar psgi_app /usr/share/request-tracker4/libexec/rt-server
                # Basic authentication against htpasswd
      AuthType Basic
      Require valid-user
      AuthName "Restricted Resource"
      AuthUserFile /etc/apache2/htpasswd
   </Location>
             # Allow tickets to be emailed

             <Location /NoAuth>
                allow from all
                satisfy any
             </Location>
</VirtualHost>

I also found it was necessary to set in /etc/apache2/apache2.conf
MaxRequestsPerChild 1000
as when it is set to 0, a process will never expire and eventually eat all the memory.


Restart apache, and navigate in a browser to
http://tickets.company.com
and the rt login screen should be presented. You ought to be able to log in as root with the mysql root user password that you set.

How to set up RT part 1: installing the basics

Request-Tracker 4 is a powerful ticketing system but setting it up and making it work was a bit of an epic task. 

The official wiki isn't bad, and the mailing list has a lot of answers to a lot of questions, but I still had to do a lot of experimentation to make things work happily together. So here's a how-to about what I did. It's massive, so I'm going to do it in chunks.


Installing the basics


1. Install a fresh copy of debian squeeze, plus any extras eg vim sudo curl


2. Add the squeeze backports to be able to get the latest version of rt
# vim /etc/apt/sources.list
  deb http://backports.debian.org/debian-backports squeeze-backports main
#aptitude update
3. Install a database: I chose mysql (vs postgresql and sqlite). Remember the password you assign!
# aptitude install mysql-server
# aptitude install rt4-db-mysql
Make sure it is up and running
# /etc/init.d/mysql status
# mysql -p


4. Install a webserver: I chose apache2 (vs nginx)
# aptitude install rt4-apache2
# /etc/init.d/apache2 status
Make sure it works
# curl localhost:80


5. Install request-tracker itself.
# aptitude install request-tracker4

6. At this point in my install, aptitude declared that it needed some dependencies that it didn't intend to install by default, which would leave RT uninstalled. At the prompt of "accept this solution" I said no, and was then invited to install a whole bunch of things, which I said yes to.

Part of the configuration during this process was to enter the following:
-name for the RT instance? myRTserver
-handle site config permissions? yes
Then it went off to install the whole world.
-configure db with dbconfig-common? yes
At this point you'll need to supply the root password you installed mysql with, and set up new passwords for RT to access mysql.