If you are running Sametime V11 or earlier and want to upgrade to Sametime 12, you have two options. They start from scratch with a clean install (sometimes it’s worth it) or migrate existing Sametime to the new Sametime 12. I have prepared a short guide on how to migrate the contact list (vpuserinfo.nsf) of your users and I have also added the option to convert from native Domino Directory to LDAP, which is a condition for migration to Sametime 12.

In my last post, I talked about how I implemented a partial Jakarta NoSQL driver using the AppDev Pack as a back end instead of the Notes.jar classes used by the primary implementation. Though the limitations in the ADP mean that it lacks a number of useful features compared to the primary one, it was still an interesting experiment and has the nice side effect of working with essentially any Java app server and Java version 8 or above. Beyond the Proton API calls, the driver brought up the interesting topic of handling authentication. Proton has three ways of working in this regard: Anonymous, which is what you might expect based on how that works elsewhere in Domino. This is easy but not particularly useful except in specific circumstances. Client certificate authentication, where you create a TLS keychain for a given user and associate it with a Directory user (e.g. CN=My Proton App/O=MyOrg), and then your app performs all operations as that user. This is basically like if you ran a remote app with NRPC using a client Notes ID. Act-as-User, which builds on the above authentication by configuring an OAuth broker service that can hand out OIDC tokens on behalf of named users. This is sort of like server-to-server communication with the "Trusted Servers" config field in the server doc, but different in key ways.

No IT solution is delivered using code written solely by the solution provider. There is always dependent code written by a third party. Dependency management tooling has proliferated in every technology sector to support this. And every solution includes an implicit assumption that the dependent code will continue to work as it does and provide whatever the consumer requires. And the brutal truth for consumers is that the authors of your dependencies did not write their code knowing your requirements up front. Whether or not it fits your implementation falls in the realm of “caveat emptor”. If it doesn’t, if you need an enhancement or you find a bug, your priorities may or may not align with the priorities of the owners of that dependency. With a product, you’re just one paying customer. With open source, you’re just one consumer - not even a customer.

Four weeks on from the last code drop HCL today released 12.0.2 EAP Drop 5Headline items for me: Domino Restyler is available out of box in the Notes client as opposed to the last drop in Nomad. (Note: a very informative getting started video with Domino Restyle from the Cross Canada Collaboration User Group is here ) We get a new version of the Admin/Designer 64 bit client. (that’s not to say we don’t get versions of all other client, we do) The Notes client on Mac runs on 12.6 Monterey (though won’t perfectly until GA)

If you are using DOTS in Domino 12.x, you might have seen some NullPointer Exceptions after you have updated a DOTS plugin. Recommendation was to delete the complete workspace-dots folder prior to starting DOTS after the upgrade. This issue has been addressed in SPR# SJAAC3BNWV: DOTS – Workspace need to be deleted on every change and add of new plugin. With this fix it is no longer necessary to delete the workspace-dots folder. Not sure, when the fix was provided. There is no information about it in the fix list database. But this is only true for Domino on WINDOWS. If you are using DOTS with Domino on LINUX, you will see an error on the Domino server console ( “An error occurred while processing the command”) or even worse, the NullPointer Exceptions. The problem is that the underlying API in Domino does not delete files starting with a dot. (hidden files on UNIX systems).

One Touch setup (OTS) is quite powerful tool. But sometimes you need to know exactly what happens and combine functionality to make best use of it. With Domino 12.0.2 OTS creates certstore.nsf automatically and you can let it create a MicroCA for you. But what if you want to use a Let's Encrypt certificate instead? There is a quite simple way to just find and update the existing document with a appConfiguration. And if you specify notes.ini CertMgr_ACCEPT_TOU=1 the ACME account license agreement will be automatically accepted (already part of 12.0.0).

You should pay special attention to the infrastructure that keeps the entire IT system running. Especially, at the beginning of your journey to HCL Nomad Web. That’s important, because it must meet all security standards to ensure the smooth operation of HCL Nomad Web. We will therefore take a look at what we actually need for the infrastructure for HCL Nomad Web.

Though the bulk of the work I've been doing for the XPages Jakarta EE project is to bring JEE technologies to Domino, the NoSQL driver has been designed to lead a double life: it works in an XPages context, but it's written to not have any XPages dependencies. One reason for this is that I want it to be usable if you use, for example, the Open Liberty runtime project to side-car apps on a Domino server but still use Notes.jar for data access. Another reason for its organization, though, is that I intended for the driver to be portable across implementations. The driver itself is split into a main bundle and a ".lsxbe" implementation bundle. My original thought was to make that ready for a JNX or Domino JNA implementation, but it's pretty flexible.

Usually OpenSSL is the tool of choice for all type of certificate operations. But what if no OpenSSL command line is available? Like in a Domino container where you can't install software? After some research, I came up with the keytool, which is part of the JVM Domino ships.

A few days ago, a customer reported that one of our applications was not working properly and sent the associated logs. It was very quickly clear under what conditions the error occurred. So it was reproducible, which is the first important step to troubleshooting. Nevertheless, it took some time to locate the cause. Finally, I was able to find the “error”. To send it ahead. The “error” is not limited to a specific Domino version. The problem also occurs under Domino 9.0.1 FP10.

Elasticsearch in HCL Connections Componentpack is secured with Searchguard and needs certificates to work properly. These certificates are generated by bootstrap during the initial container deployment with helm. These certificates are valid for 10 years (chain_ca.pem) or 2 years (elasticsearch*.pem) and stored in the Kubernetes secrets elasticsearch-secret, elasticsearch-7-secret. So when your HCL Connections deployment is running for 2 years, the certficates stop working. The documentation on bootstrap is a little bit misleading and my suggested update does not make it into a technote or documentation update since nearly one year.

Rancher Desktop is a great all-in-one desktop environment. When running it with the Docker back-end you have all in one environment for development and run-time. For a server, K3s (https://k3s.io) is my platform of choice. It is production ready and easy to deploy. For Kubernetes, you always need a registry to pull images. As soon you need custom images, you will need a registry to upload and download your image. K3s allows you to configure private registries. You could use any registry. I am just running the registry Docker image on Podman in my environment.

This post is long overdue. I originally planned to write it to document the issues and solutions while working on the app, but as the problems kept appearing I wanted to make sure that I have all the answers. Now I know that I probably won't have them in the near future as I'm seeing new issues even after having the app in production for some time.

In the past years, running Domino as a Container has evolved from something for geeks on a development server, to a serious option to consider for production use. In this session, Martijn de Jong from e-office, will show what benefits Docker or Podman as an extra layer between Domino and Linux provide in the areas of standardization, portability and upgradability. He will also show how easy it is to create your own Domino container image with a live demo.