Pandora FMS Community on Ubuntu 24.04 on Azure User Guide

Overview

Pandora FMS Community is a mature, flexible open source monitoring platform that unifies server, network, application and log monitoring in a single web console. A Perl monitoring server collects metrics from agents installed on your hosts and from remote checks such as ICMP and SNMP against network devices, stores everything in a database, and drives alerting, reporting, inventory and network topology maps. The cloudimg image ships Pandora FMS Community (Pandora Open 1.0.0) as a complete all in one appliance on a hardened, fully patched Ubuntu 24.04 LTS base: the web console served by Apache and PHP 8.3 FPM, the Perl pandora_server and tentacle_serverd data server, a bundled local MariaDB, and a self monitoring agent so live host metrics and server status are visible the moment you first sign in. The install wizard is pre completed and locked, MariaDB listens only on the loopback interface, and a unique administrator password is generated on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

• Pandora FMS Community 1.0.0 web console served by Apache and PHP 8.3 FPM, managed by systemd
• The Perl pandora_server monitoring server and tentacle_serverd agent data server
• A bundled self monitoring agent (pandora_agent_daemon) reporting to the local Tentacle
• A bundled MariaDB server holding the Pandora database, already installed and ready
• The install wizard pre completed and locked, so no setup wizard is ever exposed
• A per VM administrator password generated on first boot and recorded in a root only file
• No shipped default login: the well known admin / pandora default is never shipped; the password ships rotated to a discarded random and the real per VM password is set on first boot
• MariaDB bound to 127.0.0.1 only, never exposed to the network
• A host firewall (ufw) that default denies inbound and allows only SSH and the web console
• apache2, php8.3-fpm, mariadb, pandora_server, tentacle_serverd and pandora_agent_daemon as enabled systemd units
• An unauthenticated /healthz endpoint for Azure Load Balancer health probes
• 24/7 cloudimg support

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 a sensible starting point that gives the Apache, PHP, MariaDB and Perl monitoring server room to run comfortably; step up to a larger size as you add monitored hosts. NSG inbound: allow 22/tcp from your management network and 80/tcp for the console (443/tcp if you terminate TLS on the VM). The bundled MariaDB is never exposed: it listens on 127.0.0.1 only, so port 3306 stays off the network. The Tentacle agent port 41121 is closed by default; open it only when you want external agents to report in (see Step 7).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Pandora FMS 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). Then Review + create then Create.

Step 2 - Deploy from the Azure CLI

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

Then open port 80 for the console:

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

Step 3 - Confirm the services are running

SSH in as azureuser and confirm Apache, PHP FPM, MariaDB, the monitoring server, the Tentacle server and the local agent are all active. MariaDB listens only on 127.0.0.1:3306, Apache serves the console on port 80, the Tentacle server listens on 41121, and the /healthz endpoint answers 200 for load balancer probes.

systemctl is-active apache2 php8.3-fpm mariadb pandora_server tentacle_serverd pandora_agent_daemon
curl -s -o /dev/null -w 'console -> %{http_code}\n' http://127.0.0.1/pandora_console/
curl -s -o /dev/null -w 'healthz -> %{http_code}\n' http://127.0.0.1/healthz
ss -tln | grep -E ':(80|3306|41121) '

Step 4 - Retrieve the per VM administrator password

On the first boot of every VM, a one shot service generates a unique Pandora administrator password and writes it, together with the console URL, to a root only file. The username is admin; the password is unique to this instance.

sudo cat /root/pandora-credentials.txt

Step 5 - Sign in to the console

Browse to http://<your-instance-ip>/pandora_console/ and sign in as admin with the password from Step 4.

After signing in you land on the console home, which already shows live data from the appliance's own self monitoring: server and database status, recent events and activity charts.

Step 6 - The monitoring server and self monitoring

Open Management > Servers > Manage servers to see the Pandora monitoring server threads (Data, Network, Discovery, Plugin, Inventory and Web servers), each reporting as running.

Open Operation > Monitoring > Views > Agent detail to see the appliance's own host being monitored: the self monitoring agent reports dozens of modules (CPU, memory, disk, processes and more) with a recent last contact time, proving the full monitoring pipeline is live end to end.

Step 7 - Onboard external agents (optional)

The appliance monitors itself out of the box. To monitor other hosts, install a Pandora FMS agent on each host and point it at this server's IP on port 41121, then open that port so agents can reach it:

az vm open-port --resource-group <your-rg> --name pandora --port 41121 --priority 1010

sudo ufw allow 41121/tcp

Agentless checks (ICMP, SNMP, TCP) against network devices need no inbound port at all and can be configured entirely from the console under Management > Discovery and the agent and module wizards.

Security model

Pandora FMS ships a well known default administrator credential (admin / pandora). This image never ships it. The build seeds a per build random password, the cleanup step rotates the shipped administrator password and API token to discarded random values, and on the first boot of every VM a fresh unique administrator password is generated and written to the root only credentials file. The check below proves the per VM administrator authenticates through the real web login form while the default, blank and common weak passwords are all rejected.

sudo bash /usr/local/sbin/pandora-cred-roundtrip.sh

The bundled MariaDB is bound to 127.0.0.1 only, the internal application to database password is generated per VM, and the host firewall default denies inbound traffic apart from SSH and the console.

Versions

php -v | head -1
mariadb --version
apache2 -v | head -1
systemctl is-active pandora-firstboot

Enabling HTTPS

For production use, put the console behind TLS. The simplest path is to add a DNS name for the instance and obtain a certificate with Certbot, or terminate TLS at an Azure Application Gateway or Load Balancer in front of the VM. If you terminate on the VM, allow 443/tcp in the NSG and sudo ufw allow 443/tcp, then enable the Apache SSL site.

Support

This image is backed by 24/7 cloudimg support. For help with deployment, agent onboarding, SNMP and network monitoring, alerting and reporting, upgrades, performance tuning or MariaDB administration, contact support@cloudimg.co.uk.