i-doit Open 38 CMDB on Ubuntu 24.04 on Azure User Guide

Overview

i-doit Open is the open source CMDB (configuration management database) and IT documentation platform from synetics GmbH. It gives IT teams a single web application to document their infrastructure: configuration items such as servers, clients, network devices, software and services, and the relationships between them, alongside IP address management, contracts, licences, cabling and rack layouts, with ITIL aligned change and incident context. The cloudimg image ships i-doit Open 38 served by Apache 2.4 and PHP 8.3 FPM on a hardened, fully patched Ubuntu 24.04 LTS base, together with a bundled local MariaDB server and a memcached cache so the appliance is complete and useful on its own. The install is completed through i-doit's own console based setup and the browser setup wizard is never exposed, so the platform is ready the moment the instance boots. The bundled MariaDB listens only on the loopback interface (127.0.0.1:3306) and keeps both i-doit databases on a dedicated Azure data disk. A unique administrator password is generated on the first boot of every VM. Backed by 24/7 cloudimg support.

cloudimg is an independent image builder and is not affiliated with, sponsored by, or endorsed by i-doit GmbH or synetics GmbH. i-doit is a trademark of its respective holder and is used here only to identify the open source software this image packages.

What is included:

• i-doit Open 38 served by Apache 2.4 and PHP 8.3 FPM, managed by systemd
• A bundled MariaDB server holding the i-doit system and tenant databases, already installed and ready
• A local memcached cache for i-doit, bound to loopback only
• The install completed through i-doit's console setup, so no browser setup wizard is ever exposed
• A per VM administrator password and Admin Center password generated on first boot and recorded in a root only file
• No shipped default login: the well known i-doit defaults such as admin and admin are never present, and the internal systemapi account is disabled
• MariaDB and memcached bound to 127.0.0.1 only, never exposed to the network
• A dedicated Azure data disk carrying both i-doit databases and file attachments
• A daily systemd timer running i-doit's scheduled maintenance jobs
• apache2.service, php8.3-fpm.service, mariadb.service and memcached.service 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_B2s (2 vCPU / 4 GiB RAM) runs the appliance comfortably; step up to Standard_D2s_v3 (2 vCPU / 8 GiB) for larger CMDBs or heavier imports. NSG inbound: allow 22/tcp from your management network, 80/tcp for the application and 443/tcp if you terminate TLS on the VM. The bundled MariaDB and memcached are never exposed: they listen on 127.0.0.1 only, so ports 3306 and 11211 stay off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for i-doit 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), HTTP (80) and HTTPS (443). Review the dedicated data disk on the Disks tab, then Review + create then Create.

Step 2 - Deploy from the Azure CLI

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

Then open ports 80 and 443:

az vm open-port --resource-group <your-rg> --name i-doit --port 80,443

Step 3 - Confirm the services are running

SSH in as azureuser and confirm Apache, PHP FPM, MariaDB and memcached are all active, and that the health endpoint answers. MariaDB and memcached listen only on 127.0.0.1, while Apache serves i-doit on port 80.

systemctl is-active apache2 php8.3-fpm mariadb memcached

curl -s -o /dev/null -w 'healthz: HTTP %{http_code}\n' http://127.0.0.1/healthz

You should see four active lines and healthz: HTTP 200.

Step 4 - Retrieve the administrator password

On the first boot of every VM, a one shot service generates a fresh i-doit web administrator password, a fresh Admin Center password and a fresh database password, unique to that instance, and writes them to a root only file. Read them over SSH:

sudo cat /root/i-doit-credentials.txt

The file records the sign in URL, the admin web login and its password, the separate Admin Center login, and the internal MariaDB credentials. It is mode 0600 and owned by root, so only an administrator on the box can read it.

Step 5 - Sign in to i-doit

Browse to http://<public-ip>/ and sign in as admin with the password from the credentials file. i-doit renders on whatever hostname or IP address you reach it on.

After signing in you land on the CMDB dashboard, with the object type tree (Infrastructure, Software, Contact and more) down the left and your personal dashboard widgets in the centre.

Step 6 - Document a configuration item

i-doit models everything as typed objects (configuration items) with categories and relationships. Open any object to see its structured detail: the General category holds the title, purpose, condition and CMDB status, while other categories hold location, contacts, IP addresses, contracts and more.

Pick an object type from the top navigation (for example Infrastructure > Server) to open its object browser, then use the toolbar to create and edit configuration items of that type. Relationships you record between objects build up the connected model of your environment.

Step 7 - The security model

This image ships no shared or default credential. i-doit's documented default logins (such as admin / admin, reader, editor, author, archivar) are never created, the internal systemapi account is disabled, and the per VM admin password is set on first boot. MariaDB and memcached are bound to loopback only, and config.inc.php (which holds the database password and encryption keys) is not served over the web. You can verify the posture on the box:

ss -tlnp | grep -E ':3306|:11211' || echo '(loopback-only)'

sudo /usr/local/sbin/i-doit-cred-roundtrip.sh

The round trip proves the per VM admin authenticates through the real web login form and that blank and common weak credentials are all rejected.

Step 8 - Where your data lives

Both i-doit databases (the system database idoit_system and the tenant data database idoit_data) and i-doit's file attachments live on a dedicated Azure data disk mounted at /data, kept separate from the operating system disk. This keeps your CMDB data on its own volume that you can snapshot and grow independently.

sudo mariadb -N -e 'SHOW DATABASES;' | grep idoit

df -h /data | tail -1

Step 9 - Enable HTTPS (optional)

For production, terminate TLS in front of i-doit. Point a DNS name at the VM's public IP, ensure port 443 is open, then install a certificate with Certbot's Apache plugin:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-apache
sudo certbot --apache -d your-domain.example.com

Certbot obtains and installs the certificate and sets up automatic renewal. After enabling HTTPS, browse to https://your-domain.example.com/.

Step 10 - Scheduled maintenance

i-doit's housekeeping jobs (search index refresh, logbook archiving, auth cleanup and notifications) run daily via the i-doit-cron.timer systemd timer as the www-data user, authenticating from a root only console configuration file. Check the timer:

systemctl list-timers i-doit-cron.timer --all

Troubleshooting

• The sign in page shows an error or does not load - confirm the services are active with the Step 3 commands and check the Apache log with sudo tail -n 50 /var/log/apache2/i-doit-error.log.
• You do not know the admin password - re read it with sudo cat /root/i-doit-credentials.txt.
• First boot did not run - it is gated by a sentinel at /var/lib/cloudimg/i-doit-firstboot.done; inspect sudo journalctl -u i-doit-firstboot.service.
• Database connection errors - MariaDB listens on 127.0.0.1:3306; on box maintenance is sudo mariadb as root over the local socket.

Support

This image is published by cloudimg, an independent image builder that is not affiliated with or endorsed by i-doit GmbH. cloudimg provides 24/7 support by email (support@cloudimg.co.uk) and live chat, covering deployment, configuration, upgrades, performance tuning and MariaDB administration.