OpenDocMan on Ubuntu 24.04 on Azure User Guide

Overview

OpenDocMan is a free and open source web based Document Management System. It gives an organisation one controlled place to keep documents instead of a shared drive: every file is uploaded into a repository, checked out before it is edited and checked back in as a new revision, so two people can never quietly overwrite one another and the whole revision history stays intact. Access is granted per department and per user, with read, write, administer and view rights applied file by file, and an optional review step holds a new or updated document until an administrator approves it.

The cloudimg image ships OpenDocMan 2.6.0 served by nginx and PHP 8.3 FPM on a hardened, fully patched Ubuntu 24.04 LTS base, together with a bundled local MariaDB server so the appliance is complete on its own. The bundled MariaDB listens only on the loopback interface (127.0.0.1:3306). A unique administrator password and a unique database password are generated on the first boot of every VM. Backed by 24/7 cloudimg support.

There is no installer to reach. OpenDocMan's web installer has no already installed lock, so a reachable one would let a stranger rewrite the database configuration or drop every table. On this image the installation was completed at build time over the loopback interface, the installer was then removed from the image entirely and its routes are blocked at the web server, and nginx does not bind port 80 at all until the per VM first boot has minted your credentials.

What is included:

• OpenDocMan 2.6.0 served by nginx and PHP 8.3 FPM, managed by systemd
• A bundled MariaDB 10.11 server holding the OpenDocMan database, schema already created and ready
• A per VM administrator password and a per VM database password generated on first boot into a root only file
• No shipped default login: upstream's published admin credential is rotated away and no known or blank credential authenticates
• The installer removed from the image and every installer route hard blocked in nginx
• nginx held shut until first boot completes, so the appliance never serves a request before your credentials exist
• The document repository at /var/www/document_repository, outside the web root, so an uploaded file is never directly fetchable
• MariaDB bound to 127.0.0.1 only, never exposed to the network
• An unauthenticated /healthz endpoint for Azure Load Balancer health probes
• nginx.service, php8.3-fpm.service and mariadb.service as enabled systemd units
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point; size up for larger repositories or heavier content indexing. NSG inbound: allow 22/tcp from your management network and 80/tcp for the application. OpenDocMan serves plain HTTP on port 80; for production, terminate TLS in front of it with your own domain. The bundled MariaDB is never exposed: it listens on 127.0.0.1 only, so port 3306 stays off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for OpenDocMan 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 followed by Create.

Step 2 - Deploy from the Azure CLI

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

Then open port 80 to the application:

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

Step 3 - Confirm the services are running

SSH in as azureuser and confirm nginx, PHP FPM and MariaDB are all active. Note that MariaDB listens only on 127.0.0.1:3306 while nginx serves the application on port 80. The opendocman-firstboot unit reports active once it has finished its one shot run.

systemctl is-active nginx php8.3-fpm mariadb opendocman-firstboot

ss -tlnp | grep -E ':80 |:3306 '

Step 4 - Retrieve your per VM credentials

Every VM generates its own administrator password and its own database password on first boot and writes them to a root only file. Nothing is shared between deployments and nothing is recoverable from the published image.

sudo cat /root/opendocman-credentials.txt

Step 5 - Sign in

Browse to http://<your-vm-public-ip>/. Sign in with the user admin and the password from /root/opendocman-credentials.txt.

Step 6 - Add your first document

Choose Add Document. Pick the file to upload, choose its owner, department and category, set the department and per user permissions the document should carry, add a description, and submit. OpenDocMan writes the file into /var/www/document_repository, outside the web root, and records its metadata, owner, department, permissions and revision in the database.

Step 7 - Review and approve it

OpenDocMan ships with the authorization setting on, so a newly uploaded document is held for review before it becomes visible to other users. On the home page you will see Documents waiting to be reviewed; open it, tick the document, and choose Authorize (or Reject). You are then asked for a comment to send to the author, and once you confirm, the document is published into the repository.

If you would rather documents publish immediately, turn the review step off in Admin under Settings by setting authorization to False.

Step 8 - Browse the repository

Choose Home. The Files List shows every document you are allowed to see, with its ID, filename, description, lock status, created and modified dates, author, department and size. The filename is a link: clicking it downloads the document through OpenDocMan's permission check rather than straight off disk.

Step 9 - Check a document out and back in

Open a document and choose Check Out. OpenDocMan locks it, so its status changes from unlocked to locked and nobody else can submit a competing revision while you hold it. When you have finished editing, choose Check-in in the navigation, upload the new copy, and OpenDocMan stores it as the next revision and releases the lock. The previous revision stays in the document's history.

Step 10 - Manage departments, users and permissions

Choose Admin. This is where you add, update and delete users, departments and categories, manage file types, define your own metadata fields, review the reviews and rejections queues, list checked out files, adjust the site settings, and read the reports. Rights are Forbidden, None, View, Read, Write and Admin, and they apply per department and per user on each document.

Step 11 - Verify the security posture

Three things are worth confirming on your own VM. First, the installer is gone: every installer route returns 404 and the installer code is not on disk. Second, the administrator created at first boot is the only account that can sign in. Third, the credential round trip proves that the per VM password works through the real sign in form and that a blank password, upstream's published default and the common weak guesses are all rejected:

for r in installer installer/setup-config "installer?op=install&force_fresh=1" install/odm.php; do printf '%s -> ' "/$r"; curl -s -o /dev/null -w '%{http_code}\n' "http://127.0.0.1/$r"; done

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

Step 12 - Verify the stack and the first boot gate

Confirm the OpenDocMan version and the health endpoint, and look at the gate that keeps the appliance shut until your credentials exist. nginx.service carries a ConditionPathExists on the first boot sentinel, so at a fresh boot systemd skips nginx entirely; the first boot service mints your credentials, writes the sentinel and only then starts nginx:

grep ODM_APP_VERSION /var/www/opendocman/application/version.php; curl -sI http://127.0.0.1/healthz | head -1

grep -h '^ConditionPathExists' /etc/systemd/system/nginx.service.d/*.conf; ls -l /var/lib/cloudimg/

Where your data lives

The OpenDocMan application tree is at /var/www/opendocman, owned by www-data, with the document root at /var/www/opendocman/public. Its configuration, including the database credentials, is at /var/www/opendocman/application/configs/config.php. Your documents are not in the web tree: they live at /var/www/document_repository, which is exactly why an uploaded file can never be fetched directly and every download goes through OpenDocMan's permission check. The MariaDB database opendocman holds every user, department, permission, document record, revision and log entry, in its default datadir at /var/lib/mysql. Back up the document repository and the database together.

sudo mariadb --protocol=socket -uroot -N -e "SELECT COUNT(*) AS users FROM opendocman.odm_user"

Adding your own domain and TLS

The appliance serves plain HTTP on port 80. For production, front it with your own domain and a TLS certificate. OpenDocMan derives its own base URL from the request host at runtime, so there is no address to configure in the application. Once TLS terminates in front of the VM, turn the secure session cookie back on:

sudo sed -i 's/^session.cookie_secure = Off/session.cookie_secure = On/' /etc/php/8.3/fpm/conf.d/99-opendocman.ini
sudo systemctl restart php8.3-fpm

You can terminate TLS with Azure Application Gateway, an nginx or Caddy reverse proxy, or a managed load balancer with a certificate for your domain.

Why the secure cookie ships Off. A session.cookie_secure cookie is only ever sent over HTTPS, so leaving it on while the appliance serves plain HTTP would silently break every sign in. Turn it on in the same change that puts TLS in front of the VM.

Security notes

• The installer is not in this image and every installer route returns 404. Nobody can rewrite your database configuration or drop your tables by reaching a setup wizard.
• nginx does not bind port 80 until the first boot service has written your per VM credentials, so the appliance never serves a request before it is yours.
• The administrator password and the database password are unique per VM, and upstream's published default admin credential does not authenticate. Keep /root/opendocman-credentials.txt protected and change the password from within OpenDocMan if you share access.
• Documents live outside the web root at /var/www/document_repository, so no upload is ever directly fetchable and every download is permission checked.
• The bundled MariaDB listens on 127.0.0.1 only and is never reachable from the network. Administer it over SSH with sudo mariadb.
• OpenDocMan serves plain HTTP on port 80. For anything beyond a trusted network, put it behind your own TLS terminating reverse proxy or Azure Application Gateway with a certificate for your domain.
• Restrict inbound 80/tcp in your NSG to the networks that need the application.

Support

This image is maintained by cloudimg with 24/7 support. If you need help deploying or operating OpenDocMan on Azure, contact us at cloudimg.co.uk.