Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

Daniel Nashed

Tags

Using Server Groups for Domino Replication

Daniel Nashed – 31 July 2026 20:30:01

One of the lesser-known features in Domino server-to-server replication is that the Destination Server field in a Connection document does not have to contain a single server name. Instead, it can reference a Server Group.
According to the Domino documentation:

"You can also specify a Group name that contains server names so that the Source server replicates with each server listed in the group you specify.
To do this, you create a group that contains servers only, and specify 'Servers only' as the group type. The group cannot contain the names of other groups of servers."
https://help.hcl-software.com/domino/14.5.1/admin/conf_schedulingservertoserverreplication_t.html

At first glance this looks like an elegant way to simplify replication topologies.

A Simple Example

Instead of creating individual Connection documents like this:
ServerA --> ServerB
ServerA --> ServerC
ServerA --> ServerD

you can create a group:

---

Source Server: ServerA
Destination Server: ReplicationTargets

ServerB
ServerC
ServerD

---

and configure a single Connection document:

Domino will iterate over every server in the group and establish replication entry for each member.
This can significantly reduce the number of Connection documents that need to be maintained, especially in hub-and-spoke environments.

Requirements

There are a few rules that are easy to overlook:

The group type must be Servers only.
Nested groups are not supported.

The Hidden Catch

During testing we ran into an important limitation that is not immediately obvious from the documentation.
The group approach works well only if Domino can determine how to reach every destination server automatically.

That generally means:

All servers are on the same Notes Named Network, or
Domino can determine the network path without requiring server-specific addressing information.

If a destination server requires a dedicated network address, custom traget port, or other server-specific connection parameters, things become more complicated.

Why?

A Connection document that targets a group can only contain one set of connection parameters.
There is no way to specify different TCP/IP addresses or network information for each server in the group.
Once replication is initiated via the group Connection document, the server-specific Connection documents are apparently not consulted for network addressing.

When It Works Well

Using server groups is a great fit for environments such as:

Servers on the same LAN
Well-connected Notes Named Networks
Replication where no explicit network addresses are required
Hub servers that periodically contact many similarly configured servers

Comments [0]

FRITZ!Box ChatGPT

FRITZ!Box installation with ChatGPT

Daniel Nashed – 24 July 2026 21:10:38

What a fun experience. Even I know FRITZ!Box configurations quite well, having ChatGPT as a chat buddy during install is great.
No matter if the interface is German or English, ChatGPT really knows the FRITZ!Box interface.

The session we had yesterday trying to get my WLAN working again was great.
We ended up deciding I need a new FRITZ!Box 7690 replacing the 7 year old box and set it up together today because of a broken 2,4GHz WLAN I need for IoT devices.

It was fun mixing German and English switching the interface and getting my IPv6 configuration back again.

The next time you have to setup a FRITZ!Box try the ChatGPT voice mode.

Image:FRITZ!Box installation with ChatGPT

Image:FRITZ!Box installation with ChatGPT

Comments [0]

Grafana Domino

Gefana Blackbox Exporter Traveler getStatus Probe

Daniel Nashed – 22 July 2026 20:41:19

Grafana Blackbox exporter is great and supports all kind of probes. This includes HTTPS, TCP probes.
HCL Traveler supports an authenticated end to end status probe, which can be added to the blackbox probe types.
Here is a quick write up. I am adding it to the Domino Grafana GitHub project.

Image:Gefana Blackbox Exporter Traveler getStatus Probe

Image:Gefana Blackbox Exporter Traveler getStatus Probe

blackbox.yml

In the blackbox configuration you first define the probe.
The only a bit tricky limitation is that you have to define the user and password in the file or in separate user/password files. traveler_status: prober: http timeout: 15s http: preferred_ip_protocol: ip4 method: GET headers: Accept-Language: en-US basic_auth: username: traveler-monitor password: change-me fail_if_body_not_matches_regexp: - "Traveler server is available\\." tls_config: insecure_skip_verify: false

prometheus.yml

Once defined you can use the probe and define the targets - job_name: blackbox-traveler metrics_path: /probe params: module: [traveler_status] static_configs: - targets: -https://traveler.example.com/traveler?action=getStatus labels: pod: traveler.example.com namespace: domino relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: blackbox-exporter:9115

Comments [0]

Git Container Registry

Gitea -- Mirror GitHub projects plus a simple to use registry

Daniel Nashed – 22 July 2026 05:08:11

This project is pretty cool. It isn't only a git server implementation but offers to interesting options.

https://about.gitea.com/products/gitea/

Git Repository Mirror

In contrast to some other free editions of Git servers like GitLab community edition, it allows to mirror public Git projects in your own environment.
This is specially interesting when you don't want to let your servers access the internet and want to control which projects are used inside your company.
The mirror option is part of the "migration" feature and allows you to simply mirror any repository.

Simple to use Container Registry

For larger environments probably the Harbor registry would be the better fit.
But it you only want to host a couple of images, the Gitea container registry works pretty well.

The whole Gitea server is very resource optimized and runs from a single Go binary. Either natively or in a container.
You are up in a minute running it as Docker container for example. The configuration is straightforward. And just needs a reverse proxy like NGINX or Traefik for TLS.

For a simple test I set it up without TLS and on port 3000. docker push git.lab.nashcom.de:3000/nashcom/domino:latest

On purpose for the screen shots I used a version without TLS to show it's flexibility.
But in production you should leverage TLS and use port 443.

This setup took me a minute. The Docker image already had the container registry configured out of the box.
The container image is Alpine Linux based and the whole environment is very resource optimized in contrast to some larger projects.

I looked at Gitea earlier and liked it already.
But I never looked for the container registry part, which also works very well.

I have already a small compose stack for Gitea in one of my projects.
But maybe it would make sense to add it to my start script repository including a proxy setup. But it would run behind any load-balancer to offload TLS.

Image:Gitea -- Mirror GitHub projects plus a simple to use registry

Image:Gitea -- Mirror GitHub projects plus a simple to use registry

Comments [0]

USB

Use an USB device like a camera from a remote machine

Daniel Nashed – 19 July 2026 19:23:08

How cool is that. I wanted to use my new camera should work on multiple devices without plugging it into a different machine all the time.

ChatGPT came up with this project https://www.virtualhere.com/
From what I read it is free for one USB device.
It works on multiple platforms. In my case I plug the camera into my M4 and share it with other machines like my Thinkpad.

A camera needs quite some bandwidth and low latency. I my first tests it worked pretty good.

21.07.2026 Update:

When testing it in a meeting there is still some time lag, similar to what you get with playing audio using bluetooth.
At least in my demo showing it to someone over the preview during a meeting causes a delay.
So I would still prefer to use the camera on the same machine. It is still pretty good to have as an option.

-- Daniel

Image:Use an USB device like a camera from a remote machine

Image:Use an USB device like a camera from a remote machine

Comments [0]

Domino

Notes/Domino 14.5.1 FP1 released - Container Image is updated

Daniel Nashed – 16 July 2026 20:43:55

HCL Notes & Domino is available.
I have updated the container image with 14.5.1 FP1 and updated all lab and production Linux servers.

For Windows I am going to wait for the autoupdate repository.

Notes/Domino 14.5.1 Fix Pack 1 Release Notice
https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0132257

What's New in 14.5.1 Fixpack 1?
https://help.hcl-software.com/domino/14.5.1/admin/whats_new_in_1451FP1.html

HCL Notes/Domino 14.5.1 FP1 Fix List
https://ds_infolib.hcltechsw.com/ldd/fixlist.nsf/Public?OpenView&Start=1&Expand=1#1

Happy updating!

Image:Notes/Domino 14.5.1 FP1 released - Container Image is updated

Image:Notes/Domino 14.5.1 FP1 released - Container Image is updated

Comments [0]

Domino container Docker

How to Build the Domino container with a Hotfix.

Daniel Nashed – 14 July 2026 11:25:13

Interim Fixes are technically distributed as a Hotfix and have a HF number per platform.
Those files are available to all customers on maintenance.
Hotfixes in contrast are technically the same but they are distributed by customer for critical issues.

The HCL Domino container community project can install Hotfixes during the container build.
You have to download the file to your software directory or download repository and run the build command specifying the file.
There are currently no checksum checks like for other software, because HCL does not provide those checksums to customers.
Once available it would be easy to add.

Here is an example command-line how to build the image.

The version information is still important to label the image correctly.
But the hotfix file overrides getting it from software.txt. ./build.sh domino 14.5.1 HF51 -hf_download=1451HF51-linux64.tar latest

the versions trigger the Domino software to be downloaded and for labeling
-hf_download= overrides software.txt
latest labels the resulting image as latest. You can also use -tag=xyz to specify your own tag

An alternate way would be to add the file to software.txt. But then you also need to calculate the SHA256 hash and add it.
This override might be the easier path.

-- Daniel

Comments [0]

Grafana Domino

Introducing Domino Operations & Change Management with Grafana Integration

Daniel Nashed – 10 July 2026 22:54:57

I am working on a new project for change management and incidents in combination with Grafana alerting to create incidents and close them automatically.

The integration is implemented using the webhook interface on Grafana alerting side.
The webhook posts to a Lotus Script agent which creates and closes incidents.
This brings together multiple components:

1. Prometheus Domino Statistics --> 2. Grafana Alerting --> 3. WebHook Agent --> 4. Domino Operations & Change Management database (ocm.nsf).

Here is an example for a disk space rule in action.
It plays hand in hand with my Domino Fleet Manager application (DFM / dfm.nsf) which provides SD scrape targets for dynamic metric endpoint scraping.
I am not sure if this is going to be a product or an open source project.

Image:Introducing Domino Operations & Change Management with Grafana Integration

Image:Introducing Domino Operations & Change Management with Grafana Integration

Comments [0]

Domino Prometheus

Introducing DomProbe – The Missing Piece for Prometheus NRPC Monitoring

Daniel Nashed – 5 July 2026 12:52:20

The Prometheus ecosystem already provides excellent monitoring components.
The standard Blackbox Exporter is perfect for probing HTTP, HTTPS, TCP, ICMP and many other network protocols, while exporters such as node_exporter and DomProm provide detailed operating system and Domino server metrics.
But there has always been one missing piece: Native NRPC monitoring for HCL Domino.
That's exactly why I created DomProbe.

Why NRPC Monitoring Matters

Many critical Domino functions depend on NRPC: Notes client connectivity, replication, clustering, administration, mail routing, and server-to-server communication.
A Domino server may still answer HTTPS requests while NRPC is no longer functioning correctly. Likewise, a simple TCP connection to port 1352 only tells you that something is listening—it does not confirm that Domino is actually able to process NRPC requests.
DomProbe performs a real NRPC transaction using the native Domino C API. It connects to the target server, measures request and response latency, reports the Domino server state, and can optionally verify that a specific database can be opened.
This provides a much more meaningful availability check than simply testing whether port 1352 is open.

A Natural Extension to the Prometheus Ecosystem

DomProbe follows the same architecture as the Prometheus Blackbox Exporter.
Prometheus sends an HTTP request to DomProbe, which performs the NRPC probe and returns the results in standard Prometheus metrics format.
Existing Prometheus and Grafana dashboards, alert rules, and scrape configurations work exactly as expected—the only difference is that the probe itself understands Domino.
Typical metrics include:

NRPC availability
Domino server state (Available, Restricted, Busy, Not Reachable)
Client-to-server latency
Server-to-client latency
Total probe duration
Optional database open verification and timing

Combined with DomProm and node_exporter, this finally completes the monitoring stack for Domino environments.

Monitor Your Entire Domino Infrastructure

Although DomProbe runs as a native Domino server task on Linux, it is not limited to probing the local server.
A single DomProbe instance can probe any Domino server reachable via NRPC.
For example, you might deploy one DomProbe instance in each data center:

A Domino server in Data Center A probes all production servers in its own site as well as selected servers in Data Center B.
Another Domino server in Data Center B performs the same checks in the opposite direction.

This verifies much more than whether the target servers are running. It also confirms that NRPC communication between Domino servers is actually working.
Routing problems, firewall issues, VPN failures, or replication connectivity problems become immediately visible from the perspective of another Domino server.
Since Prometheus simply calls the /probe endpoint with different target parameters, a single DomProbe instance can monitor dozens or even hundreds of Domino servers without requiring additional software on every monitored system.

Lightweight by Design

DomProbe intentionally focuses on availability monitoring.
It does not try to replace detailed monitoring solutions such as DomProm or node_exporter.

Instead, the components complement each other:

Prometheus Blackbox Exporter — HTTP, HTTPS, TCP, ICMP, DNS and other standard protocols
DomProbe — Native Domino NRPC availability and optional database access
DomProm — Domino server statistics, replication, mail routing, performance and health metrics
node_exporter — Operating system metrics

Together they provide a complete monitoring solution for HCL Domino.

Native Domino Integration

DomProbe runs as a native Domino server task on Linux and integrates directly with the Domino runtime using the Domino C API.
The task exposes familiar Prometheus endpoints such as /probe, /metrics, and /health, making integration with existing Prometheus environments straightforward.

Open Source

DomProbe closes one of the last remaining gaps in the Prometheus monitoring ecosystem for HCL Domino by bringing native NRPC probing to Prometheus.
If you're already using Prometheus and Grafana to monitor your Domino infrastructure, DomProbe adds the missing visibility into the protocol that powers Domino itself.

https://github.com/nashcom/domino-blackbox-exporter

Comments [0]

notes.ini

Meet nshini – A Notes.ini Editing and Conversion Tool

Daniel Nashed – 5 July 2026 10:39:00

If you've administered HCL Domino long enough, you've probably edited notes.ini more times than you can count. It looks like a simple text file—but it isn't.

notes.ini is stored in LMBCS, a Lotus-specific character encoding.
Modern editors expect UTF-8. While ASCII-only settings are usually safe, any non-ASCII value—passwords, international characters, or localized paths—can be silently corrupted simply by opening and saving the file in a standard editor.

That's exactly why I created nshini after working with another HCL partner on one of his support tickets.
In his case support asked him to make changes to the notes.ini which broke umlauts.

nshini transparently converts notes.ini between LMBCS and UTF-8 using the official Domino C API. You edit a normal UTF-8 file in your preferred editor, and the tool safely converts everything back when you're done.

This makes working with notes.ini much more comfortable on both clients and servers.
When changing settings on a server you can always use "set config".

On Windows, nshini integrates seamlessly with Notepad++, allowing you to use one of the best text editors available, complete with syntax highlighting, search, and visual diff support.
On Linux, it works equally well with your favorite editor while providing clean UTF-8 output for scripts and command-line tools.

Beyond editing, converting notes.ini to UTF-8 opens the door to modern tooling. Configuration can be compared with standard diff tools, processed by scripts, indexed, or even analyzed by AI workflows without worrying about legacy character encoding.
nshini also provides commands to read and update notes.ini variables through the Domino API, making it useful for automation as well as interactive administration.

The project is open source and available on GitHub:

GitHub: https://github.com/nashcom/nshini

Comments [0]