Page History

...

• 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). The host must also resolve the names of your Domino servers (see Domino Name Resolution / DNS).
• 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.acme.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 use idna as the server address or as its first part (for example idna.acme.com): iDNA uses the server address as the host name of one of its containers, which can then no longer reach the container called idna. Avoid idna as 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.

Domino Name Resolution / DNS

iDNA connects to your Domino servers most reliably when the host can resolve the common name of each Domino server in DNS, the same way Notes clients usually find their servers. The common name is the first part of the server's hierarchical name, for example MailServer01 for MailServer01/ACME. Without this, iDNA works with the network names of the servers, but you have to know them and keep them up to date in iDNA, which often delays the setup. When a connection fails, iDNA's data collection also tries the common name, which avoids many collection problems.

The network name of a server is often different from its common name, for example msrveu01.internal.acme.com. A DNS alias (CNAME record) connects the two:

mailserver01.internal.acme.com  CNAME  msrveu01.internal.acme.com

For the short name to resolve, the DNS search list of the host must contain the domain of these aliases, here internal.acme.com. Hosts with a static network configuration often have no search domain; use the one your Notes clients get.

Check it on the host for each Domino server:

getent hosts MailServer01

The output must show the IP address of the Domino server. ping MailServer01 shows the address too, in its first line; whether ping gets a reply does not matter.

Use DNS for this, not /etc/hosts. iDNA runs in Docker containers, which use the DNS servers and search domains of the host. Whether they also see the entries in the host's /etc/hosts depends on how the host resolves names: with the default network setup of Ubuntu (systemd-resolved) they do, with that of RHEL and AlmaLinux they do not. Entries in /etc/hosts also have to be maintained by hand on this one host.

If the common names cannot be resolved in your network, enter the network name or IP address of each server in iDNA instead: https://<server address>/idna/sys/servers, column [Hostname].

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 if other containers are already running on the host when iDNA is installed for the first time.

...