Request Tracker

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting size. Choose a larger size for bigger or busier instances.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp for RT. RT serves plain HTTP on port 80, so for production terminate TLS in front of it with your own domain. The bundled PostgreSQL listens on 127.0.0.1 only, so port 5432 stays off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Request Tracker by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Review the dedicated data disk on the Disks tab, then select Review + create and Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:request-tracker-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name request-tracker \
  --image sac1647283583153:request-tracker-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open port 80 for RT:

az vm open-port --resource-group <your-rg> --name request-tracker --port 80

Step 3 - Confirm the services are running

SSH in as azureuser and confirm that PostgreSQL and Apache are both active. PostgreSQL listens only on 127.0.0.1:5432, while Apache serves RT on port 80.

systemctl is-active postgresql apache2 request-tracker-firstboot

ss -tln | grep -E ':80 |:5432 '

Step 4 - Retrieve the per-VM administrator password

Every VM generates its own RT administrator password on first boot. The password, the login user and the URL are written to a root-only credentials file. Read it with sudo:

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

Sign in to RT as user root with the RT_ADMIN_PASSWORD from this file. On the VM itself, run sudo -u postgres psql rt5 to reach the database directly over the local socket.

Step 5 - Sign in to Request Tracker

Browse to http://<vm-public-ip>/. The RT login page opens.

Sign in with username root and the password from Step 4.

Step 6 - Explore the RT dashboard

After you sign in, RT opens on RT at a glance, your home dashboard. It summarises the highest-priority tickets you own, the newest unowned tickets and your bookmarks, and it includes a quick ticket creation box.

The top menu gives you Search, Reports, an Admin area and the Create button.

Step 7 - Create and view a ticket

Click Create in the top menu, choose a queue such as General, give the ticket a subject and description, and submit it.

RT opens the ticket display page. There you can see the basics (status, priority, owner and queue), add correspondence and comments, set custom fields, and follow the full history.

Step 8 - Configure RT in the administration area

Open the Admin area to configure RT. From here you manage Users and their passwords, Groups and membership, Queues and their properties, Custom Fields, Custom Roles and Scrips. Scrips are the automation rules that drive RT's workflows.

Use this area to tailor RT to your team's process.

Step 9 - Confirm there are no known or default credentials

Request Tracker ships with a well-known default web login of root / password. The SecureAnyCloud image removes it. The root account is given a unique per-VM secret on first boot, and no known or blank password authenticates.

You can verify this with the built-in round-trip check. It confirms that the per-VM administrator signs in through RT's web login, and that a blank password and common weak guesses are all rejected:

sudo -u postgres psql -d rt5 -c "SELECT id, name FROM users WHERE name = 'root'"

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

Step 10 - Verify the stack and where your data lives

Confirm the RT version, the dedicated data disk and the installed database.

The entire PostgreSQL cluster lives on the data disk mounted at /data and bind-mounted onto /var/lib/postgresql. All of your tickets, transactions, attachments and users are kept separate from the operating system disk and travel with the VM:

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

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

sudo -u postgres psql -d rt5 -tAc "SELECT 'tickets = '||count(*) FROM tickets UNION ALL SELECT 'users = '||count(*) FROM users UNION ALL SELECT 'queues = '||count(*) FROM queues"

Adding your own domain and TLS

The appliance serves plain HTTP on port 80. RT builds its base URL into the links it puts in tickets and notifications, so for production you should set your own address.

Front RT with your domain and a TLS certificate. Then set $WebDomain to your public hostname in /etc/request-tracker5/RT_SiteConfig.d/91-sac-web.pm and restart Apache:

sudo systemctl restart apache2

You can terminate TLS with Azure Application Gateway, an nginx or Caddy reverse proxy, or a managed load balancer with a certificate for your domain.

Security notes

• Encrypt web traffic. RT serves plain HTTP on port 80. Beyond a trusted network, put it behind your own TLS-terminating reverse proxy or Azure Application Gateway with a certificate for your domain.
• Keep PostgreSQL private. The bundled PostgreSQL listens on 127.0.0.1 only and is never reachable from the network. Administer it through RT, or over SSH with sudo -u postgres psql rt5.
• Protect the credentials. The administrator password and the database secret are unique per VM, and no known or blank credential authenticates. Keep /root/request-tracker-credentials.txt protected, and change the password from within RT if you share access.
• Restrict the NSG. Allow inbound 80/tcp only from the networks that need RT.

Support

SecureAnyCloud maintains this image and provides 24/7 support. For help deploying or operating Request Tracker on Azure, contact us at secureanycloud.com.

Deploy on Azure

Launch Request Tracker on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Prerequisites

You need 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.

Configure the security group to allow inbound 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. RT comes up within a couple of minutes of first boot, after the instance has generated its unique secrets and set RT's web domain to its own 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

Confirm that PostgreSQL and Apache are both running:

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

Confirm that 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 that 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 that 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 that 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 that 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.

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

This image sets RT's session cookie without the secure flag, because the appliance serves plain HTTP on port 80. If you front RT with TLS, for example with an Application Load Balancer or your own reverse proxy, set $WebSecureCookies back to 1 in /etc/request-tracker5/RT_SiteConfig.d/91-sac-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 you can bulk update, chart or export the results.

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.

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. You can reply, comment, take ownership, set the status and resolve the ticket from there.

Step 7 - Administer queues, users and workflow

Use the Admin menu to configure RT. Create and edit queues, define custom fields, and manage users, groups and rights. You can also build scrips, RT's automation rules, which fire on ticket events to send mail, change status or run custom logic.

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

Step 8 - Check the data volume and plan 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. 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, and the security group opens ports 22 and 80.
• Dedicated data volume. The PostgreSQL cluster is bind-mounted onto a separate EBS disk, which keeps 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 that Apache and PostgreSQL are active with systemctl status apache2 postgresql. Then confirm that first boot completed with sudo systemctl status request-tracker-firstboot.service and ls /var/lib/sac/data/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, make sure $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-sac-web.pm, then run sudo systemctl restart apache2.
• Email intake does not work. 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

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

Deploy on AWS

Launch Request Tracker with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com