HCL Connections Docs and Blogs vs Chrome

Today we ran into a “small” issue with HCL Docs editor. The editor opened but as soon as I tried to change anything I got a strange error popup. A 1 minute timeout expired and I should login again…

Create a new blog post in Chrome and it shows a nice message:
.

This message appeared only in Chrome 91. Firefox 89 just worked.

Checking the browser’s console and network log showed that a request to /docs/api/docsvr/lcfiles/7f45a827-647c-4565-a758-d205828a7567/edit/hb?save=false produced a http error 403.
The developer tools also revealed the problem. The JSESSIONID cookie had the SameSite set to None but has been missing the Secure flag.


Verifying the IBM technotes SameSite Cookie Handling and PH22157.

After adjusting and verifying all possible settings for SameSite and adding the Secure flag to all the Session Cookies, HCL Docs is working in Chrome again.

Access your index – Elastic Search queries

HCL Component Pack is fully set-up now, you’re interested what’s going on in that mysterious elasticsearch part? In CP 6.5 you’ve been able to access the ElasticSearch data directly through the kibana pod. With CP7 this seems to be gone.

If you really want/need to access the ElasticSearch environment, you may use the following path on your own risk

Step 1: get the necessary certificates

#!/bin/sh

echo "check directory"
cwd=`pwd`
if [ ! -d "$cwd/certs" ]; then
 mkdir -p $cwd/certs
fi
version='elasticsearch-7-secret'
#version='elasticsearch-secret'
echo "extract certificates"
if [ ! -f "$cwd/certs/elasticsearch-healthcheck.crt.pem" ]; then
	kubectl view-secret -n connections $version elasticsearch-healthcheck.crt.pem > $cwd/certs/elasticsearch-healthcheck.crt.pem
fi 
if [ ! -f "$cwd/certs/elasticsearch-http.crt.pem" ]; then
	kubectl view-secret -n connections $version elasticsearch-http.crt.pem > $cwd/certs/elasticsearch-http.crt.pem
fi
if [ ! -f "$cwd/certs/elasticsearch-healthcheck.des3.key" ]; then
	kubectl view-secret -n connections $version elasticsearch-healthcheck.des3.key > $cwd/certs/elasticsearch-healthcheck.des3.key
fi

echo "done"

This script requires the kubectl krew plugins installed in your kubectl client.
Run this on your master or a client which has kubectl and the krew plugin installed to get the secrets.

Then you could use the following script as an example:

#!/bin/bash
# An util script so that you can interact with es like what official site suggested:
# for additional usage, if you need to do much more complicated operation, pls
# refer to offcial site:
# https://www.elastic.co/


set -o errexit
set -o pipefail
set -o nounset

# the directory that all cert placed
# change this to your cert directory.
cert_dir=./certs
HOST=`hostname`
URL_base="https://localhost:30098"
#CP6.5:
#URL_base="https://localhost:30099"
#CP6.5: KEY_PASS=`kubectl view-secret -n connections elasticsearch-secret elasticsearch-key-password.txt`

KEY_PASS=`kubectl view-secret -n connections elasticsearch-7-secret elasticsearch-key-password.txt`

echo "[$KEY_PASS]"
if [ "${1:-}" = "" ] || [ "${2:-}" = "" ]; then
  echo "usage: sendRequest.sh   param_method param_url [additional param]"
  echo "Request is send to es client(coordinating node) by default. add param"
  echo "to send request to es master node"
  echo "refer: https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html"
  exit 107
fi

# save the HTTPS METHOD.
_method=$1
# and then shfit this argument.
# since we need to pass the rest args to curl command unchanged.
shift 1

# turn off expansion to avoid asterisk becoming current directory
set -f
# please ensure those
#   cert, password, key, cacert
# are at the right location.
response_text=$(curl \
   --insecure \
   --cert $cert_dir/elasticsearch-healthcheck.crt.pem:${KEY_PASS} \
   --key  $cert_dir/elasticsearch-healthcheck.des3.key \
   --cacert $cert_dir/elasticsearch-http.crt.pem \
   -X${_method} \
   ${URL_base}"$@")

# echo to return to caller.
echo ${response_text}
# turn expansion back to 'on'
set +f

Now you can use it like this

./sendRequest.sh GET /_cat/indices > indices.txt

Disclaimer: use at your own risk

HCL Connections 7 – update

We updated our productive HCL Connections environment last week from 6.5CR1 to 7. This time we decided to do an inplace update.

Upgrade WAS to 8.5.5.18 on commandline :

cd /opt/ibm/InstallationManager/eclipse/tools
./imcl install com.ibm.websphere.ND.v85_8.5.5018.20200910_1821 -repositories /data/install/unpacked/wasfp18/ -acceptLicense

The Connections update itself did not provide any surprises.
The database wizard was a bit creepy as it wanted to do a db update from 2.5 to 7 in the first place. After switching to the db2inst1 user, it still wanted an update from 3 to 7 for wikis and files db. So we decided to go through the wizards connections.sql directory and run any upgrade-XY-70.sql scripts. There’s only one for homepage.

Export PDF: there’s a post install step hidden, deep inside the help on how to install wkhtmltopdf.

Upgrade the Component Pack to 7 required some steps.
I decided to upgrade our kubernetes environment to 1.18.latest first. Then install helm3 and migrate all the stuff from helm2 using helm 2to3 Plugin

What am I missing at the moment: all my previous metrics data. The elasticsearch got updated from 5.5 to 7 which does not automatically update the elasticsearch indices. I have not found a way to update these properly yet.

The next step was to prepare all the *.yml files from the samples to my environment.
After applying all the new helm builds all the pods updated. Nothing worked. All the pods were up, but neither /appreg nor /social worked.

I only got a 404 from nginx.

After some debugging with krew’s tail plugin, it was clear that I had some issues with the ingress definitions.

 

 
Looks like the ingress controller has some issues with regex and wildcard definitions.
To fix this issue I added these 2 ingress definitions.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
  name: my-ingress-appreg
  namespace: connections
spec:
  rules:
  - host: 'connections.belsoft.ch'
    http:
      paths:
      - backend:
          serviceName: appregistry-client
          servicePort: 7000
        path: /appreg
        pathType: ImplementationSpecific
      - backend:
          serviceName: te-creation-wizard
          servicePort: 8080
        path: /te-creation-wizard
        pathType: ImplementationSpecific
      - backend:
          serviceName: community-template-service
          servicePort: 3000
        path: /comm-template
        pathType: ImplementationSpecific
      - backend:
          serviceName: admin-portal
          servicePort: 8080
        path: /cnxadmin
        pathType: ImplementationSpecific
      - backend:
          serviceName: sanity
          servicePort: 3000
        path: /sanity
        pathType: ImplementationSpecific

and

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  name: my-ingress-appregistry
  namespace: connections
spec:
  rules:
  - host: 'connections.belsoft.ch'
    http:
      paths:
      - backend:
          serviceName: appregistry-service
          servicePort: 3000
        path: /appregistry
        pathType: ImplementationSpecific
      - backend:
          serviceName: orient-web-client
          servicePort: 8000
        path: /social
        pathType: ImplementationSpecific
      - backend:
          serviceName: itm-services
          servicePort: 3000
        path: /itm
        pathType: ImplementationSpecific
      - backend:
          serviceName: community-suggestions
          servicePort: 3000
        path: /community_suggestions/api/recommend/communities
        pathType: ImplementationSpecific
      - backend:
          serviceName: connections-ui-poc
          servicePort: 3000
        path: /connections-ui
        pathType: ImplementationSpecific
      - backend:
          serviceName: teams-presence-service
          servicePort: 3000
        path: /teams-presence
        pathType: ImplementationSpecific
      - backend:
          serviceName: teams-share-service
          servicePort: 3000
        path: /teams-share-service
        pathType: ImplementationSpecific
      - backend:
          serviceName: teams-share-ui
          servicePort: 3000
        path: /teams-share-ui
        pathType: ImplementationSpecific
      - backend:
          serviceName: teams-tab-api
          servicePort: 3000
        path: /teams-tab/api
        pathType: ImplementationSpecific
      - backend:
          serviceName: teams-tab-ui
          servicePort: 8080
        path: /teams-tab
        pathType: ImplementationSpecific