temBoard on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of temBoard on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images.

temBoard is Dalibo's PostgreSQL monitoring and remote-administration console. Where most monitoring tools stop at drawing charts, temBoard also acts on your databases: it lists live sessions and terminates them, edits postgresql.conf and reloads the cluster, schedules VACUUM and ANALYZE, and surfaces query performance from pg_stat_statements.

This image bundles the complete appliance on a single virtual machine:

• temBoard 10.0.0 server — the web console on TCP 8888 (HTTPS)
• PostgreSQL 16 — serving as both the temBoard repository database and the first monitored instance
• temBoard 10.0.0 agent — installed beside that PostgreSQL and registered automatically

The appliance is self-demonstrating. The bundled PostgreSQL is registered as temBoard's first managed instance at first boot, so the console begins collecting real metrics immediately. Sign in a few minutes later and the dashboard is already drawing live charts — load average, CPU, transactions per second, cache hit ratio, sessions — with no configuration at all. You then install agents beside your own PostgreSQL servers and register them.

What is included:

• temBoard 10.0.0 server and agent (PostgreSQL Licence), installed from the official Dalibo Labs .deb packages and SHA256-verified
• PostgreSQL 16 with pg_stat_statements enabled, tuned for a 2 vCPU / 4 GiB virtual machine
• A first-boot service that generates every credential and key uniquely per virtual machine
• A shipped self-test that proves monitoring and administration actually work end to end

The three services, the installed versions, and the only three listening ports.

Security model

temBoard is remote-administration software. Through its agent it can terminate database backends and rewrite PostgreSQL configuration, so this image treats the agent as a privileged control plane rather than as another web service:

• The web console on TCP 8888 is the only thing reachable from the network.
• The agent binds 127.0.0.1:2345 only, and is additionally fenced with systemd IPAddressDeny=any / IPAddressAllow=localhost, so the kernel refuses non-loopback traffic to it even if its configuration were changed.
• PostgreSQL binds 127.0.0.1 only and is fenced the same way. The repository database is never an open port.
• No default credential ships. temBoard's documented admin / admin login is replaced with a unique 48-character password on first boot, and the stock credential is rejected. The session signing secret, the repository password, the UI-to-agent RSA signing key pair and the TLS certificate are all generated per virtual machine.

Prerequisites

• An Azure subscription with permission to create virtual machines
• An SSH key pair for administrative access
• A network security group allowing inbound TCP 22 (SSH) and 8888 (temBoard console) from your own address ranges
• Recommended size: Standard_B2s (2 vCPU, 4 GiB) or larger

Step 1: Deploy from the Azure Portal

1. In the Azure Portal, choose Create a resource and search for temBoard on Ubuntu 24.04 LTS by cloudimg.
2. Select the offer and click Create.
3. Choose your subscription, resource group and region.
4. Set the virtual machine size to Standard_B2s or larger.
5. Under Administrator account, select SSH public key and supply your key. The admin username is azureuser.
6. Under Inbound port rules, allow SSH (22) and Custom (8888).
7. Review and create.

Step 2: Deploy from the Azure CLI

# Create a resource group
az group create --name temboard-rg --location eastus

# Create the virtual machine from the cloudimg offer
az vm create \
  --resource-group temboard-rg \
  --name temboard-vm \
  --image cloudimg:temboard-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

# Open the console port
az vm open-port --resource-group temboard-rg --name temboard-vm --port 8888 --priority 1010

# Retrieve the public IP address of the new virtual machine
az vm show -d --resource-group temboard-rg --name temboard-vm --query publicIps -o tsv

Step 3: Connect via SSH

ssh azureuser@<vm-ip>

Step 4: Verify the Services

Three services make up the appliance. All three should report active:

systemctl is-active postgresql@16-main temboard temboard-agent@16-main

Expected output:

active
active
active

Confirm the installed versions:

temboard --version
temboard-agent --version

Step 5: Confirm Only the Console Is Exposed

The console is the only service that should answer from outside the machine. Check what is actually listening:

ss -tlnH | grep -E ':(8888|2345|5432) ' | awk '{printf "%-8s %-24s\n", $1, $4}'

Expected output — note that only 8888 is bound to a wildcard address:

LISTEN   0.0.0.0:8888
LISTEN   127.0.0.1:2345
LISTEN   127.0.0.1:5432

Prove the agent is genuinely unreachable off-host:

IP=$(hostname -I | awk '{print $1}')
curl -sk -m 6 -o /dev/null -w 'agent from off-host: HTTP %{http_code}\n' "https://$IP:2345/discover" || echo "connection refused — agent is host-local"

The kernel-level fence is independent of the application configuration:

systemctl show temboard-agent@16-main.service -p IPAddressDeny -p IPAddressAllow

The stock credential is rejected, the agent is unreachable off-host, and the fail-closed secret guard reports clean.

Step 6: Retrieve the Admin Password

Every virtual machine generates its own credentials on first boot:

sudo cat /stage/scripts/temboard-credentials.log

This file is 0600 root:root and contains the console URL, the admin username and password, and the repository database credentials.

Step 7: Run the Shipped Self-Test

The image ships an end-to-end self-test. It does not merely check that the service is up — it generates real database activity, proves monitoring data accumulates and keeps growing, and then performs a genuine administration action:

sudo /usr/local/sbin/temboard-selftest.sh

It takes about four minutes because it deliberately samples the metric row count across a collection interval to prove collection is live rather than a single stale batch.

The self-test proves the stock credential is refused, monitoring rows grow across a sampling interval, and a backend is terminated through the console and confirmed gone from pg_stat_activity.

Step 8: Inspect the Monitoring Data

The repository database holds the collected metrics. Confirm the bundled instance is registered:

sudo -u postgres psql -d temboard -c "SELECT substring(hostname,1,28) AS hostname, agent_address, agent_port FROM application.instances"

Confirm samples are accumulating and are recent:

sudo -u postgres psql -d temboard -c "SELECT count(*) AS samples, max(datetime) AS newest FROM monitoring.metric_sessions_current"

Confirm the collector is healthy:

sudo -u postgres psql -d temboard -c "SELECT status, last_pull, last_insert FROM monitoring.collector_status"

The registered instance, accumulated metric samples, and a healthy collector — all in the bundled repository database.

Step 9: First Login

Open https://<vm-ip>:8888/ in a browser. The console serves a self-signed certificate generated on this virtual machine's first boot, so your browser will warn on first visit — accept it, or put a trusted certificate in front (Step 15).

Sign in as admin with the password from Step 6.

The temBoard sign-in page. The documented default password does not work on this image.

After signing in you land on the instance inventory, already showing the bundled PostgreSQL:

The bundled PostgreSQL 16 instance, registered automatically at first boot.

Step 10: The Instance Dashboard

Click the instance to open its dashboard — live gauges for CPU, memory, cache hit ratio and sessions, with load average and transactions-per-second charts alongside a full alerting status grid:

Live figures within minutes of first boot, with no configuration.

Step 11: Historical Monitoring

The Monitoring tab plots the metrics accumulated in the repository. Use the time-range selector at the top right — on a freshly booted machine, choose Last 1 hour so the available history fills the chart:

Load average and CPU usage plotted from real collected samples.

Metrics are retained for 90 days on this image (temBoard's own default is 730 days, which grows without bound on a single-disk appliance). Query statistics are retained for 7 days. To change these, edit /etc/temboard/temboard.conf:

sudo grep -A2 '^\[monitoring\]' /etc/temboard/temboard.conf

Step 12: Live Activity and Session Control

The Activity tab is where temBoard stops being a dashboard and becomes an administration console. It lists running, waiting and blocking backends, and lets you select any of them and click Terminate.

To see it work, open a long-running query in another SSH session:

sudo -u postgres psql -d postgres -c "SELECT pg_sleep(90)"

Then reload the Activity tab — the backend appears in the Running list:

Live backends with CPU, memory and I/O per session. Select one and click Terminate to end it.

Step 13: Configuration Editing

The Configuration tab reads and writes the managed instance's postgresql.conf. Settings are grouped by category and searchable, and temBoard reloads or flags a restart as required:

Editable PostgreSQL settings, applied to the managed instance from the console.

Step 14: Monitor Your Own PostgreSQL Servers

The bundled instance demonstrates the product. To manage your real databases, install an agent beside each one. The agent must run on the same host as the PostgreSQL instance it manages — remote agents are not supported.

On the machine running your PostgreSQL server

Add the Dalibo Labs repository and install the agent:

echo "deb http://apt.dalibo.org/labs $(lsb_release -cs)-dalibo main" | sudo tee /etc/apt/sources.list.d/dalibo-labs.list
sudo curl -fsSL -o /etc/apt/trusted.gpg.d/dalibo-labs.gpg https://apt.dalibo.org/labs/debian-dalibo.gpg
sudo apt update && sudo apt install -y temboard-agent

Configure it against your temBoard console, where <vm-ip> is the address of your temBoard virtual machine:

sudo /usr/share/temboard-agent/auto_configure.sh https://<vm-ip>:8888

The script prints the agent's TCP port and configuration path. Fetch the console's signing key, then start the agent:

sudo -u postgres temboard-agent -c /etc/temboard-agent/16/main/temboard-agent.conf fetch-key
sudo systemctl enable --now temboard-agent@16-main

Register it with the console

Back on the temBoard virtual machine, where <private-ip> is the address of the machine running the agent:

sudo -u temboard temboard register-instance <private-ip> 2345 --environment default --if-not-exists

Alternatively use Settings → Instances → Add new instance in the web console.

Restrict the agent's exposure. An agent that manages a remote server has to be reachable by the console, so it cannot be loopback-only the way the bundled one is. Restrict its port to the console's address with a network security group rule or host firewall — never leave it open to the internet.

Step 15: Put TLS in Front (Production)

The console generates a self-signed certificate on first boot. For production, place a trusted certificate in front by pointing ssl_cert_file and ssl_key_file in /etc/temboard/temboard.conf at your own certificate and restarting the service, or terminate TLS at an Azure Application Gateway.

Step 16: Managing the Services

# Status
systemctl status temboard --no-pager

# Restart the console
sudo systemctl restart temboard

# Restart the agent for the bundled instance
sudo systemctl restart temboard-agent@16-main

# Console logs
sudo tail -n 50 /var/log/temboard/temboard.log

# Agent logs
sudo tail -n 50 /var/log/temboard-agent/temboard-agent.log

Both log files are rotated daily by /etc/logrotate.d/temboard, capped at 50 MB each with 14 generations kept, so logs cannot fill the disk.

Step 17: Troubleshooting

The console will not start. A fail-closed guard runs before the service and refuses to open the listener if any published default secret is still in effect. Run it directly to see what it objected to:

sudo /usr/local/sbin/temboard-secret-guard.sh

First boot did not complete. The console and agent are deliberately gated behind a marker that first boot writes, so neither starts until credentials exist:

journalctl -u temboard-firstboot.service -n 20 --no-pager
sudo tail -n 40 /var/log/cloudimg-firstboot.log 2>/dev/null || echo "no first-boot log yet"

The instance shows no data. The agent probes every 30 seconds and the console pulls every 60 seconds, so allow two or three minutes after boot. Check the collector:

sudo -u postgres psql -d temboard -c "SELECT status, last_pull, last_insert FROM monitoring.collector_status"

Step 18: Security Recommendations

• Restrict inbound 8888 and 22 to your own address ranges in the network security group.
• Replace the self-signed certificate with a trusted one before exposing the console broadly.
• Change the admin password after first login, and create individual accounts under Settings → Users rather than sharing the admin login — temBoard records who performed each administrative action.
• Leave the bundled agent and PostgreSQL bound to loopback. Nothing about normal operation requires exposing them.
• Keep the machine patched: sudo apt update && sudo apt upgrade.

Step 19: Support and Licensing

temBoard is distributed under the PostgreSQL Licence, a permissive BSD-style licence. PostgreSQL is distributed under the PostgreSQL Licence. There are no subscription or licence fees for the software in this image.

cloudimg provides 24/7 support for the image itself, its first-boot provisioning and its configuration.

Deploy on Azure

Find temBoard on Ubuntu 24.04 LTS in the Azure Marketplace.

Need Help?

Contact cloudimg support at support@cloudimg.co.uk.