Starting with version 3.5.0, iDNA Applications runs on a Linux host that you provide. You prepare the host with a supported Linux distribution and Docker; the panagenda installer then sets up iDNA Applications on it as a set of Docker containers. This gives you more flexibility in choosing your virtualization platform and makes it easier to keep the operating system iDNA runs on up to date.
As of version 3.5.0, panagenda no longer supplies virtual appliance images for VMware or Hyper-V. Existing iDNA appliances keep running and are upgraded with the same installer (see Upgrading iDNA Applications).
This page lists the requirements for the Linux host. Share it with the team that provides your Linux servers, and have them prepare the host before you install iDNA.
The installation at a glance:
panagenda recommends these distributions. They are among the most widely used Linux distributions, and panagenda tests iDNA Applications on them:
panagenda tests on Red Hat Enterprise Linux 9, AlmaLinux 10, Ubuntu 24.04 LTS and Ubuntu 26.04 LTS. AlmaLinux is binary-compatible with Red Hat Enterprise Linux, so each of these tests also covers the same version of the other distribution.
Note on version RHEL 10: Red Hat Enterprise Linux 10 and most compatible distributions require a processor with the x86-64-v3 feature level (Intel Haswell from 2013 or newer, or a comparable AMD processor). On a virtual machine, the hypervisor must pass these processor features through; an older VMware EVC mode, for example, keeps the operating system from starting. AlmaLinux 10 also offers a build for older processors.
iDNA Applications runs on any Linux distribution that meets these requirements:
/opt and /usr/bin.panagenda support (support@panagenda.com) helps you install and run iDNA Applications on any distribution that meets these requirements, including distributions panagenda does not test itself. Examples are Rocky Linux, Oracle Linux, CentOS Stream, Debian and SUSE Linux Enterprise.
Setups that do not meet these requirements but may still work. You are welcome to try them, but panagenda does not recommend them for production and cannot guarantee that they run stably or keep working after an upgrade. panagenda support covers iDNA Applications itself, starting at the web interface, but not the setup.
/usr/bin.docker compose, docker info and the Docker socket).For evaluation and tests, iDNA Applications can run in the Windows Subsystem for Linux (WSL2), with a recommended distribution and Docker. It is not intended for production: the WSL2 environment depends on a Windows user session, and ports 80 and 443 have to be forwarded from Windows.
sudo.docker version docker compose version |
systemctl enable --now docker |
"selinux-enabled": true in /etc/docker/daemon.json) does the installer need the package policycoreutils-python-utils, and it asks before it changes anything. On Ubuntu, AppArmor needs no changes.hostname -f), and set its time zone (timedatectl set-timezone). The installer copies both into the iDNA configuration; iDNA uses the host name in alert emails and for the address of its Metabase reports.We recommend a host that runs only iDNA Applications. To manage the iDNA containers, the iDNA cron container has access to the Docker daemon (/var/run/docker.sock). This gives it full control over every container on the host, including containers of other applications. The installer points this out and asks for confirmation.
For most environments, start with:
RAM and disk space grow with the number of users, the number of databases and the collection period. For larger environments, see the sizing table in System Requirements, Virtual Hardware; it applies to your own Linux host as well.
As on the former iDNA appliance, keep the iDNA directories that grow on filesystems of their own. If the log files or the operating system fill their filesystem, the database keeps working, and the filesystems that grow can be extended without touching the root filesystem.
Example for the 300 GB default:
| Filesystem | Recommendation | Size in the example | Why |
|---|---|---|---|
/ (root) | required | 70 GB | The operating system (about 20 GB) and Docker, which keeps the iDNA images and containers in /var/lib/docker. During an upgrade, the old and the new images exist side by side, and the offline installer unpacks about 8 GB in /tmp. Plan the root filesystem generously: a full root filesystem is hard to fix, while the iDNA filesystems are easy to extend. |
/opt/panagenda/appdata | recommended | 30 GB | The Notes database designs iDNA downloads, stored as zipped DXL files. Fills during the first design collection and grows slowly afterwards: about 5 MB per database, 30 to 80 GB in large environments. |
/opt/panagenda/logs | recommended | 5 GB | The log files of all iDNA services. iDNA deletes them after 7 to 14 days; a filesystem of their own keeps an unusual amount of log output away from the operating system and the database. |
/opt/panagenda/pgdata | strongly recommended | 175 GB | The iDNA database, the part that grows continuously. A filesystem of its own keeps a full root or log filesystem from affecting it. |
| unassigned | recommended | 20 GB | Free space in the LVM volume group, to extend a filesystem quickly when needed. |
Rules for the filesystems:
/etc/fstab. Otherwise the installer writes into the directories on the root filesystem, and a filesystem mounted there later hides that data./opt/panagenda/pgdata is not mounted when Docker starts, the database container finds an empty directory and creates a new, empty database on the root filesystem; iDNA then starts without its data. This setting keeps Docker from starting until the filesystems are mounted (list the filesystems you created):
mkdir -p /etc/systemd/system/docker.service.d cat > /etc/systemd/system/docker.service.d/panagenda-mounts.conf <<'EOF' [Unit] RequiresMountsFor=/opt/panagenda/pgdata /opt/panagenda/appdata /opt/panagenda/logs EOF systemctl daemon-reload |