OTOBO Service Desk on Ubuntu 24.04 on Azure User Guide

Overview

OTOBO is an open source service desk and ticketing system for IT and service organisations, and the maintained community successor to OTRS after that project's community edition was discontinued. Requests arrive by email or through a self service portal, land in a queue, and are assigned to an agent or a team. From there the whole working life of a request is tracked in one place: the conversation thread, the owner, the state, the escalation clock, and every change made along the way.

Around that core sit service level agreements with response and solution times, standard templates and canned responses, dynamic fields and custom forms, a customer portal and knowledge base, process based tickets, statistics and reporting, a generic web service interface for integrations, and directory authentication so agents can sign in with credentials they already have.

The cloudimg image delivers OTOBO 11.0.18 on Ubuntu 24.04, served over HTTPS, with the browser install wizard already run and permanently closed, and every secret generated on the first boot of your VM. Backed by 24/7 cloudimg support.

What is included:

• OTOBO 11.0.18 at /opt/otobo, installed from the vendor's own release tarball and verified by SHA-256
• Apache 2.4 with mod_perl running OTOBO's PSGI application, bound to 127.0.0.1:8080 only
• nginx serving HTTPS on port 443 with a certificate generated for your VM; port 80 only redirects to HTTPS
• PostgreSQL 16 on the loopback address only, holding tickets, articles and attachments
• The OTOBO daemon for escalations, scheduled jobs and the generic agent, with a watchdog timer
• A ready made queue structure (Service Desk, Service Desk::Hardware), ticket types and a service, so you can start work immediately
• No default login: the administrator password, the database password and the TLS key are all generated on your VM's first boot and written to a root-only file
• The web installer is closed at the application level, not merely unlinked, so it stays closed even against an empty database
• Brute-force protection active on the sign-in form
• postgresql, apache2, nginx and otobo-daemon systemd services, enabled and active

OTOBO is a trademark of Rother OSS GmbH. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them. This image packages the unmodified open source software, which is distributed under the GNU General Public License v3.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2ms (2 vCPU, 8 GiB RAM) is the recommended size: OTOBO runs under mod_perl, where each Apache worker holds a resident copy of the application, so memory rather than CPU is the constraint. Choose a larger size for many concurrent agents or heavy reporting. Network security group inbound rules: 22/tcp from your management network, 443/tcp for the web interface, and optionally 80/tcp, which only redirects to HTTPS.

Step 1: Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for OTOBO Service Desk 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 HTTPS (443). Then select Review + create and Create.

Step 2: Deploy from the Azure CLI

Create the VM, open the ports the service desk needs, and read back the public address you will use for the rest of this guide:

az group create --name otobo-rg --location eastus

az vm create \
  --resource-group otobo-rg \
  --name otobo-vm \
  --image cloudimg:otobo-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

az vm open-port --resource-group otobo-rg --name otobo-vm --port 443 --priority 1001
az vm open-port --resource-group otobo-rg --name otobo-vm --port 80  --priority 1002

az vm list-ip-addresses --resource-group otobo-rg --name otobo-vm \
  --query "[0].virtualMachine.network.publicIpAddresses[0].ipAddress" -o tsv

Step 3: Confirm the stack is running

Connect over SSH as azureuser and check the four services. First boot takes about thirty seconds; until it completes, the web tier is deliberately held shut, so a connection refused on port 443 immediately after the VM starts is expected rather than a fault.

systemctl is-active postgresql apache2 nginx otobo-daemon

Every line must read active. You can also confirm which versions you are running:

cat /opt/otobo/RELEASE
sudo runuser -u postgres -- psql -tAc 'SHOW server_version'
nginx -v

Step 4: Check what is listening

Only SSH, HTTP and HTTPS are reachable from outside the VM. Apache and PostgreSQL are bound to the loopback address, so no request can reach the application without passing through nginx, which is where the request headers are normalised.

sudo ss -Hltnp

The image ships a checker that asserts the exact set rather than eyeballing it:

sudo /usr/local/sbin/otobo-port-check.sh

It prints PORTS_OK 22 80 443 and exits non-zero if anything else is listening off-box.

Step 5: Retrieve your administrator password

No password ships inside the image. On the first boot of your VM a one-shot service generates the administrator password, the database password and a TLS certificate unique to that instance, and writes them to a file readable only by root.

sudo cat /root/otobo-credentials.txt

You will see the sign-in URL, the administrator account root@localhost and its password, plus the database credentials. The file is mode 0600 and owned by root:

sudo ls -l /root/otobo-credentials.txt

Step 6: Sign in to the agent interface

Browse to https://<vm-public-ip>/otobo/index.pl and sign in with root@localhost and the password from the previous step. The certificate is self-signed and generated on your instance, so your browser will warn on first visit; Step 11 covers replacing it with a certificate for your own domain.

The install wizard has already been run, so you land directly on the agent interface rather than a setup screen.

OTOBO will show a banner advising you not to work in the superuser account. That is good advice and Step 7 follows it.

Step 7: Create your own agent account

root@localhost is the built-in administrator. Use it to create the accounts your team will actually work in, then keep it for administration only.

In the web interface choose Admin, then Agents, then Add agent. Fill in the name, a username and an email address, set a password, and save. Then open Admin → Groups → Agents (or Agents ↔ Groups) and give the new agent rw on the users group so they can see and work the queues.

You can do the same from the command line. --group adds the agent to that group with rw permission in the same step:

sudo runuser -u otobo -- /opt/otobo/bin/otobo.Console.pl Admin::User::Add \
  --user-name jdoe --first-name Jane --last-name Doe \
  --email-address jane.doe@servicedesk.test --group users

Addresses at example.com are rejected. OTOBO ships a CheckEmailInvalidAddress pattern that treats the reserved documentation domains as invalid, so jane.doe@example.com fails with Email address not valid. Use a real address for your organisation. You can review the rule under Admin → System configuration, searching for CheckEmailInvalidAddress.

Then set the password by piping it in, so it never appears on a command line, in ps output or in the system journal:

printf '%s\n' 'choose-a-strong-password' \
  | sudo runuser -u otobo -- /usr/local/sbin/otobo-set-password.pl jdoe

To change an existing agent's group permissions later, use Admin::Group::UserLink with --user-name, --group-name and a --permission of ro, move_into, create, owner, priority or rw.

Step 8: Work a ticket

The image ships with a Service Desk queue and a Service Desk::Hardware sub-queue. Choose Tickets, then Queue view, and select a queue from the list along the top. New instances start empty; the screenshots below are from a populated system so you can see what a working queue looks like.

Selecting a ticket opens it, showing the conversation thread, the ticket information panel and the actions available: lock it to yourself, change the priority or state, reply to the customer, add an internal note, or move it to another queue.

To raise a ticket yourself, choose Tickets → New phone ticket for a request that arrived by phone, or New email ticket to open a conversation outbound.

Step 9: Add queues, types and service levels

Everything that shapes how work flows is under Admin.

• Queues — one per team or work stream. Sub-queues use Parent::Child naming, as the shipped Service Desk::Hardware does.
• Service level agreements — response, update and solution times, with escalation when they are missed. Attach an SLA to a queue or to a service.
• Ticket types, priorities and states — the vocabulary your team works in.
• Dynamic fields — extra structured fields on tickets, such as an asset tag or a change window.
• Templates — canned responses and signatures, linked to the queues that use them.

Step 10: Receive tickets by email

A service desk normally receives most of its work by email. Under Admin → PostMaster mail accounts, add the mailbox OTOBO should collect from: choose IMAPS for a TLS connection, enter the host, the username and the password, and choose the queue new mail should land in. OTOBO's daemon polls the account and turns each message into a ticket, threading replies onto the existing ticket by its ticket number.

For outbound mail, set the sending address under Admin → Email addresses and the relay under Admin → System configuration, searching for SendmailModule. To send through an external SMTP relay, set SendmailModule to Kernel::System::Email::SMTPS and fill in the host, port and credentials.

Confirm the daemon that collects mail and runs escalations is alive:

sudo runuser -u otobo -- /opt/otobo/bin/otobo.Daemon.pl status

Step 11: Use your own domain and certificate

The shipped certificate is self-signed and generated for your VM's address. To use your own domain, point a DNS A record at the VM's public address, then install your certificate and key and tell OTOBO the new address.

Place your certificate chain and private key at /etc/otobo/tls/otobo.crt and /etc/otobo/tls/otobo.key, keeping the existing ownership and permissions:

sudo chown root:www-data /etc/otobo/tls/otobo.key
sudo chmod 0640 /etc/otobo/tls/otobo.key
sudo chmod 0644 /etc/otobo/tls/otobo.crt
sudo nginx -t && sudo systemctl reload nginx

Then update the address OTOBO uses when it builds links in notification emails:

sudo runuser -u otobo -- /opt/otobo/bin/otobo.Console.pl Admin::Config::Update \
  --setting-name FQDN --value <your-domain> --no-deploy
sudo runuser -u otobo -- /opt/otobo/bin/otobo.Console.pl Maint::Config::Rebuild

Step 12: Verify the security posture

The image ships a self-test that signs in through the real web front door with a browser-shaped request, confirms the session reaches the agent dashboard, and then proves that the published upstream default and a set of common weak passwords are all refused.

sudo /usr/local/sbin/otobo-verify-login.sh

It ends with OTOBO_CREDENTIAL_ROUNDTRIP_OK. OTOBO's own source seeds the root@localhost account with the password root; that credential is removed during the build and this check proves it is refused on your instance.

The web installer is also closed. It answers 403 at every spelling of its path, because SecureMode is set in Kernel/Config.pm itself rather than only in the database, which means it stays closed even if the database is empty:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/otobo/installer.pl

Step 13: Back up and restore

Everything a customer creates — tickets, the conversation threads and their attachments — lives in PostgreSQL, so a database dump plus the configuration is a complete backup.

sudo runuser -u postgres -- pg_dump -Fc otobo > /var/tmp/otobo-$(date +%F).dump
sudo tar czf /var/tmp/otobo-config-$(date +%F).tar.gz \
  /opt/otobo/Kernel/Config.pm /etc/otobo /etc/nginx/sites-available/otobo.conf

Copy both files off the VM. To restore onto a fresh instance, stop the application, restore the dump, and start it again:

sudo systemctl stop apache2 otobo-daemon
sudo runuser -u postgres -- pg_restore -d otobo --clean --if-exists /var/tmp/otobo-2026-09-20.dump
sudo systemctl start apache2 otobo-daemon

The restored database carries its original passwords, so put back the matching Kernel/Config.pm from the same backup.

Step 14: Keep the instance patched

Ubuntu security updates install automatically through unattended-upgrades. To apply operating system updates immediately:

sudo apt-get update && sudo apt-get -y dist-upgrade

OTOBO itself is upgraded from the vendor's release tarball. Back up first, then follow the upgrade instructions in the OTOBO manual for your target version, and afterwards rebuild the configuration and clear the cache:

sudo runuser -u otobo -- /opt/otobo/bin/otobo.Console.pl Maint::Config::Rebuild
sudo runuser -u otobo -- /opt/otobo/bin/otobo.Console.pl Maint::Cache::Delete

Step 15: Grow the disk as your ticket history grows

Tickets and their attachments are stored in the database on the operating system disk, which is 29 GiB. To give a busy service desk more room, resize the disk in Azure and then grow the filesystem:

df -h /

Stop the VM, increase the disk size in the Azure portal or with az disk update --size-gb, start the VM again, then confirm the new size and expand the partition and filesystem:

lsblk
sudo growpart /dev/sda 1
sudo resize2fs /dev/sda1

Troubleshooting

The web interface does not answer immediately after the VM starts. First boot generates the per-VM secrets before the web tier is allowed to serve. Wait for it to finish and check it succeeded:

systemctl is-active otobo-firstboot.service
sudo journalctl -u otobo-firstboot.service --no-pager | tail -20

A sign-in is rejected even with the right password. OTOBO blocks a username for a period after three failed attempts. Wait, or clear the block:

sudo runuser -u otobo -- /opt/otobo/bin/otobo.Console.pl Maint::Cache::Delete --type BannedLoginsAgent
sudo runuser -u otobo -- /opt/otobo/bin/otobo.Console.pl Maint::Cache::Delete --type FailedLoginsAgent

Check the application log for errors OTOBO recorded itself:

sudo runuser -u otobo -- /opt/otobo/bin/otobo.Console.pl Maint::Log::Print

Confirm OTOBO can reach its database:

sudo runuser -u otobo -- /opt/otobo/bin/otobo.Console.pl Maint::Database::Check

Web server errors are in the usual places:

sudo tail -40 /var/log/apache2/otobo-error.log
sudo journalctl -u nginx --no-pager | tail -20

Support

cloudimg provides 24/7 technical support for this image by email at support@cloudimg.co.uk and via live chat, covering deployment and configuration, inbound and outbound mail, queue and SLA design, dynamic fields, the generic web service interface, LDAP authentication, upgrades and PostgreSQL administration. Critical issues receive a one hour average response time.