Rt
Applications Azure

Request Tracker on Ubuntu 24.04 on Azure User Guide

| Product: Request Tracker on Ubuntu 24.04 LTS on Azure

Overview

Request Tracker (RT) is a mature, enterprise grade open source ticketing platform from Best Practical, used to track requests, incidents and tasks through their whole lifecycle. It gives you queues, custom fields, approvals, service level reminders, a full rights and permission model, and a searchable history of every interaction, so teams can run help desks, IT service management, and operational and security workflows from one place. The cloudimg image ships RT 5 served by Apache with mod_perl on a hardened, fully patched Ubuntu 24.04 LTS base, together with a bundled local PostgreSQL server so the appliance is complete and useful on its own. RT is served on port 80. The bundled PostgreSQL listens only on the loopback interface (127.0.0.1:5432) and keeps its data on a dedicated Azure data disk. A unique administrator password, and a unique database secret, are generated on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

  • Request Tracker 5 served by Apache 2 with mod_perl (prefork), managed by systemd
  • A bundled PostgreSQL 16 server holding the RT database, already installed and initialised
  • RT served on :80, with the login page reachable at /
  • A per VM administrator password generated on first boot and recorded in a root only file
  • No shipped default login: RT's well known root / password default is replaced by a unique per VM secret, and no known or blank credential authenticates
  • A per VM PostgreSQL secret: the database password and the RT_SiteConfig database secret are also rotated on first boot, so nothing is baked into the image
  • PostgreSQL bound to 127.0.0.1 only, never exposed to the network
  • A dedicated Azure data disk carrying the entire PostgreSQL cluster, so all of your ticket data lives off the operating system disk
  • postgresql.service and apache2.service as enabled systemd units
  • 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point; size up for larger or busier instances. NSG inbound: allow 22/tcp from your management network and 80/tcp for RT. RT serves plain HTTP on port 80; for production, terminate TLS in front of it with your own domain. The bundled PostgreSQL is never exposed: it 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 cloudimg, and select Create. On Basics 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 Review + create then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name request-tracker \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open port 80 to 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 PostgreSQL and Apache are both active. Note that 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 '

The postgresql, apache2 and request-tracker-firstboot services reported active, with Apache listening on port 80 and PostgreSQL bound to loopback 127.0.0.1:5432

Step 4 - Retrieve the per VM administrator password

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

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

The per VM Request Tracker credentials file, showing the admin login user root, the generated password and the RT URL

You sign in to RT as user root with the RT_ADMIN_PASSWORD from this file. On the box itself you can also 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>/. You land on the RT login page. Sign in with username root and the password from Step 4.

The Request Tracker login page showing the username and password fields and the RT 5 version

Step 6 - The RT dashboard

Once signed in you land on RT at a glance, your home dashboard. It summarises the highest priority tickets you own, the newest unowned tickets and your bookmarks, with a quick ticket creation box, and the top menu gives you Search, Reports, an Admin area and the Create button.

The Request Tracker home dashboard, RT at a glance, showing the highest priority and newest unowned ticket panels and the quick ticket creation box

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. RT opens the ticket display page, where you can see the basics (status, priority, owner and queue), add correspondence and comments, set custom fields, and follow the full history.

A Request Tracker ticket display page showing the ticket metadata, the basics with status new and queue General, and the people section

Step 8 - 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 (the automation rules that drive RT's workflows). This is where you tailor RT to your team's process.

The Request Tracker administration area showing the Users, Groups, Queues, Custom Fields, Custom Roles and Scrips management sections

Step 9 - No known or default credentials

Request Tracker ships with a well known default web login of root / password. The cloudimg 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 prove this with the built in round-trip check, which confirms the per VM administrator signs in through RT's web login while 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

The RT root user present in the users table, and the round-trip check confirming the per VM administrator authenticates via the RT web login while a blank password and weak guesses are rejected

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 (bind mounted onto /var/lib/postgresql), so all of your tickets, transactions, attachments and users are kept separate from the operating system disk and ride 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"

The Request Tracker version 5.0.5, the ext4 data disk mounted at /data and bind mounted onto /var/lib/postgresql, and the ticket, user and queue counts from the database

Adding your own domain and TLS

The appliance serves plain HTTP on port 80, and RT bakes 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-cloudimg-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

  • RT serves plain HTTP on port 80. For anything beyond a trusted network, put it behind your own TLS terminating reverse proxy or Azure Application Gateway with a certificate for your domain.
  • 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.
  • 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 inbound 80/tcp in your NSG to the networks that need RT.

Support

This image is maintained by cloudimg with 24/7 support. If you need help deploying or operating Request Tracker on Azure, contact us at cloudimg.co.uk.