Let me clarify what this article is about. Huddo (also known as ISW) is selling 2 versions of their Boards product: Kudos Boards – The Java application that can be installed on WebSphere. Active development has stopped a few years ago Huddo Boards – The product consisting of several containers, which can be installed on Kubernetes or a container engine like Docker. A version with limited functionality is part of the HCL Connections component pack and known as Activities Plus. This product is actively being developed and also available for other platforms. Although the Connections Component pack was introduced in version 6 already, many companies refrained from installing it due to the serious amount of extra infrastructure needed to run these components, which includes a Kubernetes cluster. We call these the WebSphere-only Connections installations, as they only include the WebSphere stack part of Connections. So what if you would like to use the full power of Huddo Boards without having to install a Kubernetes cluster? That’s what this article is about.

As I do a lot of my research on new Domino versions, Connections versions and HCL DX on my own server at home and as I’m often not at home, I figured I needed a VPN tunnel to my server, so I can work as if I am home. Wireguard has become kind of the de facto standard for these kind of situations, so I looked into installing it on my CentOS Stream 9 host.

Last week I got the unpleasant surprise of a no longer working Huddo Boards for Component pack installation at a customer after I had rebooted my Kubernetes environment. I had to reboot this environment after I updated the Kubernetes certificates. Of course, after a change you immediately think that your problem is related to the change you just made, but in this case the only relation was with the restart, which means that this can happen to everyone running Huddo/Kudos Boards for Component pack or Huddo Boards Docker.

On a new SDI 7.2 installation (with Java 8 and the latest Connections TDISOL directory for Java 8), I ran into a weird error: CTGDKG023E Error while starting main class.java.lang.reflect.InvocationTargetException .. Caused by: java.lang.UnsatisfiedLinkError: i4clntjni (Not found in java.library.path) Luckily, Google could help me on this one. This technote shows that if there are missing libraries, SDI doesn’t properly install and you will have to uninstall SDI, install the missing libraries, and reinstall SDI.

Normally a Kubernetes environment is well maintained and regularly updated with the most recent versions of Kubernetes. However, with a Kubernetes environment that is just used a an HCL Connections Component pack installation, this might not be on your radar and it’s easy to let it just run attended. If you do that for too long though, like longer than one year, you’ll get into trouble

In part 5 I discussed the installation of all components. Now it’s time to configure them. My goal is not to duplicate the HCL documentation on this point, but to highlight where this documentation is ambiguous or incomplete. So by all means, also read that documentation.

If you followed the steps from the previous parts, you have a working Kubernetes cluster and a Docker registry containing all images necessary for installing the Component Pack. In this part I’ll discuss installing all helm charts up to, but not including, the actual components like OrientMe, Elasticsearch etc.

As a next step we’ll import the components of the Component pack into a Docker registry. If you have an existing registry in your company which you can use, you can skip right to the step where you upload the images in this repository. If you don’t, you’ll have the create the registry first.

In a series of articles I’m trying to fill the gaps in the HCL documentation regarding the Component Pack. In the first part I covered the installation and configuration of Docker. In this 2nd part I’ll cover the installation of Kubernetes together with Calico and Helm. After this the basic infrastructure is set up and the actual installation of the Component pack can begin. The installation I’m doing is a non-HA Kubernetes platform. One master and 2 worker nodes. If you need to setup a HA Kubernetes platform, you have to do a few extra steps, but using this manual and combining it with the HA documentation from HCL, you should be good.

As I’m currently installing the HCL Connections 6.5 CR1 component pack at a customer I run into a lot of points where the HCL documentation is simply outdated or very confusing. In a series of articles I plan to write about the caveats in the documentation, to hopefully help you with your installation. In this first part I cover Docker.

Your TDI solution directory contains a couple of files which all start with employee. These files tell you which records were added, updated, deleted, skipped or produced an error. The last file is usually the most interesting one. Often employee records give an error because a user was deleted at an earlier stage and recreated with a different GUID. Sometimes users are created with the same login ID as a previous user, which was long deleted and there are more relatively obvious reasons like that why an employee record would create an error. However, sometimes you are just completely in the dark of why a record gives an error. That’s when this little tip helps you to determine the problem.

HCL Domino saves it certificates in a .kyr file. IBM WebSphere saves it certificates in a Java Keystore / .jks format. Both formats allow you to save the password for the keystores in a stash file which has the extension .sth. The stash files allow you to do most actions without entering a password.

Over the past year, I’ve created my own set of useful SQL queries to get needed information and I thought I’d share them here. Please realise that my main client uses MS SQL for their backend, so the queries are written for that, though most should be universal or easy to change for DB2 or Oracle.