Applications Azure

OCS Inventory NG 2.12 IT Asset Management on Ubuntu 24.04 on Azure User Guide

| Product: OCS Inventory NG 2.12 IT Asset Management on Ubuntu 24.04 LTS on Azure

Overview

OCS Inventory NG (Open Computers and Software Inventory Next Generation) is the open source IT asset management platform for discovering and inventorying every machine you own. Lightweight agents installed on Windows, Linux, macOS, Android and BSD machines report their hardware, installed software, running services and configuration to a central server, so you always know what you have without walking the floor or maintaining a spreadsheet. From one web console you can search and group the estate, track software licences and CVE exposure, discover unknown devices on the network with IpDiscover, inventory SNMP devices such as printers and switches, and push software deployment packages to managed machines.

The product has two server halves and this image ships both, already wired to one database: the communication server, a Perl handler running inside Apache at /ocsinventory, which is the endpoint agents post their inventories to; and the web console (ocsreports), the PHP interface at /ocsreports where you read the results. A manual installation is unusually involved: Apache with both mod_perl and mod_php, a database, a dozen Perl modules, a compiled Perl module, an interactive shell installer, then a separate web based database installation and a schema upgrade before the console will open. All of that is completed and locked away here, on a hardened, fully patched Ubuntu 24.04 LTS base. A unique console administrator password and a unique database password are generated on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

  • OCS Inventory NG 2.12.5 with both server components installed and wired together
  • The Perl communication server at /ocsinventory, the endpoint your agents report to
  • The ocsreports web console at /ocsreports, served by Apache with PHP 8.3
  • A bundled MariaDB server holding the ocsweb inventory database, already installed and ready
  • The shell installer, the web database installation and the schema upgrade all pre completed
  • A per VM console administrator password generated on first boot and recorded in a root only file
  • No shipped default login: upstream's admin/admin console account and its published ocs/ocs database login are both rotated away, and the wildcard host database account upstream's installer creates is removed
  • The install and update wizards denied from the web and readable only by root
  • MariaDB bound to 127.0.0.1 only, never exposed to the network
  • A dedicated Azure data disk carrying both the inventory database and the deployment packages, SNMP and IpDiscover trees
  • A software aggregation timer so newly reported packages appear in the console automatically
  • apache2.service and mariadb.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) is a sensible starting point for a few hundred machines; move up to Standard_D2s_v3 or larger for a big estate or heavy software deployment use. NSG inbound: allow 22/tcp from your management network, 80/tcp so both the console and the agent endpoint are reachable, and 443/tcp if you terminate TLS on the VM. Your agents must be able to reach port 80 (or 443) on this VM. The bundled MariaDB is never exposed: it listens on 127.0.0.1 only, so port 3306 stays off the network.

Launch from the Azure Marketplace

In the Azure portal choose Create a resource, search for the cloudimg OCS Inventory NG offering, and select it. Pick your subscription, resource group and region, choose Standard_B2s or larger, and select SSH public key authentication with the user name azureuser. On the Disks blade leave the attached data disk in place: it carries your inventory database and deployment packages. On the Networking blade attach an NSG allowing 22, 80 and 443 inbound. Review and create.

Launch from the Azure CLI

az vm create \
  --resource-group my-resource-group \
  --name ocs-inventory \
  --image <the cloudimg OCS Inventory NG offer URN> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

az vm open-port --resource-group my-resource-group --name ocs-inventory --port 80 --priority 1001

First boot

On the first boot of your VM a one shot service, ocs-inventory-ng-firstboot.service, generates a console administrator password and a database password unique to that instance, writes them into the console and communication server configuration in lock step, restarts Apache so the communication server picks up the new database secret, and records everything in a root only file. It runs once and then does nothing on subsequent boots.

Connect over SSH and confirm the stack is up:

systemctl is-active apache2 mariadb
systemctl is-enabled ocs-inventory-ng-software-aggregate.timer
curl -s -o /dev/null -w 'healthz: %{http_code}\n' http://127.0.0.1/healthz
curl -s -o /dev/null -w 'console: %{http_code}\n' -L http://127.0.0.1/ocsreports/

The apache2 and mariadb services reporting active with the software aggregation timer enabled, Apache listening on port 80 with MariaDB bound to loopback 127.0.0.1:3306, the installed OCS Inventory NG version, and the health and console endpoints both answering

Retrieve your console password

The per VM credentials are written to a root only file:

sudo cat /root/ocs-inventory-ng-credentials.txt

The per VM OCS Inventory NG credentials file, showing the console URL, the admin console user, the generated password masked, the agent server URL and the loopback MariaDB details, with the first boot service enabled

The file records the console URL, the console user (admin) and its per VM password, the agent server URL you will point your agents at, and the loopback MariaDB details.

The addresses in that file are this VM's own address as seen from inside the VM. Azure does not expose the public IP to the instance, so it is usually the private address. Browsing the public IP shown in the Azure portal works identically: OCS builds its console links relative to the request, so it answers correctly on the public IP, the private IP or any DNS name you point at it.

Sign in to the console

Browse to http://<your-vm-address>/ocsreports/ (the bare address redirects there). Sign in as admin with the password from the credentials file.

The OCS Inventory NG sign in page showing the language selector, the user and password fields and the send button

The dashboard summarises the estate this server is tracking: how many machines have reported, how they split across Windows, Unix and Android, and which agent and operating system versions are in use.

The OCS Inventory NG dashboard showing one reporting machine counted under Unix, one operating system, and the agent version and OS version charts naming the reporting agent and Ubuntu 24.04

Enrol your first agent

A fresh server has an empty estate: machines appear as soon as an agent reports to it. Take the agent server URL from your credentials file (http://<your-vm-address>/ocsinventory) and point agents at it.

On a Debian or Ubuntu machine you want to inventory:

sudo apt-get install -y ocsinventory-agent

sudo tee /etc/ocsinventory/ocsinventory-agent.cfg >/dev/null <<'EOF'
server = http://<your-vm-address>/ocsinventory
tag = london-office
EOF

sudo ocsinventory-agent --force

The tag is free text that groups machines in the console, so setting something meaningful per site or department is worth doing at enrolment time. On Red Hat family machines the package is ocsinventory-agent from EPEL; for Windows and macOS download the agent installer from the OCS Inventory NG project's own download page and give it the same server URL.

Within seconds of the agent running, the machine appears in All computers with its operating system, memory and processor:

The OCS Inventory NG all computers list showing one inventoried machine with its tag, last inventory timestamp, operating system Ubuntu 24.04, RAM and CPU speed columns

Selecting a machine opens its full inventory: detected operating system, memory, network address, the reporting agent version and the timestamp of the last inventory, with tabs for hardware, software, network, devices and deployment.

The OCS Inventory NG computer detail page showing the collected system, network, hardware and agent sections for the inventoried machine, including its operating system, memory, IP address, reporting agent version and last inventory time

You can confirm the same thing from the shell, which is useful when checking whether a remote agent really reached the server:

curl -s -o /dev/null -w 'agent endpoint: %{http_code}\n' http://127.0.0.1/ocsinventory
sudo mariadb --protocol=socket -uroot ocsweb -e "SELECT NAME, OSNAME, MEMORY, LASTDATE FROM hardware ORDER BY LASTDATE DESC LIMIT 10;"

A GET on the agent endpoint returning 400 is correct and healthy: agents POST compressed XML there, so a plain browser request is rejected by design.

The agent endpoint answering, the inventoried machine listed in the database with its operating system, processor and memory, the collected and indexed software counts, and the software aggregation timer enabled and active

How software inventory is indexed

The communication server records every package an agent reports, but the console's All software view reads through a separate index. This image ships ocs-inventory-ng-software-aggregate.timer, which runs the project's own aggregation job every 30 minutes to rebuild that index, so newly reported software appears without you doing anything. To rebuild it immediately after enrolling a batch of machines:

sudo systemctl start ocs-inventory-ng-software-aggregate.service
sudo mariadb --protocol=socket -uroot ocsweb -e "SELECT COUNT(*) AS indexed_software FROM software_link;"

To change the cadence, edit /etc/systemd/system/ocs-inventory-ng-software-aggregate.timer and run sudo systemctl daemon-reload.

The project also ships optional maintenance jobs in /usr/share/ocsinventory-reports/ocsreports/crontab/ for CVE import, orphan cleanup, IpDiscover, wake on LAN and notifications. They are present but not scheduled, so you can enable only the ones you want.

Security model

There is no shipped default login. Upstream's installer leaves two well known credentials behind and this image removes both:

  • the console's seeded admin account, whose password is the published default, is rotated to a value nobody has, and then to a fresh per VM password on first boot
  • the database login upstream's web installer hardcodes is rotated per VM, and the wildcard host database account it creates (reachable from any address the database listens on) is removed entirely

The install and update wizards are denied from the web and readable only by root, which also clears the security banner OCS otherwise displays on every page. You can verify the whole posture on your own VM:

sudo bash /usr/local/sbin/ocs-inventory-ng-cred-roundtrip.sh
curl -s -o /dev/null -w 'install wizard: %{http_code}\n' http://127.0.0.1/ocsreports/install.php
sudo mariadb --protocol=socket -uroot -N -B -e "SELECT COUNT(*) AS wildcard_accounts FROM mysql.user WHERE User='ocs' AND Host='%';"

The round trip check signs in through the real console login form with your per VM password, then confirms that a blank password and the published defaults are all rejected.

The published default console password absent from the operators table, the published database login rejected, no wildcard host database account, the install wizard denied with 403, the data disk mounts, and the credential round trip reporting success

Where your data lives

A dedicated Azure data disk is mounted at /data and carries both halves of your data, so nothing of yours sits on the OS disk:

findmnt -no SOURCE,TARGET,FSTYPE /data /var/lib/mysql /var/lib/ocsinventory-reports
df -h /data

/var/lib/mysql holds the ocsweb inventory database and /var/lib/ocsinventory-reports holds the deployment packages, SNMP data, IpDiscover results and console logs. Both are bind mounted from the data disk, so you can grow the disk in Azure and both follow.

To back up the inventory database:

sudo mariadb-dump --protocol=socket -uroot --single-transaction ocsweb | gzip > /tmp/ocsweb-backup.sql.gz
ls -lh /tmp/ocsweb-backup.sql.gz

Enabling HTTPS

Agents and the console both talk over port 80 by default. To terminate TLS on the VM, point a DNS name at the public IP, open 443, and use the packaged Certbot Apache plugin:

sudo apt-get install -y certbot python3-certbot-apache
sudo certbot --apache -d ocs.your-domain.example --agree-tos -m admin@your-domain.example --redirect

After the certificate is issued, update your agents' server setting to the https:// URL. The console follows the request scheme automatically, so its links switch to HTTPS with no further configuration.

Optional: the REST API

The project's REST API is installed and its Apache configuration is present at /etc/apache2/conf-available/zz-ocsinventory-restapi.conf, but it is not enabled, because upstream restricts it to 127.0.0.1 so it offers nothing over the network as shipped. To turn it on, enable the configuration and reload Apache, then adjust the Require ip directive to match the clients you want to allow.

Service operations

systemctl status apache2 --no-pager | head -5
systemctl status mariadb --no-pager | head -5
systemctl list-timers ocs-inventory-ng-software-aggregate.timer --no-pager
sudo tail -5 /var/log/apache2/ocsinventory-error.log

The communication server logs to /var/log/ocsinventory-server/, and raising LOGLEVEL to 1 in the console's Configuration menu makes it considerably more detailed, which is the first thing to do when an agent is not appearing.

Troubleshooting

An agent runs but the machine never appears. Confirm the agent can reach this VM on port 80 and that your NSG allows it, then check that the agent is really posting rather than falling back to writing a local file: sudo ocsinventory-agent --force prints the server response. On the server, sudo tail /var/log/apache2/ocsinventory-error.log shows rejected inventories.

The console loads but shows no software. The software index is rebuilt every 30 minutes; run sudo systemctl start ocs-inventory-ng-software-aggregate.service to rebuild it immediately.

You forgot the console password. It is in /root/ocs-inventory-ng-credentials.txt. If it has been changed inside the console and lost, reset it in the database and then sign in with the new value:

sudo mariadb --protocol=socket -uroot ocsweb -e "UPDATE operators SET PASSWD=SHA2('<new-password>',256), PASSWORD_VERSION=2 WHERE ID='admin';"

Support

cloudimg provides 24/7 technical support for this product by email (support@cloudimg.co.uk) and live chat, covering deployment, agent enrolment across Windows, Linux and macOS, console and permissions configuration, IpDiscover and SNMP setup, software deployment packages, upgrades, performance tuning and MariaDB administration. Critical issues receive a one hour average response time.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.