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

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.

• Comments [0]

Use an USB device like a camera from a remote machine

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

• Comments [0]

Notes/Domino 14.5.1 FP1 released - Container Image is updated

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!

• Comments [0]

How to Build the Domino container with a Hotfix.

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]

Introducing Domino Operations & Change Management with Grafana Integration

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.













 

• Comments [0]

Introducing DomProbe – The Missing Piece for Prometheus NRPC Monitoring

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]

Meet nshini – A Notes.ini Editing and Conversion Tool

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]

Domino NRPC Proxy – A Modern Proxy Platform for Domino

The Domino NRPC Proxy project started with a simple but ambitious goal: provide a modern, production-ready proxy for Domino NRPC connections that integrates naturally with Docker and Kubernetes.

While traditional TCP proxies can forward NRPC traffic, they have no understanding of the Domino protocol itself.
At the heart of the project is a custom NGINX Stream module that understands the initial Domino NRPC handshake and enables intelligent routing based on the requested Domino server.
Since then, the project has grown well beyond its original scope.
Today it provides a complete proxy platform for Domino, combining NRPC routing, HTTPS reverse proxy support, generic stream proxying.


Key Features

• Custom NGINX Stream module for Domino NRPC
• Intelligent NRPC routing based on the requested Domino server
• HTTPS reverse proxy support
• Generic TCP stream proxy support
• Optional ACME certificate management using LEGO
• Dynamic configuration generation from templates
• Zero-downtime configuration updates
• Automatic certificate reload
• Native Docker and Kubernetes support
• Docker Secrets and Kubernetes Secrets integration
• Environment variable driven configuration
• Own Prometheus metrics endpoint including details about configuration status

The container build compiles NGINX and the stream module. The Image can be build with the included build script. The image is also available on the GitHub registry as part of the GitHub project.


Intelligent NRPC Routing


The Domino NRPC Proxy is much more than a TCP forwarder.
The project includes a custom NGINX Stream module developed specifically for Domino NRPC. The module understands the initial NRPC protocol exchange and extracts the Domino server name requested by the Notes client.
This information is then used to make an intelligent routing decision before forwarding the connection to the appropriate back-end Domino server.
The entire process is completely transparent to the client and requires no changes to existing Notes or Domino installations.

This makes it possible to:

• Publish a single NRPC endpoint for multiple Domino servers.
• Route Notes clients automatically to the requested server.
• Hide backend Domino servers inside private Docker or Kubernetes networks.
• Dynamically route connections as infrastructure changes.
• Simplify load balancer configurations.
• Scale from a single Domino server to large Domino deployments.

This capability is particularly valuable in Kubernetes environments, where Domino servers are represented by services and pods whose network topology may change over time.


HTTPS Reverse Proxy


Although NRPC remains the primary focus of the project, most Domino environments also expose HTTP and HTTPS services.
The Domino NRPC Proxy now includes a fully integrated HTTPS reverse proxy based on NGINX.

Features include:

• HTTPS reverse proxy
• HTTP to HTTPS redirection
• Multiple virtual hosts
• Configurable upstream servers
• Dynamic configuration generation

Running both NRPC and HTTPS within the same proxy simplifies deployments while providing a consistent operational model.


Generic Stream Proxy Support


The custom NRPC module is one part of the project.
The surrounding infrastructure has been designed to support generic TCP stream proxying as well.
This allows the same container to proxy additional TCP services using the same configuration framework, making the project useful beyond Domino-specific scenarios.


Designed for Docker and Kubernetes


The project was designed from day one with containers in mind.
Whether you're deploying a single Domino server with Docker Compose or operating a large Kubernetes cluster, the same container image can be used without modification.
Configuration is generated automatically during startup, allowing deployments to be driven entirely by environment variables and secrets.
The result is a container that fits naturally into Infrastructure-as-Code workflows and automated deployments.


Dynamic Configuration Templating


Maintaining multiple static NGINX configuration files quickly becomes difficult as deployments grow.
Instead, the Domino NRPC Proxy gene7rates its configuration dynamically from templates.

The templating system supports:

• HTTP configuration
• Stream configuration
• Environment variable substitution
• Optional feature enablement
• User supplied templates
• Deployment specific customization

This approach keeps the container image generic while allowing extensive customization without rebuilding images.


Zero-Downtime Configuration Updates


Container environments are dynamic by nature.
Services may be added, removed or updated while the proxy continues running.
Whenever configuration changes are detected, the proxy automatically:

• Generates the new configuration
• Validates it using nginx -t
• Atomically replaces the active configuration
• Reloads NGINX without interrupting existing client sessions

Existing NRPC and HTTPS connections continue uninterrupted while new connections immediately use the updated configuration.


Automatic Certificate Management


The latest versions add optional integrated ACME support using the excellent LEGO client.
The proxy can automatically request and renew certificates from Let's Encrypt or any RFC 8555 compatible ACME provider.

Supported features include:

• Let's Encrypt Production and Staging
• Alternative ACME providers
• HTTP-01 challenge support
• Automatic renewals
• Environment variable based configuration
• Automatic NGINX reload after successful renewal
• Support LEGO environment configuration

The implementation also handles the initial bootstrap process, allowing completely unattended deployments.


Automatic Certificate Reload


Certificates may also be provided by external certificate management solutions.
The Domino NRPC Proxy automatically detects updated certificates and reloads NGINX without requiring container restarts.
This enables continuous certificate management without downtime or maintenance windows.


Secret Integration


Security is an important design goal.
Sensitive configuration data should never be embedded in container images.

The Domino NRPC Proxy provides native support for:

• Docker Secrets
• Kubernetes Secrets

Certificates, private keys, bearer tokens, API credentials and other sensitive configuration can be securely mounted while remaining fully compatible with the templating framework.


Built Around Automation


One of the guiding principles throughout the project has been automation.
A modern infrastructure component should require as little manual configuration as possible.
The Domino NRPC Proxy therefore focuses on:

• Convention over configuration
• Environment variable driven deployments
• Dynamic configuration generation
• Automated certificate management
• Automatic configuration validation
• Zero-downtime updates

The result is a proxy that is equally at home in a simple Docker installation or a fully automated Kubernetes platform.


Part of the Domino Infrastructure Ecosystem


The Domino NRPC Proxy has become one of the core building blocks of a larger Domino infrastructure ecosystem.
It integrates naturally with projects such as:

• Domino Fleet Manager
• Cube Control
• CertMgr
• Domino monitoring components

Each project is designed to work independently, while together they provide a modern platform for deploying, managing and operating HCL Domino environments.


Open Source


The Domino NRPC Proxy is available as an open source project on GitHub:
https://github.com/nashcom/domino-nrpc-proxy
The project has evolved considerably since its first release and continues to grow with new features and deployment options.
If you're running Domino in Docker, Kubernetes, or simply looking for a modern proxy platform for Domino services, I hope you'll find it useful.

• Comments [1]

Behind the Scenes: Linux Install Fest Lab at Engage 2026

Bill, Matijn and I did three hands on sessions at Engage.
If you wondered how we have been doing it. Here is how this worked and it could be leveraged for own workshops.
Using cloud hosted servers can make a lot of sense. And it is very cost efficient.

Hetzner is a provider with a very modern and easy to use GUI. But they also have a great API to create and manage servers.
I am using them for years for DNUG and other events. And I would make it available for friends & family.

Recently Hetzner moved their separate DNS API into the central cloud API -->https://docs.hetzner.cloud/reference/cloud
I took this opportunity to implement most of this API in an existing Lotus Script class (Script Lib) and read the full inventory for a project to manage it from a Notes database.
Each database would match 1:1 a Hetzner project. We created a private network for the project and offered services like NFS based file mounts to provide workshop data.

The database is mainly designed for lab setups with the same server configuration used for all servers.
A profile document is used to define the type, size, location etc of the server.
What I also added is support for cloud.init configurations.

For our servers I just needed a host name. The e-mail address is used for an integrated mail workflow to notify users -- including sending them their server name and IP.
When creating a new server also a DNS record is created and also the IN-ARPA entry is set properly.

Creating a new server just takes a couple of seconds. In our case you have to wait a moment because we installed additional software, configured a NFS mount and rebooted the machine.

Because we did not expect everyone to register ahead of time thru the official Engage registration processing a mail flow from the Leap App to our database, I added a registration form to feed in new server requests directly.
The slides had a registration QR code to fill in the registration code.

This gave us a very flexible way to generate new servers on-the-fly.

The whole lab setup was done in a reusable way. So all the time spent on it wasn't just for this one conference.
And I will extend it over time for other use cases. The Lotus Script Lib is the core of the application, but with my additions also reading the inventory could be re-used in other areas.

This is a good example use case for a Notes database. It would probably have taking me much longer with most other approaches.

See some details below. I also added label support and to specify firewalls directly or via labels.
The could.init replaced my earlier Ansible scripting I used to customize servers after they are created.
But I also added a Ansible host list export and we used the same SSH key for all servers beside the management server which hosted the file shares.

-- Daniel

         

• Comments [6]

Domino On Proxmox LXC Containers Part II

As mentioned at Engage, I am working on Domino container deployments on Proxmox.
The first deliverable was a new build option for the container image to create two components:

• A LXC template which can be cloned into a new LXC container using pct command line
• A /opt volume which is read-only mounted into each container

You can see from the configuration dump below how this would look like.
The second deliverable is a management script "dompct" which allows to create and manage LXC containers.
I added some screen shots below.

The new script is already part of the develop branch of the Domino Start script, but I am still enhancing and testing it.
It comes with configuration profiles which can be managed and assigned to servers when created.

This includes ZFS volumes assigned to LXC containers -- as you can also see from the example below.
The new option build.sh -pct and the new dompct tool standardize and simplify Proxmox LXC deployments.

There isn't full documentation yet in the GitHub project. But dompct has command line help already.
You can either use command-line parameters or the menu.
The menu prompts to select a container if not specified. Or a profile if not specified.
It also prompts for the hostname when creating a new container and the hostname is not specified at command-line.

The tool can be used interactively or for automated provisioning. That's why I also added -json for output.

The Proxmox LXC is a first implementation and I mainly wrote it for one customer who is actively looking into Domino on Proxmox deployments.
But I wanted to make it available already for feedback.


--- Configuration output ---

--------------------------------------------------------------------------------
Config LXC 800
--------------------------------------------------------------------------------

arch: amd64
cores: 4
features: nesting=1
hostname: domino-01
memory: 8192
mp0: /rpool/data/domino-opt-20260419-1053,mp=/opt,ro=1
mp1: /rpool/data/subvol-800-domino-local,mp=/local
mp2: /rpool/data/subvol-800-domino-nsf,mp=/local/notesdata
mp3: /rpool/data/subvol-800-domino-translog,mp=/local/translog
mp4: /rpool/data/subvol-800-domino-daos,mp=/local/daos
mp5: /rpool/data/subvol-800-domino-backup,mp=/local/backup
net0: name=eth0,bridge=vmbr0,hwaddr¼:24:11:75:9A:30,ip=dhcp,type=veth
ostype: ubuntu
rootfs: local-zfs:subvol-800-disk-0,size=20G
swap: 0
tags: domino
unprivileged: 1

description:
HCL Domino server 800









--- Configuration profile example ---


# Domino LXC configuration - default

PCT_TAGS=domino
PCT_DATA_POOL=rpool/data
PCT_DAOS_POOL=rpool/data
PCT_TRANSLOG_POOL=rpool/data

PCT_TRANSLOG_SIZE_GB=5
PCT_NSF_SIZE_GB=100
PCT_BACKUP_SIZE_GB=100
PCT_DAOS_SIZE_GB=100

PCT_RAM_GB=8
PCT_SWAP_GB=0
PCT_CPU=4

env_DOMSETUP_ENABLED=1
env_NODE_EXPORTER_OPTIONS=default


PCT_NET0_TEMPLATE=name=eth0,bridge=vmbr0,ip=%PCT_IP%/24,gw=192.168.96.98



--- Command Line Parameters ---


dompct - LXC Container Control Utility

Usage:

./dompct.sh <command> [VMID] [options]

Commands:

create              Create new container
start               Start container
stop                Stop container
status              Show container status
enter | bash        Enter container shell
config              Show container configuration
update              Update container
destroy             Destroy container
about               Show container information
profile             Select or apply profile
list                List containers
KILL                Force kill container
KILL-WITH-DISKS     Kill container and remove disks

Global Options:

-profile=<name>     Use profile (from ~/.dompct/*.cfg)
-host=<name>        Set hostname
-hostname=<name>    Same as -host
-tags=<tags>        Set Proxmox tags (comma-separated)
-ip=<ip>            Assign IP address
-description=<txt>  Set container description
-opt-vol=<opts>     Volume options (advanced)

Output Options:

-json               Output in JSON format (where supported)

Arguments:

VMID                Numeric container ID (required for most commands)

Examples:

./dompct.sh list
./dompct.sh start 800
./dompct.sh create -profile=mail
./dompct.sh profile
./dompct.sh destroy 800

Notes:

- If VMID is omitted, interactive menu may be used
- Profiles are stored in: ~/.dompct/

• Comments [238]