RT Care and Feeding

Note that this page is currently being developed contact iainr@infREMOVE_THIS.ed.ac.uk for more information.

This page covers the operation of slurmRT on the clusters in use in the School.


We run RT on a number of services, the main RT service, ISSRT and RDMPUBS RT is an open source ticketing system developed by Best Practical Solutions. It consists of a Web frontend, Mysql or postgres backend and a mail gateway.

Web Front End

The configuration for the web front end is in /etc/rt/RT_SiteConfig.pm and is configured via the file component. Note that you're editing in perl code rather than a configuration file so you may have to escape some characters in the file. The main highlights are:
Set( $DatabaseUser, "root" );
Set( $DatabasePassword, "somegibberish" );
The user/password combination to connect to the database with,
Set( $WebExternalAuto, 1 );
Set( $WebFallbackToInternalAuth, 1 );
Set( $WebRemoteUserAuth,1);
We're using extrernal auth (cosign) by default but we want it to fall back to internal authentication if cosign is not available because we can still then login as the admin user and do things. RT4 has a long section setting additional lifecycles that redefines how some ticket transitions happen, other rts rdon't.

database backend(mysql)

This is the default database and required no comfiguration beyond defining a username and password pair. It's assumed that the front end can connect to a mysql database running on localhost. mysqldump is run daily on weekdays dumping the full database. to recover the database set up a blank mysql instance vie the myql component, run om mysq RunCommand and import the dumped database. not that this will change the mail database password and you will have to edit /disk/data/rtdata/rootpwd in order to get the mysql component to work.

database backend (postgres)

This is evident by the appearance of the postgresql-rt-server header, and the running postgresql server, etc. It can be managed in the same way as any other postgresql server, the processes for which are relatively well-documented on the RAat unit web.

Backups will be taken as usual to the location in postgresql.pgbackupdir

Mail Gateway

Email into rt is gatewayed through crunchie.inf ed.ac.uk. mail for rt and issrt are routed via rt@infREMOVE_THIS.ed.ac.uk and rdmpubs is via infkm@infREMOVE_THIS.ed.ac.uk (Don't ask). Mail is sorted via .procmail filters in each account on crunchie and a gateway script (rt-mailgate) called with approrpiate arguments to queue the email to the correct queue or ticket. if you want to debug this part of the system you can cat an email message (headers included) into the gateway. Logs are generated by procmail (~/log-file) and a complete copy is held of incoming mail for abot a month or so.

Editing the procmail filters

In the case of rt....don't, please don't unless you really know what you're doing. .procmail itself is running under rcs so you will need to co and ci the file. email destined for issrt is mailed to rt+s@inf and mail is then distributed based on the plussed address. THe procmail file for infkm is a lot simpler and that rt tends to have a lot less traffic so if you want to test a procmail filter it may make sense to do so in rdmpubs before trying it in rt or issrt.


Email delivery problems

Mail can go awray, ususally because of issues with the procmail filters or because of database issues. If there have been issues then you can usually figure out what's happened by searching in the procmail log and you can "replay" incoming emails once you've fixed the issue. To do this cd into the ~/Mail directory and run the RECOVERY script. there is additional documentation in the README-RECOVERY file. When you run the RECOVERY file it will generate a working copy of the Incoming-mail file to work on. The best strategy is usually to either select the emails which were not processed correctly and bounce them or, with more complicated problems it's sometimes easier to regressivly remove items which were delivered correctly and then bounce the rest. Note that, just to confuse things, emails may be repeatedly resent through the gateway so there may be multiple copies of the same email in Incoming-Copy. In the past we've been able to programatically strip out dplicate emails but this functionality is broken at the time of writing because of a bug in a perl module.

Web front end can't connect to database.

This is usually caused by the wrong password being used in the configuration. If you are moving rt to another host then the password will have to remain the same as the default passwored generated by the mysql component will be overwritted when you restore from backup.

-- IainRae - 12 Mar 2019

Topic revision: r4 - 08 May 2019 - 08:08:19 - GrahamDutton
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies