openMAINT 2.4.2 on Ubuntu 24.04 on Azure User Guide

Overview

openMAINT is a full open source application for property and facility management, built on the CMDBuild platform by PAT Srl. It manages the built estate and everything in it: sites, complexes, buildings, floors and rooms; an asset and equipment register covering electrical, climate control, fire protection, security, sanitation, conveyor and telecommunications systems; preventive maintenance plans and corrective maintenance with work orders, checklists and service level agreements; energy meters and consumption; logistics, purchase orders, contracts and budgets; and a portal through which requesters and suppliers reach the maintenance office.

The cloudimg image delivers the official openMAINT 2.4.2 release, on CMDBuild core 4.2.0, fully installed on Ubuntu 24.04 LTS and served over HTTPS, with every per-VM secret generated on first boot — so a working facility management system is serving within minutes of launch. Backed by 24/7 cloudimg support.

openMAINT is free software published under the GNU Affero General Public License version 3. In accordance with section 7(b) of that licence the Appropriate Legal Notices are retained: the openMAINT logo and header remain displayed in the application, and this image is not white-labelled or re-skinned. openMAINT and CMDBuild are trademarks of PAT Srl; cloudimg is not affiliated with, endorsed by, or sponsored by PAT Srl. This image packages the upstream open source release with cloudimg's provisioning, hardening and support.

What is included:

• openMAINT 2.4.2 on CMDBuild core 4.2.0, deployed as an exploded web application under /opt/openmaint-tomcat/webapps/openmaint
• Apache Tomcat 10.1 on OpenJDK 17, bound to 127.0.0.1:8080 only, behind nginx serving HTTPS at https://<vm-ip>/openmaint/ui/; port 80 only ever redirects to HTTPS and serves no content of its own
• PostgreSQL 17 with the PostGIS spatial extension, bound to 127.0.0.1 only, with its data directory on a dedicated managed disk mounted at /var/lib/postgresql
• The openMAINT sample estate loaded, so the application is explorable from your first sign-in rather than an empty shell
• A per-VM administrator password, application database password, PostgreSQL superuser password and HTTPS certificate, all generated on first boot and written to a root-only file — no default, shared or published credential ships in the image
• The setup surface is closed. openMAINT ships a graphical installation wizard and an unauthenticated boot API that can reconfigure the database connection. The database is created at build time with the product's own command line tool, the wizard is never run, and the web server refuses the entire /services/rest/v*/boot/ subtree
• All five seeded accounts neutralised. The upstream database seeds admin, demouser, guest, scheduler and a vendor account, all enabled. On this image every one of them is rotated, and the three demonstration and vendor accounts are disabled outright
• 24/7 cloudimg support

Prerequisites

• An Azure subscription and the Azure CLI, or access to the Azure portal
• A network security group allowing inbound 443 (and 80, which only redirects) and 22 for administration
• A VM size with at least 8 GiB of memory. Standard_B2ms is the recommended size: openMAINT is a Java application running alongside PostgreSQL

Step 1: Deploy from the Azure Marketplace

In the Azure portal, search the Marketplace for openMAINT on Ubuntu 24.04 LTS by cloudimg, choose Create, pick Standard_B2ms, and allow inbound 443, 80 and 22 on the network security group. Everything else can stay at its default.

Step 2: Deploy from the Azure CLI

az vm create \
  --resource-group my-resource-group \
  --name my-openmaint \
  --image cloudimg: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

Step 3: Connect to your VM

ssh azureuser@<vm-ip>

Step 4: Confirm the stack is running

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.

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:

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

Step 5: Retrieve the first-boot credentials

Every secret on this VM is unique to it. They are written to a file readable only by root:

sudo cat /root/openmaint-credentials.txt

You will see the sign-in URL, the administrator username and password, and the database credentials. The administrator password is the one you need to sign in.

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

Expected output:

600 root:root

You can confirm first boot really ran on this VM — the sentinel carries the timestamp of the boot that created it, not of the image build:

sudo cat /var/lib/cloudimg/openmaint-firstboot.done

Step 6: Understand the platform URL

openMAINT keeps its externally visible address in a database row, Parameter.Server-URL, and builds notification and e-mail links from it. This image rewrites that row from the VM's own address on every boot, so an Azure public IP that changes across a stop and start is picked up automatically:

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.

Step 7: Sign in

Browse to:

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

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

Step 8: Explore the building and asset registers

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

Click any row to open the record. Each asset carries its general data, location data, and tabs for notes, relations, history, e-mails and attachments, with shortcuts 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.

Step 9: Confirm the setup API is not exposed

openMAINT ships an unauthenticated boot API so a fresh instance can be configured from a browser — including an endpoint that rewrites the database connection. On this image the database is created at build time and that whole subtree is refused at the web server. You can 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

Step 10: No default credentials

The openMAINT project's database dumps seed five enabled accounts and its legacy password format is reversible, so all five passwords are 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. You can confirm 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, so without a pause between them the later lines report a throttle response instead of a real rejection.

Step 11: Use a domain name and your own certificate

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/cloudimg-openmaint and 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 changing the address, update the platform URL so 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';"

Step 12: Scheduled jobs

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:

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 see that jobs really are executing, look at the run history:

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

Step 13: What this image is, and what it is not

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 and the Advanced Connector, and the plugin-backed dashboards.

That has one visible consequence worth knowing about: a few entries in the Maintenance management menu (Preventive planner, Preventive maint. calendar, and the Corrective maintenance dashboard) are plugin pages. With no plugins installed — /services/rest/v4/system/plugins reports none on this image — those pages sit on Loading… and never render. That is upstream behaviour for the open source distribution, not a fault in this image. The class registers under Facilities and assets and Maintenance management are the supported path and hold the same data.

Step 14: Security model

• 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

Step 15: Back up your data

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, so you can also snapshot that disk in Azure independently of the OS disk.

Step 16: Maintenance and upgrades

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

Check which version you are on at any time:

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

Support

cloudimg provides 24/7 support for this image by email at support@cloudimg.co.uk and via live chat. We help with deployment, retrieving the first-boot credentials, signing in, user and role administration, the data model, preventive maintenance configuration, the job scheduler, custom domains and certificates, PostgreSQL tuning, backups and upgrades.

Questions about openMAINT feature behaviour are answered on a best-effort basis and, where appropriate, directed to the project's documentation at docs.cmdbuild.org and openmaint.org.