openMAINT

In the Azure portal, search the Marketplace for openMAINT on Ubuntu 24.04 LTS by SecureAnyCloud and choose Create. Pick Standard_B2ms. Allow inbound 443, 80 and 22 on the network security group.

Leave everything else at its default.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:openmaint-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-resource-group \
  --name my-openmaint \
  --image sac1647283583153:openmaint-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
az vm open-port --resource-group my-resource-group --name my-openmaint --port 443 --priority 1001
az vm open-port --resource-group my-resource-group --name my-openmaint --port 80 --priority 1002

Connect to the VM over SSH:

ssh azureuser@<vm-ip>

First boot generates this VM's secrets, issues its HTTPS certificate and then starts the web tier. Allow three to five minutes after launch.

Until first boot completes, the web tier deliberately stays closed. An appliance whose provisioning failed should be unreachable, not half-configured. Check the services:

systemctl is-active postgresql openmaint-tomcat nginx

Expected output:

active active active

Only SSH and HTTPS are reachable from outside the VM. Tomcat and PostgreSQL stay on loopback. Confirm the listeners:

ss -lntH | awk '{print $4}' | grep -vE '^(127\.|\[::1\]|\[::ffff:127\.)' | sed -E 's/.*:([0-9]+)$/\1/' | sort -un | paste -sd, -

Expected output:

22,80,443

Every secret on this VM is unique to it. First boot writes them to a file that only root can read. Read it as root:

sudo cat /root/openmaint-credentials.txt

The file lists the sign-in URL, the administrator username and password, and the database credentials. Use the administrator password to sign in.

sudo stat -c '%a %U:%G' /root/openmaint-credentials.txt

Expected output:

600 root:root

To confirm that first boot ran on this VM, check the sentinel file. It carries the timestamp of the boot that created it, not of the image build:

sudo cat /var/lib/sac/data/openmaint-firstboot.done

openMAINT keeps its externally visible address in a database row, Parameter.Server-URL, and builds notification and email links from it.

This image rewrites that row from the VM's own address on every boot. An Azure public IP that changes across a stop and start is therefore picked up automatically. Read the current value:

sudo -u postgres psql -d openmaint -tAc "SELECT \"Value\" FROM ONLY \"Parameter\" WHERE \"Code\"='Server-URL' AND \"Status\"='A'"

This prints https://<your-vm-ip>/openmaint.

Open the following address in a browser:

https://<vm-ip>/openmaint/ui/

Your browser warns about the self-signed certificate until you install your own (Step 11). Sign in with the username admin and the password from Step 5.

The image ships the openMAINT project's own sample estate, so there is real data to explore immediately. In the navigation, choose Facilities and assets > Locations > Building.

Click any row to open the record. Each asset carries its general data, its location data, and tabs for notes, relations, history, emails and attachments. Shortcuts lead to its building dossier and service status.

To create your own record, use Add card Building on the register toolbar. The same pattern applies to every class: floors and rooms under Locations, plants, systems and devices under Elements, and the maintenance registers under Maintenance management.

openMAINT ships an unauthenticated boot API so that a fresh instance can be configured from a browser. One endpoint rewrites the database connection. On this image the database is created at build time, and the whole subtree is refused at the web server. Check it yourself:

ADDR=$(hostname -I | awk '{print $1}') for u in /openmaint/services/rest/v3/boot/status /openmaint/services/rest/v3/boot/database/configure /openmaint/WEB-INF/conf/database.conf; do printf '%-55s -> HTTP ' "$u" curl -sk -o /dev/null -w '%{http_code}\n' -m 15 -H "Host: $ADDR" "https://127.0.0.1$u" done

Expected output:

/openmaint/services/rest/v3/boot/status -> HTTP 404 /openmaint/services/rest/v3/boot/database/configure -> HTTP 404 /openmaint/WEB-INF/conf/database.conf -> HTTP 404

The application itself is unaffected. Only the provisioning surface is closed:

curl -sk -o /dev/null -w 'the application -> HTTP %{http_code}\n' -m 20 -H "Host: $(hostname -I | awk '{print $1}')" https://127.0.0.1/openmaint/ui/

Expected output:

the application -> HTTP 200

The openMAINT project's database dumps seed five enabled accounts, and its legacy password format is reversible. All five passwords are therefore recoverable by anyone who downloads the distribution.

On this image every one of them is rotated, and demouser, guest and the vendor account are disabled outright. Confirm that none of them works:

ADDR=$(hostname -I | awk '{print $1}') SESS="https://127.0.0.1/openmaint/services/rest/v3/sessions" for pair in admin:admin demouser:demouser guest:guest scheduler:scheduler tecnoteca:16manzoni; do u="${pair%%:*}"; p="${pair#*:}" printf '%-11s %-12s -> HTTP ' "$u" "$p" curl -sk -o /dev/null -w '%{http_code}\n' -m 20 -H "Host: $ADDR" -H 'Content-Type: application/json' \
  --data "{\"username\":\"$u\",\"password\":\"$p\",\"scope\":\"service\"}" "$SESS" sleep 3 done

Every line returns 401.

The sleep 3 matters. openMAINT answers rapid repeated sign-in attempts with 404 rather than 401. Without a pause between attempts, the later lines report a throttle response instead of a real rejection.

Point a DNS A record at the VM's public IP, then replace the self-signed certificate. The nginx site file is /etc/nginx/sites-available/sac-openmaint. The certificate paths are /etc/ssl/openmaint/openmaint.crt and /etc/ssl/openmaint/openmaint.key.

To use Let's Encrypt, install certbot and issue a certificate for your domain:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d openmaint.your-domain.example

After you change the address, update the platform URL so that notification links stay correct:

sudo -u postgres psql -d openmaint -c "UPDATE \"Parameter\" SET \"Value\" = 'https://openmaint.your-domain.example/openmaint' WHERE \"Code\" = 'Server-URL' AND \"Status\" = 'A';"

openMAINT runs a job engine inside the application and records every execution. The three maintenance jobs it ships (the preventive maintenance generator, the advance scheduler and the process delay notifier) run daily in the early morning. List them:

sudo -u postgres psql -d openmaint -tAF'|' -c "SELECT \"Code\",\"Enabled\",\"Config\"->>'cronExpression' FROM ONLY \"_Job\" WHERE \"Status\"='A' AND \"Enabled\"=true ORDER BY 1"

To confirm that the jobs are executing, check the run history:

sudo -u postgres psql -d openmaint -tAF'|' -c "SELECT \"Job\",\"JobStatus\",\"Timestamp\" FROM ONLY \"_JobRun\" ORDER BY \"Timestamp\" DESC LIMIT 5"

This image is the open-source openMAINT distribution. PAT Srl also sells an annual subscription that adds components which are not part of the AGPL release, notably the Self-Service Portal, the Advanced Connector and the plugin-backed dashboards.

This has one visible consequence. A few entries in the Maintenance management menu (Preventive planner, Preventive maint. calendar and the Corrective maintenance dashboard) are plugin pages. No plugins are installed on this image (/services/rest/v4/system/plugins reports none), so those pages stay on Loading... and never render.

This is upstream behaviour for the open-source distribution, not a fault in this image. Use the class registers under Facilities and assets and Maintenance management instead. They hold the same data.

The image applies the following controls:

• Only SSH (22) and HTTPS (443) are reachable from outside the VM. Port 80 issues a permanent redirect to HTTPS and serves nothing else
• Tomcat listens on 127.0.0.1:8080 only. The AJP connector is removed from server.xml entirely and the Tomcat shutdown port is disabled
• PostgreSQL listens on 127.0.0.1 only
• Every secret is generated on this VM's first boot and written to a root-only file. Passwords are stored with the platform's own salted hash, not its reversible legacy format
• The graphical setup wizard is never run and the unauthenticated boot API is refused at the web server
• PermitRootLogin and PasswordAuthentication are both disabled in sshd

Everything openMAINT stores lives in the PostgreSQL database and the attachments directory. Take a database dump with the product's own tooling or with PostgreSQL's:

sudo -u postgres pg_dump -Fc openmaint > /var/backups/openmaint-$(date +%F).dump

The database's data directory is on a dedicated managed disk mounted at /var/lib/postgresql. You can also snapshot that disk in Azure independently of the OS disk.

unattended-upgrades applies Ubuntu security updates automatically. To move to a later openMAINT release, follow the project's own upgrade procedure with the shipped command-line tool at /opt/openmaint-tomcat/webapps/openmaint/cmdbuild.sh. Take a database backup first.

To check which version you are on, run:

cat /opt/openmaint-tomcat/webapps/openmaint/WEB-INF/classes/org/cmdbuild/version.properties

Expected output:

org.cmdbuild.version=4.2.0 org.cmdbuild.vert.name=openMAINT org.cmdbuild.vert.version=2.4.2