Using Virtual Machines and Linux container for software testing

Now that Notes and Domino 14.5.1EA1 shipped this week some admins & developers are looking for options to test out the new version without impacting their production environment.

This is more a challenge on client side then on server side.

If you have a notebook or Macbook where you can install software, there are a couple of good (and free options).
In a corporate environment often the only option is to use a remote VM.

But there are some good client choices if one of those tools can be installed in your environment.

Windows

For a quick test of software on Windows the Windows Sandbox is a very simple to use solution.
It can be configured with volume mounts and share the already running resources of your host Windows.
There can be only one Sandbox at a time and when you should down the Sandbox all data not hosted on a mount is gone.
But often for testing this is exactly what you want.

https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/


VMware Workstation Pro 25H2

VMware workstation is back in business and has a new version.
It is free for private and commercial use. You can install multiple VMs if you have sufficient resources and have the full flexibility of snapshots.

https://www.vmware.com/products/desktop-hypervisor/workstation-and-fusion


MacOS

On the Mac you have multiple options

VMware Fusion is one of them.
But there is also UTM


UTM

https://mac.getutm.app/

Both can be used to install either a MacOS or Windows.

For Windows VMs on older Intel Macs you would use standard Intel/AMD64 Windows.
For Apple Silicon you should always pick the Windows ARM edition -- which works well for Notes and Domino.


Avoid running Domino on Linux on Apple Silicon

Running Linux on the Mac sadly only works well with Intel hardware.
There are still issues with the JVM shipped with Domino.
This is true for native Linux and any kind of container environment like Docker and Rancher Desktop.


Domino servers on Linux

For Linux there are a couple of desktop options.
You can run it in the VM infrastructure of your choice like VMware Workstation Pro.

But there are more options to choose from.


Windows Subsystem for Linux (WSL).

One great platform is WSL.
It is part of Windows and well integrated with Windows.

https://learn.microsoft.com/en-us/windows/wsl/install

You can access Windows disks using a standard enabled mount (e.g. /mnt/c) or the other way round access Linux volumes via Windows explorer.

Beside running a native Domino server on WSL you can also install a Docker host on WSL to run a Domino container.


Running Domino in Containers on Linux

This is one of the easiest and most flexible options.

The Domino container project allows you to build a standard or customized containers -- also with version 14.5.1 EA1.

You can run container images on

• WSL based Linux host with Docker or Podman
• Docker Desktop
• Rachner Desktop

https://www.docker.com/products/docker-desktop/
https://rancherdesktop.io/

Docker for Desktop is free for smaller companies, but commercial for larger companies.
But WSL and Rancher Desktop are great options to use as well.

Unless you are using Docker Desktop or Rancher Desktop for other work, it would make probably most sense to look into WSL.

• Comments [0]

FIX Domino Container Image: tzdata was missing in UBI 10 minimal

The container image uses Redhat UBI 10 minimal as the base image.
In version 9 it contained tzdata by default.

The newer version does not contain it and the build script did not install it.
I have added logic to try to always install tzdata to make sure this never happens again for any distro change.

But I also decided to go back to have the normal not the minimal image as the default.
Admins can still switch back to the minimal using -from=ubi-minimal

The standard UBI image is the safer bet and the resulting image isn't that much bigger.

The develop and the main branch are both updated.

This only affected the recent builds where UBI 10 minimal was used.
The issue occurred was that the timezone was not switched inside the container even specifying your timezone at build time.

See details here --> https://opensource.hcltechsw.com/domino-container/howto_tz_locale/

If you are on UTC there isn't any issue at all. But for everyone else this is an important fix.

-- Daniel

• Comments [0]

Leveraging the potential of Domino CertMgr + What’s new in 14.5.1

Domino CertMgr introduced in Version 12.0 is one of the modern corner stones of Domino security.

This includes the TLS Cache and certstore.nsf which is used for many other security features today.

It is built on open standards and can be customized and leveraged outside Domino.
Certificates are stored in PEM format in text fields.
When generating exportable keys, they are stored in plain text PEM format encrypted with the modern (PKCS#8 + PBKDF2 + AES-256-CBC) encryption.

CertMgr supports multiple flows:

• Manual import
• ACME protocol with HTTP-01 and DNS-01 challenges
• Import/Export
• MicroCA

See details her --> https://opensource.hcltechsw.com/domino-cert-manager/certificate_flows/


Those flows can be mixed and matched and can be also extended for your own needs.
Specially the manual flow is designed to allow to export CSRs to for example send it to an external CA.
And import certificates once issued by an external CA.

The past operation can be automated by just writing the certificate into the right field and setting the status of the TLS Credentials document to the right state.

Details of the TLS Credentials document are documented here --> https://opensource.hcltechsw.com/domino-cert-manager/tls_credentials_anatomy/

Once created exportable TLS Credentials can be used outside Domino and can be even automatically updated querying certificates remotely from CertMgr.
See details here --> https://opensource.hcltechsw.com/domino-cert-manager/deploying_outside_dominio/

For exporting and importing TLS Credentials there is a script lib with a documented LS2SCAP call-out to use it for your own export and import applications.

Auto filter complete, auto sort and auto complete functionality

All mentioned flows support the same "automatical" certificate handling.
In most applications you have to specify the right order, specify exactly the certificates needed and add the root and intermediate certificates.

With Domino CertMgr you don't need to care about any of this manually.

The certificate chain provided is automatically sorted
The sorting happens from checking the public key to match it against the leaf certificate.
From the leaf certificate the chain is built backwards up to the root certificate.
Any certificates which don't match the chain or are duplicated are automatically filtered out.

If the chain is not complete CertMgr looks up trusted roots stored in certstore.nsf trust store.
This works for root certificates and also for intermediate certificates.
The resulting chain should be always complete and in the right order.

This functionality is available since version 12.0 and available for all flows without separate configuration.


Using TLS Credentials outside of Domino

When using Domino managed TLS Credentials outside Domino it becomes essential to monitor expiration.
Certificates in certstore.nsf are monitored by CertMgr automatically. Certificates are updated where the flow allows it and statistics are updated with number of certificates in green, yellow, red state.

For external used TLS Credentials there is a separate health check by URL, which daily checks all configured URLs, updates statistics and optionally sends one summary mail with warning and errors:

https://help.hcl-software.com/domino/14.5.0/admin/secu_certificate_url_health_check.html

All the functionality described is intended to simplify certificate management and make Domino a first class citizen in certificate management.

New functionality in 14.5.1 EA1
There isn't much to add, but in 14.5.1 EA1 there are some smaller enhancement based on customer feedback.

e-mail attribute in manual and ACME flow

Some customers require an e-mail attribute in the common name for their internal certificate flows.
The field was always present since 12.0 but has not been exposed in the UI,
Now with 14.5.1 it is an official feature of CertMgr for manual flows and also the ACME protocol (even most public ACME servers ignore it, but internal customer flows might need it).

Custom Expiration in MicroCA flow

The Domino MicroCA started as a very simple private CA for the AppDevPack.
But meanwhile it is used for JConsole Certs and can be leveraged for Domino IQ and other flows.

It is very useful for internal certificates for example behind a reverse proxy.
Because certificates are automatically renewed, distributed by replication via certstore.nsf and instantly updated by the TLS cache, they are a very good fit for those type of scenarios.
But the MicroCA does not provide any CRL end-point or OCSP option.

To comply with modern requirements the MicroCA now supports custom certificate expiration. So you could set it even as low as 3 days today.
The MicroCA flow would auto renew it as soon the renewal interval has been reached.

There is a new field on the TLS Credentials form Validity period shown in MicroCA mode.
The internal field was already present since 12.0. But the field has now exposed in the UI and is officially supported.

Subject Key Identifier (SKI) and Authorized Key Identifier for MicroCA

Those have been two missing extensions expected from modern CAs.
They have been added in 14.5.1 as well to comply with modern requirements.

New certificates would get those extensions automatically beginning with 14.5.1 EA1.
A new MicroCA would get a SKI when created with 14.5.1 too.
If you have special requirements and integration ideas let me know.

-- Daniel

• Comments [0]

Another look into Rancher Desktop for Domino containers

The Rancher Desktop K3s meanwhile the Dashboard they integrated looks like the GUI of Rancher.

I just retested container builds using nerdctl to make sure the Domino Container Build is still working.
Again this is Intel only. Apple Silicon is still an issue due to the emulation.

Building via nerdctl on Rancher Desktop is slower but works.
I would recommend building on docker and pushing to a registry.

But you can use the embedded container store in the k8s.io namespace on Rancher Desktop.

I would only use Rancher Desktop for Domino if you are using it for other purposes anyhow or need a free desktop K8s environment.
Docker would be the easier approach and is free as long you are not working for a larger company.

The container project looks at all different platforms to provide a choice and learn from different platforms.
nerdctl to build instead of Docker or Podman might be a challenge. But it works in general.

-- Daniel





Rancher Desktop 1.20.1 Dashboard

• Comments [0]

Domino SMTP with TLS -- Make sure you always have a RSA TLS Credential

Today I had a very weird problem in our DNUG Lab Domino environment.
Mails did not route any more to certain destinations with a weird error message.
After turning on SSL Handshake Debug it turned out the certificate was sent and the session was terminated afterwards.

It turned out the other side used RSA ciphers and expected a RSA cert to verify.
But the server only had a ECDSA TLS credentials configured.

The solution was to just get a RSA key in paralle. Domino CertMgr can handle RSA and ECDSA keys in parallel since Domino 12.0.


26.11.2025 14:52:20,41 SSL_Handshake Enter>> Current Cipher ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030)
26.11.2025 14:52:20,41 SSLProcessProtocolMessage> Record Content: Handshake (22)
26.11.2025 14:52:20,41 SSLProcessHandshakeMessage Enter> Message: ServerHelloDone (14) State: HandshakeHelloDone (9) Key Exchange: 15 Cipher: ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030)
26.11.2025 14:52:20,41 SSLProcessHandshakeMessage Exit> Message: ServerHelloDone (14) State: HandshakeHelloDone (9) Key Exchange: 15 Cipher: ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030)
26.11.2025 14:52:20,41 SSLAdvanceHandshake Enter> Processed: ServerHelloDone (14) State: HandshakeHelloDone (9)
26.11.2025 14:52:20,41 SSLAdvanceHandshake> A certificate has been requested
26.11.2025 14:52:20,41 SSLAdvanceHandshake> An X509 certificate has been requested
26.11.2025 14:52:20,41 SSLAdvanceHandshake> We have 3 certificate(s)
26.11.2025 14:52:20,43 SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeCertificate
26.11.2025 14:52:20,43 SSLEncodeCertificate> Generating a certificate message with 3 certs
26.11.2025 14:52:20,43 SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeKeyExchange
26.11.2025 14:52:20,43 SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeCertificateVerify
26.11.2025 14:52:20,43 SSLEncodeCertificateVerifyTLS12> Signing CertificateVerify using RSAWithSHA256
26.11.2025 14:52:20,43 SSLSendAlert> Sending an alert of 0x0 (close_notify) level 0x2 (fatal)
26.11.2025 14:52:20,43 SSL_Handshake> After handshake2 state SSLErrorClose (2)
26.11.2025 14:52:20,43 SSL_Handshake> Exit Status = -5000
26.11.2025 14:52:20,43 int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone]
26.11.2025 14:52:20,43 SSL_Handshake Enter>> Current Cipher ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030)
26.11.2025 14:52:20,44 SSL_Handshake> After handshake2 state SSLErrorClose (2)
26.11.2025 14:52:20,44 SSL_Handshake> SSL Error: -6997
26.11.2025 14:52:20,44 int_MapSSLError> Mapping SSL error -6997 to 4096 [SSLUnknownErr]
26.11.2025 14:52:20   Unexpected TCP/IP error func: 001Dh error Notes: 1C5B, NTI: 1000h, Stack: 00000000h
26.11.2025 14:52:20   SMTPClient: SSL handshake error: 1C5Bh
26.11.2025 14:52:20   Router: No messages transferred to acme.de (host secure-mail02.acme.de) via SMTP: Unexpected TCP error.  See the Notes log file on this system for error code.

• Comments [0]

Notes, Domino, Traveler 14.5.1 EA1 what’s new and forum access

This morning I got a question in an old EAP blog post about how to access the forum.
There is a new forum for each Eearly Access Program. Here is the link to the 14.5.1 forum:

https://registration.hclpartnerconnect.com/domino1451forum.nsf/allDocuments.xsp

If you have been registered for an existing EAP, your account should still work.

Here is also the link to the TN with entry points to What's new, which also lead you to the updated documentation.

https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0126585


-- Daniel

• Comments [0]

Notes, Domino, Traveler 14.5.1 Early Access 1 is available

HCL Domino (r) Server (64 Bit) (Build V1451_11212025 for Linux/64)

I have just updated the HCL Domino Community Container image.
This time the Early Access web-kit are properly linked into the build menu.
But you can continue to use the command line option to specify it.

The menu has an advantage. It remembers your saved configurations and you can pick additional software packages.

When you select Domino 14.5.1 EA1, Traveler will also flip automatically to the corresponding version.
Changes are pushed to the develop and main branch. You just need to "git pull" the changes and run a new ./build.sh as I am doing for all of my lab environments right now...


HCL Domino Version
------------------

(1)  14.5FP1
(2)  14.0FP4IF1
(3)  12.0.2FP7IF1

(4)  14.5.1EA1 (Beta)

Select Domino version  [0] to cancel?



HCL Domino Container Community Image
------------------------------------

(D)  HCL Domino          [X]  14.5.1EA1
(O)  OnTime              [ ]
(V)  Verse               [X]  3.2.6
(T)  Traveler            [X]  14.5.1EA1
(N)  Nomad Server        [X]  1.0.17
(L)  Language Pack       [ ]
(R)  REST-API            [ ]
(A)  C-API SDK           [ ]
(P)  Domino Leap         [ ]

(M)  Prometheus          [X]  domprom 0.9.2 & Node Exporter 1.9.1
(G)  Borg Backup         [X]  1.4.1
(X)  nshmailx            [X]  1.1.0

• Comments [1]

Updated HCL Domino Container Community project base image list

Now that most vendors updated their distributions to a new major version, I looked over the list and updated the documentation.
https://opensource.hcltechsw.com/domino-container/concept_environments/

The project comes with short names for each of those platforms.
If you use those short names listed in the table the script turns them into the full base image names and displays also the code name of the project.

The list is now updated with the latest versions:

• Red Hat Enterprise Linux 10 (Coughlan)
• SUSE Leap / SUSE Enterprise 16.0
• Rocky Linux 10.0 (Red Quartz)
• AlmaLinux 10.0 (Purple Lion)
• CentOS Stream 10 (Coughlan)
• Oracle Linux Server 10

-- Daniel

• Comments [0]

SUSE Enterprise 16 released

SUSE Enterprise 16 (and openSUSE Leap 16) shipped this month.
I looked at it already during beta and there are no surprises from kernel nor glibc level.

Kernel 6.12.0
glibc 2.40

In contrast to Debian 13, the glibc version is still in the range that works with Domino 14.5 and the currently shipping Java 221 version.

There are a couple of interesting enhancements and the new installer is completely reworked.
Here is a good blog post --> https://www.suse.com/c/what-is-new-in-suse-linux-enterprise-server-16-0/

SUSE Enterprise 16 isn't tested by HCL yet. This usually happens with the next fixpacks and major releases.
But there are no surprises to expect and it already has community support.

It's probably too new to be used in production environments.
But I have added the new enterprise base image and also openSUSE Leap 16.0 to the HCL Community project.

C-API development should remain on Redhat 9.x.

For C-API Development I would still recommend to use a Redhat UBI 9.x image, because this would align with HCL's recommendation and ensure applications work on all supported Linux distributions.
Compiling with a later glibc causes the glibc to be the minimum version to run the binary.
A container image is a great way to keep a C-API development at the recommended version.
The community project supports different C-API versions and base images.

-- Daniel

• Comments [0]

Ubuntu Autoinstall -- No touch installation

It took me half a day to get started. But once I got a round tip it is really pretty cool.
Ubuntu has a true autoinstall which incorporates Could Init configuration options as part of it.

https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html

I first started with a standard Ubuntu ISO + another small ISO with the configuration on a Proxmox VM.
Resetting the snapshot on Proxmox was very helpful.

Once I got the ISO setup working, I switched over to a physical small Lenovo box booting from a USB stick.
The USB stick setup is even more simple. You can just write a /autoinstall.yaml into the root of the stick.

With this setup I know have the base for building a Domino environment from scratch on Ubuntu.

Below is an example autoinstall.yaml I wrote up over the weekend.
One of the highlights in this configuration is the root ZFS configuration.

The following setup installs a minimal server with essential configuration and SSH.
On purpose I am specifying a static IP configuration. DHCP would even more simple but not what I want for a server.

The devil is in the detail. But if you want to try it out on your own, my sample configuration should give you are starting point.
My new GitHub repository will have more examples including ISO command lines to build the ISO.

-- Daniel


autoinstall:
version: 1

locale: en_US.UTF-8
timezone: Europe/Berlin
keyboard:
layout: de
variant: nodeadkeys

identity:
hostname: nsh-dls01
username: notes
password: "$6$j9BDc..."

ssh:
install-server: true
allow-pw: false
authorized-keys:
  - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AA...

network:
version: 2
ethernets:
  default:
    match:
      name: "en*"
    dhcp4: no
    addresses:
      - 192.168.1.42/24
    routes:
      - to: default
        via: 192.168.1.1

    nameservers:
      addresses:
        - 1.1.1.1
        - 1.0.0.1

storage:
layout:
  name: zfs
  sizing-policy: all
  match:
    size: largest

# could be also be only but we want all: security
updates: security
apt:
preserve_sources_list: false

source:
id: ubuntu-server-minimal

packages:
- openssh-server
- vim

user-data:
disable_root: true
package_update: false
package_upgrade: false

write_files:
  - path: /etc/ssh/sshd_config.d/99-hardening.conf
    content: |
      PasswordAuthentication no
      ChallengeResponseAuthentication no
      UsePAM yes

runcmd:
  - systemctl restart ssh
  - zfs set atime=off rpool
  - zfs set recordsize=32K rpool

• Comments [0]