openCRX 6.0.3 on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and use of openCRX 6.0.3 on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images.

openCRX (BSD-3-Clause) is one of the leading enterprise class, open source CRM and groupware suites. It manages accounts and contacts, activities and tickets, the sales pipeline (leads, opportunities, quotes, sales orders), products and price lists, and groupware such as calendars, email and CardDAV/CalDAV. It is built on the openMDX model driven framework and runs as a full Jakarta EE application on Apache TomEE.

This image runs the official prebuilt openCRX server distribution — Apache TomEE Plus 10.1.2 hosting the opencrx-core-CRX enterprise application — on Java 21, which openCRX 6.x requires. Rather than the bundled in-memory database, the datastore is a local PostgreSQL 16: openCRX ships no static SQL (its schema is generated from the openMDX model), so the schema is created on PostgreSQL by openCRX's own tooling and the standard security segment with its bootstrap accounts is migrated in. A freshly launched VM therefore boots into a working, data backed CRM.

What is included:

• openCRX 6.0.3 running under systemd as opencrx.service (Apache TomEE Plus 10.1.2, Java 21) on port 8080
• PostgreSQL 16 as the datastore, running as postgresql.service on loopback 127.0.0.1
• The full openMDX web portal plus the REST, CardDAV, CalDAV, iCal and IMAP endpoints the distribution ships
• The standard openCRX security segment and its accounts migrated into PostgreSQL, so the Accounts view shows real data on first boot
• A per VM administrator password and PostgreSQL password generated on first boot; the administrator password is rotated in both of openCRX's security realms
• The JVM heap sized from the VM's memory on first boot, so the image runs honestly on a Standard_B2s and grows on a larger VM
• No swap in the image; a fully patched base with unattended security updates enabled

Deploying the VM

Launch the image from the Azure Marketplace as you would any other VM. The recommended size is Standard_B2ms (2 vCPU / 8 GiB); the shipped configuration also runs on Standard_B2s (2 vCPU / 4 GiB).

The web portal listens on TCP 8080. In the Azure network security group, open 8080 only to the client addresses that genuinely need it — never to the whole internet — and add 22 for SSH. PostgreSQL on 5432 is bound to loopback and is deliberately not exposed.

First boot

On the first boot of each VM, a one shot service runs before the CRM becomes reachable:

1. opencrx-firstboot.service generates a unique PostgreSQL role password and a unique openCRX administrator password, rotates the PostgreSQL crx role and the TomEE data source password, rotates the admin-Standard credential in both realms openCRX authenticates against (the database credential store and tomcat-users.xml), disables the guest login, then starts openCRX and asserts that the per VM administrator authenticates while every shipped default (admin-Standard, admin-Root, guest) is rejected.

opencrx.service is gated on the first boot completing, so it never starts with build time secrets. Confirm the stack is up:

systemctl status --no-pager postgresql opencrx

Signing in to the web portal

Retrieve the generated credentials (root only):

sudo cat /root/opencrx-credentials.txt

You will see the administrator user (admin-Standard), a unique password, the unique database password and the portal URL.

Confirm the portal is serving:

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/opencrx-core-CRX/

A 200 means openCRX is up. Open the portal in your browser:

http://<vm-public-ip>:8080/opencrx-core-CRX/

Sign in with admin-Standard and the generated password. The shipped openCRX defaults (admin-Standard, admin-Root, guest, each with its login as password) are rotated and rejected.

After signing in you land on the openCRX home, which surfaces your alerts, work lists and activities alongside the full CRM module tree — Contacts, Support, Sales, Products and more.

Managing accounts and contacts

Choose Manage Accounts from the top menu, then All Accounts in the left panel. The grid lists the accounts held in the standard segment — contacts and account groups — served live from PostgreSQL. Because the standard security segment was migrated into the database at build time, a freshly launched VM already shows real account data rather than an empty shell.

Use New Contact to add people and Account Groups to organise them. Every account, contact and group you create is stored in PostgreSQL. You can confirm the account data directly through the REST endpoint:

curl -s -u "<OPENCRX_ADMIN_USER>:<OPENCRX_ADMIN_PASSWORD>" -H "Accept: application/xml" \
  "http://127.0.0.1:8080/opencrx-rest-CRX/org.opencrx.kernel.account1/provider/CRX/segment/Standard/account?size=5"

The response lists the migrated contacts and groups from the standard segment.

Working with activities, sales and products

Choose Manage Activities from the top menu to open the activity tracker — tickets, tasks and the Bugs + Features tracker the distribution ships. The Sales menu holds the pipeline (leads, opportunities, quotes and sales orders) and Products holds product definitions and price lists. Each module renders against the same live PostgreSQL datastore.

The datastore

openCRX ships no static SQL — its schema is generated from the openMDX model — so this image builds the schema on PostgreSQL by running openCRX's own DbSchemaUtils validation passes, then migrates the standard segment's bootstrap data with openCRX's own CopyDb tool. The result is a full openCRX schema on PostgreSQL:

   kind    | count
 ----------+-------
  tables   |   328
  views    |    96
  sequences|     2

The migrated standard segment holds the openCRX security accounts and groups, which is what the Accounts view renders:

Security notes

• No default login ships. openCRX's defaults exist in two realms simultaneously — a database credential store and tomcat-users.xml. First boot rotates the admin-Standard credential in both, removes guest/tomcat, and rotates the PostgreSQL role and data source passwords, then proves the per VM administrator authenticates and every default is rejected before writing the credentials file.
• The database is loopback only. PostgreSQL listens on 127.0.0.1; only the local openCRX server reaches it.
• Expose the portal narrowly. Open TCP 8080 only to the addresses that need it. For production, terminate TLS in front of openCRX (for example with a reverse proxy and a certificate for your own domain) rather than serving plain HTTP over the internet.
• Rotate the administrator password from the portal once you have signed in, and keep the root only /root/opencrx-credentials.txt protected.

Support

Every cloudimg image ships with a fully patched base, unattended security updates enabled, and 24/7 cloudimg support. If you need help deploying or operating openCRX, contact cloudimg support.