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.

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 (NEW)).

This page describes what the Linux host needs. Hand it to the team that provides your Linux servers before the installation, so that the host is ready when you install iDNA.

The installation at a glance:

1. Provide a Linux host that meets the requirements on this page.
2. Create and mount the filesystems for iDNA (see Partitioning).
3. Install Docker Engine.
4. Download and run the iDNA installer (see Installing iDNA Applications on Linux).
5. Log in to iDNA and configure it.

Responsibilities

• 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.

Supported Operating Systems

iDNA Applications supports these Linux distributions on x86_64 (64-bit Intel or AMD) processors:

• Red Hat Enterprise Linux 9 and 10 and compatible distributions: AlmaLinux, Rocky Linux, Oracle Linux and CentOS Stream, each in version 9 or 10.
• Ubuntu 24.04 LTS and 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:

• ARM processors (for example AWS Graviton): 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.
• Windows, including the Windows Subsystem for Linux (WSL2), and macOS as hosts.

Note on version 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.

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
  Docker does not list AlmaLinux, Rocky Linux and Oracle Linux separately; use the instructions for Red Hat Enterprise Linux or CentOS. Docker's guides first remove Podman and runc, which these distributions may have installed; Podman, also with the podman-docker package, is not a substitute for Docker Engine. On Ubuntu, the Docker snap package is not supported.
  Afterwards, both of these commands must work:

  docker version docker compose version

  Docker must start at boot; the iDNA containers start automatically together with Docker:

  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.

Network

• Ports 80 and 443 must be free on the host. The iDNA web server uses both; port 80 redirects to HTTPS on port 443. Users and administrators reach iDNA over HTTPS.
• Firewall: Docker opens the ports of its containers with its own firewall rules, so firewalld or ufw on the host usually need no extra rule. Firewalls between your users and the host must allow port 443.
• Domino servers: the host needs the same network access to your Domino servers as before, for example Notes RPC on port 1352 (see System Requirements, Access and Permissions).
• Internal Docker network: iDNA uses a private /24 subnet for the communication between its containers, by default 192.168.238.0/24. If your network already uses this subnet, change it after the installation (see Configuration File).
• Internet access: the online installer downloads the iDNA Docker images from docker.panagenda.com over HTTPS (no login needed). If the host reaches the internet through a proxy, configure Docker's proxy settings (docs.docker.com/engine/daemon/proxy). The offline installer contains the images and needs no internet access.
• Host name and time zone: give the host the fully qualified name under which users will reach iDNA (shown by 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.

Dedicated Host

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.

Sizing

For most environments, start with:

• 4 CPU cores
• 16 GB RAM
• 300 GB disk space

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.

Partitioning

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:

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/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

Next Steps

• New installation: Installing iDNA Applications on Linux
• Upgrading an existing installation or appliance: Upgrading iDNA Applications (NEW)