Installing an RT4 server from scratch

This is based on installing a test RT4 server on a VM called "bembo" (which became the SL7 Server Migration RT). Typically you'd want hostname ≠ vhost DNS alias. You'd make the change in the usual way via DNS alias, editing the various definitions below:

Note this ensures two important variations on the "old default" RT server config:

• local PostgreSQL server, rather than MySQL (remote postgres is also an option, please ask)
• krbcurl mailgate, rather than procmail (means no manual dredging out of INCOMING on failure).

Machine Profile

Now the trial service (SL7 RT) has become stable, some of this configuration is being moved into dice/options/sl7rt-server.h and dice/options/rt4-server.h -- until it's fully migrated into its proper home, these instructions will be slightly outdated (but should still result in a functioning server).

Start out with a small-server.h running SL6_64.

Add the basics to the machine profile:

#define DICE_OPTIONS_RT_SERVERNAME  sl7tracker.inf.ed.ac.uk
#define DICE_OPTIONS_COSIGN_X509TAG bembo
#define DICE_OPTIONS_COSIGN_DESCRIPTION SL7 Tracker
#define DICE_OPTIONS_COSIGN_VALIDREF ^https://bembo\.inf\.ed\.ac\.uk(/.*)?
#define DICE_RT_ROOT /disk/data
#define LCFG_OPTIONS_NAGIOS_CLIENT_REMCTL off
#define DICE_OPTIONS_APACHECONF_SECURITY_ALLOWHYPHENS
[...]
#include <dice/options/rt4-server.h>
#include <dice/options/rt-postgresql.h> /* after rt server headers! */
#include <dice/options/postgresql-9.4-server.h> /* override 9.2 default - this isn't required, it's just good sense */

/* Basic RT config */
#define RT_EMAIL_ALIAS sl7-tracker
!file.v_databasename            mSET(rt4)
!file.v_databaseuser            mSET(rt)
!file.v_databasepassword        mSET()
!file.v_webdomain               mSET(DICE_OPTIONS_RT_SERVERNAME)
!file.v_webexternalauth         mSET(1)
!file.v_webexternalauto         mSET(1)
!file.v_rtname                  mSET(SL7)
!file.v_sendmailarguments       mSET(-fRT_EMAIL_ALIAS@inf.ed.ac.uk -oi)
!file.v_commentaddress          mSET(RT_EMAIL_ALIAS+comment)
!file.v_correspondaddress       mSET(RT_EMAIL_ALIAS+correspond)
!file.v_additional              mSETQ('Set($WebPath, \'\');\n\
')

Bootstrap

Having configured the profile, wait for the changes and apply as much as we can:

$ om updaterpms run
$ om file configure

HACK: On bembo itself, I had to fix up the data disk (this won't be a problem with a properly-configured VM and data disk configured as separate partition - separate partitioning is the only safe way to do this):

# chown root:root /disk/ /disk/data/
# chmod 755 /disk/ /disk/data/
$ om file configure

Next, the database needs to be started and initialised with RT data:

 $ om x509 start
 $ om postgresql start
 # /usr/sbin/rt-setup-database --help

Now the database is configured, we can start apache/RT itself. Don't expect the cosign servers to have caught your spanning map change, though:

$ rfe lcfg/hanlon
  <make a trivial change; commit>
$ rfe lcfg/mcintyre
  <make a trivial change; commit>
$ om cosign start
$ om apacheconf start

ANOTHER HACK: At this stage apache wasn't configured correctly to serve RT from /; I found this file on another RT server, copied from a previous machine. On bembo I've set this to file component management, but it will be properly integrated into the apache config in future:

!file.files             mEXTRA(rt4_conf)
file.file_rt4_conf      /etc/httpd/conf.d/rt4.conf
file.type_rt4_conf      literal
file.mode_rt4_conf      0644
file.owner_rt4_conf     root
file.group_rt4_conf     root
file.tmpl_rt4_conf      \
Alias / "/usr/share/rt4/html/"\n\
\n\
 <Directory "/usr/share/rt4/html">\n\
  AllowOverride All\n\
  Options ExecCGI FollowSymLinks\n\
\n\
  RewriteEngine On\n\
  RedirectMatch permanent (.*)/$ $1/index.html\n\
  AddDefaultCharset UTF-8\n\
\n\
  AuthType Cosign\n\
  AuthName "SL7 Tracker"\n\
  CosignProtected On\n\
  Require valid-user\n\
\n\
    SetHandler modperl\n\
    PerlResponseHandler Plack::Handler::Apache2\n\
    PerlSetVar psgi_app /usr/sbin/rt-server\n\
 </Directory>\n\
\n

Automatic user/group management

Now we've shown RT is working, we can set it up for automatic user/group management. This grants RT privileges to members of various netgroups, notably rt/sl7tracker/operator for those able to manage tickets. You can create subgroups with the RT_MANAGE_GROUP macro (I'd expect Unit membership to be done this way, adding for example rt/sl7tracker/rat to the ratu-member role.

Remember that RT creates users automatically when they visit (based on their cosign-authenticated REMOTE_USER). Accordingly, the group management can only take place AFTER a user has visited the site at least once. So, a newly-added super-user will need to visit the site, wait for a manual or scheduled pgluser run, then visit the site a second time.

#define DICE_OPTIONS_RT_BASECAP sl7tracker      /* enables pgluser management */
#include <dice/options/rt-postgresql.h>
[...]
!pgluser.users_rtsu             mADD(gdutton)  /* Super-users, for setup/testing */

Having added the pgluser ruleset, run it on the server:

$ om pgluser start
$ om pgluser run -- --init # first run flag

Note that until you have defined netgroups containing RT users (superusers, operators or any kind of managed group) pgluser will be running in 'safe mode' and require to be passed the --init flag, which means its scheduled runs will fail. If you'd prefer not to use LDAP to manage things, you can pass --init by default:

!pgluser.defargs    mADD(--init)

...but this isn't recommended.

Backups and Backup checks

Backups will run automatically (nightly for a week — you might want to change this).

Mirroring should be set up as appropriate with a MIRROR_THIS_AND_TAPE or similar macro.

Backups will also be checked nightly ... and immediately fail as the backups on a new RT will be too small. Reset the backup size by predefining a guard:

#define DICE_OPTIONS_PSQL_BACKUP_SIZE 70k

EMail gateway

Not much is required to get this up and running, but we're using a custom-written bit of gateway CGI which will need to be more carefully configured in future.

On the RT server, we need to configure a few things:

Outgoing Email:
Double-check outgoing addresses at this stage: note these resources have already been mentioned above.

!file.v_rtname                  mSET(SL7RT)
!file.v_commentaddress  mSET(sl7rt-gate+comment\@inf.ed.ac.uk)
!file.v_correspondaddress  mSET(sl7rt-gate+correspond\@inf.ed.ac.uk)
!file.v_sendmailarguments       mSET(-fsl7rt-gate+rtbounce@inf.ed.ac.uk -oi)
!file.v_webbaseurl          mSET(https://sl7rt.inf.ed.ac.uk)
!file.v_owneremail         mSET(<%sysinfo.manager%>)

Incoming Email:
For incoming email we need only define some /sendmail/aliases-local lines on the mail server:

sl7rt-gate: "|/disk/mailraid/scripts/krbcurl https://sl7rt.inf.ed.ac.uk/mailgate"

These alias lines use the krbcurl mechanism which relies on a Kerberos (SPNEGO) authenticated service on the RT server which receives an HTTP connection directly from the mail server. We use a custom script to negotiate the gap between the web service and the rt-mailgate software, restricting its use to the mail server credentials:

#define RT_KRB_MAILGATE
/* add UUN@INF.ED.AC.UK to this list if you'd like to test it manually */
#define RT_MAILSEND_CREDENTIALS mailkrbcurl/crunchie.inf.ed.ac.uk@INF.ED.AC.UK

WARNING: the full configuration for this is being worked into rt4-server and this section will not work on stable PCs for a week or so

-- GrahamDutton - 04 Feb 2016