This is based on installing a test RT4 server on a VM called "bembo". Typically you'd want hostname ≠ vhost DNS alias, but this is just a test. 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 PostgreSQL is also an option, please ask)
remctl mailgate, rather than procmail (means no manual dredging out of INCOMING on failure).
Machine Profile
Start out with a small-server.h running SL6_64.
Add the basics to the machine profile:
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):
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:
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.
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
uncharted waters! This bit isn't ready yet. Probably going to be replaced by krbcurl.
Not much is required to get this up and running. On the RT server, just set one define: