Applications AWS

Request Tracker (RT) Ticketing and ITSM on AWS User Guide

| Product: Request Tracker

Overview

Request Tracker (RT) is a mature, enterprise grade ticketing and workflow platform from Best Practical, used for help desks, IT service management, customer support, network operations and incident response. Teams track work as tickets in configurable queues, with custom fields, ownership and status workflows, group and role based permissions, approvals, a searchable history of every correspondence, and a self service portal for requesters. Under the hood RT is a Perl and Mason web application served by Apache with mod_perl, backed by PostgreSQL.

This cloudimg image installs RT from the maintained distribution packages, so every Perl dependency is package managed rather than built from CPAN, and runs it behind Apache configured with the prefork MPM and mod_perl (RT is not thread safe). The bundled PostgreSQL 16 cluster is placed on a dedicated data volume: the database directory is bind mounted onto a separate EBS disk before PostgreSQL is installed, so every ticket, attachment, transaction, queue and user account lives on its own independently resizable disk. PostgreSQL binds to the loopback interface only and is never exposed on a host port; only Apache on port 80 is public.

Security is enforced from first boot. RT ships a well known default root and password login, which this image never ships: before the web front door is reachable, the RT administrator password, the PostgreSQL role password and the RT database secret are all generated uniquely for the individual instance, and RT's web domain is set to the instance's own public address so ticket links and self service URLs are correct. Backed by 24/7 cloudimg support.

What is included:

  • Request Tracker 5.0.5, the GPL-2.0 licensed enterprise ticketing platform from Best Practical
  • Apache with the prefork MPM and mod_perl serving RT on port 80, and a bundled PostgreSQL 16 on the loopback interface
  • A dedicated data volume carrying the PostgreSQL cluster, bind mounted onto /var/lib/postgresql
  • The well known default root login rotated away at build time, with a unique administrator password generated on first boot
  • A per instance PostgreSQL role password and RT database secret generated on first boot, written to a root only file
  • RT's web domain set to the instance public address on first boot so ticket links and cookies are correct
  • postgresql.service and apache2.service as systemd units, enabled and active
  • 24/7 cloudimg support

Prerequisites

An AWS account, an EC2 key pair in the target region, and a VPC with a public subnet. m5.large (2 vCPU / 8 GiB RAM) is the recommended instance type. Security group inbound: allow 22/tcp from your management network for SSH and 80/tcp for the web UI.

Step 1 - Launch the AMI

Subscribe to the listing in AWS Marketplace, then launch an instance from the AMI into your VPC with the security group described above. Choose the m5.large instance type and attach your EC2 key pair. The RT schema ships in the image on the dedicated data volume, so the ticketing system comes up within a couple of minutes of first boot, after it has minted this instance's unique secrets and set RT's web domain to the instance address.

Step 2 - Connect to your instance

Connect over SSH as the default login user for the operating system variant you launched. The login user differs per OS, so use the row for your variant:

OS variant SSH login user
Ubuntu 24.04 ubuntu 
ssh -i your-key.pem ubuntu@<public-ip>

Step 3 - Read your unique credentials

The RT administrator password is generated uniquely on this instance's first boot and written to a root only file. Read it over SSH:

sudo cat /root/request-tracker-credentials.txt

The file records the RT sign in URL (http://<instance-public-ip>/), the administrator user (root) and this instance's unique RT_ADMIN_PASSWORD. RT ships no other default login.

Step 4 - Verify the stack and its security model from the command line

Confirm PostgreSQL and Apache are both running:

for s in postgresql apache2; do printf '%s: %s\n' "$s" "$(systemctl is-active "$s")"; done

Confirm the RT login page answers on port 80 (RT serves its login page at / and returns HTTP 200 when unauthenticated, which is the documented health target):

curl -s -o /dev/null -w 'RT login page over :80 -> HTTP %{http_code}\n' http://127.0.0.1/

Confirm PostgreSQL is bound to the loopback interface only and is not exposed on a host port:

PG=$(ss -tln | grep -cE '0\.0\.0\.0:5432|\[::\]:5432' || true)
[ "${PG:-0}" -eq 0 ] && echo 'PostgreSQL is loopback-only (127.0.0.1:5432), not exposed' || echo 'WARNING: PostgreSQL is exposed on a host port'

Confirm the PostgreSQL cluster lives on the dedicated data volume, bind mounted onto /var/lib/postgresql:

findmnt -no SOURCE,TARGET,FSTYPE /data
findmnt -no SOURCE,TARGET,FSTYPE /var/lib/postgresql

Confirm the per instance administrator authenticates through the RT web login, and that a blank password and common weak guesses are rejected (this is the same round trip the build's security gate runs):

sudo /usr/local/sbin/request-tracker-cred-roundtrip.sh

Confirm the installed RT version:

dpkg-query -W -f='${Version}\n' request-tracker5

Step 5 - Sign in to the web UI

Open http://<instance-public-ip>/ in a browser. RT presents its sign in page.

The Request Tracker login page served over HTTP on port 80

Sign in as root with the RT_ADMIN_PASSWORD from Step 3. RT opens on the RT at a glance homepage dashboard, showing the tickets you own, the newest unowned tickets, the queue list and a quick ticket creation panel.

The RT at a glance homepage dashboard with the ticket queues and quick creation panel

RT sets its session cookie without the secure flag on this image because the appliance serves plain HTTP on port 80. If you front RT with TLS (for example an Application Load Balancer or your own reverse proxy), set $WebSecureCookies back to 1 in /etc/request-tracker5/RT_SiteConfig.d/91-cloudimg-web.pm and restart Apache.

Step 6 - Create and work tickets

Use Search to list and filter tickets in a queue by status, owner, priority and more. Every column sorts and filters, and results can be bulk updated, charted or exported.

The RT ticket search results listing tickets by status, owner and priority

Click Create new ticket to raise a request in a queue. Set the requestor, subject, priority and owner, write the description in the rich text editor, and attach files.

The RT create a new ticket form with requestor, subject, message editor and queue basics

Open a ticket to work it. The Display view shows the ticket metadata, the people involved, the dates, links to other tickets, and the full history of correspondence and comments, with actions to reply, comment, take ownership, set status and resolve.

A Request Tracker ticket detail view showing metadata, people, dates and actions

Step 7 - Administer queues, users and workflow

The Admin menu is where you configure RT. Create and edit queues, define custom fields, manage users, groups and rights, and build scrips (RT's automation rules) that fire on ticket events to send mail, change status or run custom logic.

The RT admin queues page listing the configured queues

To take RT into production, create your own queues for each team, add users and grant rights through groups, and configure inbound and outbound email so requesters can open and reply to tickets by email as well as through the self service portal.

Step 8 - Data volume and backups

The bundled PostgreSQL cluster, and therefore every ticket, attachment, transaction, queue and user account, lives on the dedicated data volume:

df -h /var/lib/postgresql | tail -1

Because the ticket database is on its own EBS volume, you can grow it independently of the OS disk as your ticket history accumulates, and snapshot it with EBS snapshots or AWS Backup for point in time recovery. For a logical backup, dump the database on the instance with the standard PostgreSQL tooling as the postgres user.

Security model

  • No default or shared credentials. RT's well known default root and password login is never shipped. A unique administrator password, PostgreSQL role password and RT database secret are generated on this instance's first boot and written only to the root owned /root/request-tracker-credentials.txt.
  • Correct instance URL. First boot sets RT's $WebDomain to this instance's public address, so ticket links, self service URLs and cookies are correct and never point at a build time address.
  • Network isolation. PostgreSQL binds to the loopback interface only and is never published on a host port; only Apache on port 80 is exposed. The security group opens ports 22 and 80.
  • Dedicated data volume. The PostgreSQL cluster is bind mounted onto a separate EBS disk, keeping all customer data off the OS disk and independently resizable.
  • Plain HTTP by default. The appliance serves HTTP on port 80. For production, terminate TLS at a load balancer or your own reverse proxy, point RT's web domain at your hostname, and re-enable $WebSecureCookies.

Troubleshooting

  • The web UI does not load. Confirm Apache and PostgreSQL are active with systemctl status apache2 postgresql, and that first boot completed: sudo systemctl status request-tracker-firstboot.service and ls /var/lib/cloudimg/request-tracker-firstboot.done.
  • You cannot sign in. Re-read the password with sudo cat /root/request-tracker-credentials.txt; the user is root. If you have fronted RT with TLS, ensure $WebSecureCookies matches your scheme.
  • Ticket links point at the wrong address. Set $WebDomain (and, behind TLS, $WebPort/$WebSecureCookies) in /etc/request-tracker5/RT_SiteConfig.d/91-cloudimg-web.pm and run sudo systemctl restart apache2.
  • Email intake. RT can accept mail to open and reply to tickets; configure a mail transport (for example fetchmail or an SMTP relay) to pipe mail into rt-mailgate.

Support

cloudimg provides 24/7 technical support for this product by email and live chat at support@cloudimg.co.uk. We help with deployment, configuring queues, custom fields, scrips and workflow, wiring up inbound and outbound email, reverse proxy termination with your own domain and certificate, and backup planning for your ticket database.