Page History
| Table of Contents | ||
|---|---|---|
|
Overview
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.
...
- Provide a Linux host that meets the requirements on this page.
- Create and mount the filesystems for iDNA (see Running iDNA Applications on Your Own Linux Host Partitioning).
- Install Docker Engine.
- Download and run the iDNA installer (see Installing iDNA Applications on Linux).
- Log in to iDNA and configure it.
...
- You provide and operate the host: the operating system and its security updates, Docker, monitoring, and backups of the host and of the iDNA database.
- panagenda provides iDNA Applications as Docker containers, and the installer that installs and upgrades them. Each new iDNA version also brings updated components inside the containers.
...
Operating Systems
...
Recommended Distributions
panagenda recommends these distributions. They are among the most widely used Linux distributions, and panagenda tests iDNA Applications on them:
- Red Hat Enterprise Linux 9 and 10 and compatible distributions: AlmaLinux, Rocky Linux, Oracle Linux and CentOS Stream, each in version 9 or 10.
- AlmaLinux 9 and 10
- Ubuntu 24.04 LTS and 26.04 LTS
panagenda tests on Red Hat Enterprise Linux 9, AlmaLinux 10, Ubuntu 24.04 LTS and Ubuntu 26.04 LTS.
...
Other current x86_64 Linux distributions with Docker Engine and the Docker Compose plugin are likely to work, but are not supported.
Not supported: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.
Supported Distributions
iDNA Applications runs on any Linux distribution that meets these requirements:
- An x86_64 processor (64-bit Intel or AMD).
- A current Docker Engine with the Docker Compose plugin (version 2).
- Docker starts at boot. systemd is recommended: the setting that makes Docker wait for the iDNA filesystems is a systemd setting (see Partitioning).
- bash and the standard tools the installer checks for (see Access and Software).
- Writable directories
/optand/usr/bin. - Ports 80 and 443 free.
panagenda support helps you install and run iDNA Applications on any distribution that meets these requirements, also on one that panagenda does not test itself, for example Rocky Linux, Oracle Linux, CentOS Stream, Debian or SUSE Linux Enterprise.
Unsupported Setups
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.
Not Supported
- ARM processors (for example AWS Graviton or Apple Silicon): the iDNA containers exist for x86_64 only.
- Distributions with a read-only system partition, such as Fedora CoreOS, Flatcar or Ubuntu Core: the installer needs to write to
/usr/bin. - Podman instead of Docker Engine: the installer and the iDNA containers need Docker Engine (
docker compose,docker infoand the Docker socket). - Windows and macOS has hosts.
Not supported for production use:
- as hosts: containers need a Linux kernel. For WSL2, see Evaluation on Windows (WSL2).
Evaluation on Windows (WSL2)
For evaluation and tests, iDNA Applications can run in the Windows Subsystem for Linux (WSL2)
...
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, 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.
Host Requirements
Access and Software
- Root access: the installer runs as root, directly or through
sudo. - Docker Engine with the Docker Compose plugin (Compose version 2). Install it from Docker's own repository, following Docker's guide for your distribution:
- Red Hat Enterprise Linux: docs.docker.com/engine/install/rhel
- CentOS Stream: docs.docker.com/engine/install/centos
- Ubuntu: docs.docker.com/engine/install/ubuntu
Afterwards, both of these commands must work:
Docker must start at boot; the iDNA containers start automatically together with Docker:Code Block language bash docker version docker compose version
Code Block language bash systemctl enable --now docker
- Standard tools: tar, grep, awk, sed, hostname, ip, fdisk, one of ss, lsof, netstat or fuser, and timedatectl. A normal server installation includes them; the installer names any that are missing. You also need unzip to unpack the download.
- SELinux can stay enforcing. With a standard Docker installation, the installer needs no changes. Only if Docker itself enforces SELinux on containers does the installer need the package policycoreutils-python-utils, and it asks before it changes anything. On Ubuntu, AppArmor needs no changes.
...
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:
- Use LVM, so that the filesystems can be extended.
- Mount the filesystems before you run the installer, with entries in
/etc/fstab. Otherwise the installer writes into the directories on the root filesystem, and a filesystem mounted there later hides that data. - Make Docker wait for the filesystems at boot. If
/opt/panagenda/pgdatais 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):Code Block language bash 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
...
