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.
...
- 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, getent, timeout, 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. With curl, the installer also checks at the end that the server address answers; without it, it skips this check.
- SELinux can stay in enforcing mode. With a standard Docker installation, no SELinux changes are needed. Only if SELinux support is enabled in Docker (
"selinux-enabled": truein/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.
...
- 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.
- Server address: decide on the DNS name under which users will open iDNA in their browser, for example
idna-apps.exampleacme.com, and register it in DNS so that it points to the host before the installation. iDNA uses this address for its web interface and its Metabase reports, in the links of Metabase emails, and in iDNA alert emails. The installer suggests names, checks them in DNS and lets you choose (see Server Address). The host's own name does not have to match, and the installer does not rename the host. An IP address also works, but every link breaks when it changes. Do not useidnaas the server address or as its first part (for exampleidna.acme.com): iDNA uses the server address as the host name of one of its containers, which can then no longer reach the container calledidna. Avoididnaas the host's own name too, because the installer suggests server addresses based on it. - Time zone: set the time zone of the host (
timedatectl set-timezone). The installer copies it into the iDNA configuration.
...
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
...
