Das neue Kudos Boards für Docker und Kubernetes wurde bislang mit einer Testlizenz betrieben. Parallel existierte eine Premium-Lizenz für das klassische WebSphere Boards. Die Testlizenz lief vor einigen Wochen aus. Über den neuen Store wurde daher eine neue Erstellt. Da diese auf eine URL beschränkt ist, wiederholte sich der Prozess für das Testsystem.
Neues Docker-Hub Repository
Zu diesem Zeitpunkt war unsere Installation mangels neuer Docker-Images bereits seit einigen Monaten nicht mehr aktualisiert worden. Daher schaute ich in der Dokumentation nach, ob es etwas Neues gibt. Tatsächlich war eine neue Hauptversion 3 des Helm-Charts verfügbar. Die dort verlinkte beispielhafte values.yml enthielt einen Hinweis, dass das bisherige Repo iswkudos/kudos-boards-docker bereits seit 16.10.2019 veraltet ist. Stattdessen soll das neue iswkudos/kudos-boards genutzt werden.
Das neue Repo hatte ich im Docker-Hub bereits vor einigen Monaten gesehen. Allerdings nie getestet, da es keinerlei Hinweise oder Dokumentation hierzu gab. Laut der kurzen Beschreibung sollte es für die Cloud vorgesehen sein.
Neues Lizenzverhalten
Aufgrund des Kommentars aktualisierte ich das Repository. Das tagSuffix „2019-10-16“ wurde zunächst beibehalten. Primär ging es mir darum, das Lizenzchaos in den Griff zu bekommen. Funktionelle Updates sollten unabhängig davon später regulär getestet werden.
Nach dem Repository-Wechsel änderte sich das Lizenzverhalten: Wie auf dem obigen Screenshot zu sehen, war vereinzelt nur noch Activities+ nutzbar. Bei den restlichen Funktionen fehle laut Oberfläche die Lizenz. Dieses Verhalten betraf nicht alle Benutzer. Bei den Betroffenen schaffte weder das Leeren von Cache/Cookies, noch das Wechseln des Browsers Abhilfe. Bislang wurde nur ein Hinweis eingeblendet, dass die Demo-Lizenz abgelaufen sei. Im gleichen Tag des anderen Repos wurden somit Änderungen vorgenommen.
Fehlerhafte Verknüpfung von Benutzern zu Lizenzen?
Auch der Admin-Bereich enthält neue Funktionen. Öffnet man die Organisation und klickt unten auf die Kudos Boards Premium-Lizenz, werden jene Nutzer angezeigt, die diese Lizenz verwenden:
Es findet somit eine Verknüpfung von Benutzer und Lizenz statt. Dies hat die Fehlersuche etwas erleichtert: Die Benutzer mit dem o.g. Lizenzproblem tauchten nämlich nicht in der Benutzerliste der Premium-Lizenz auf. Im Adminbereich war zwar keine weitere Lizenz zu sehen. Da die Benutzer in der Liste fehlten, vermutete ich eine fehlerhafte Zuordnung zur alten, abgelaufenen Demo-Lizenz. Diese wird zwar möglicherweise nicht mehr angezeigt, aber könnte noch in der Datenbank vorhanden sein.
Collection sichern
Bevor man an der Datenbank experimentiert, sollte man diese sichern. Im Falle von nicht unterstützten Änderungen wie dies hier der Fall ist, sowieso. Mit dem Kommandozeilenwerkzeug mongoexport können wir MongoDB-Datenbanken komplett oder teilweise sichern. In diesem Falle geht es primär um die Collection userlicences. Das Sichern der kompletten Datenbank ist auch möglich. In diesem Falle sind sämtliche Änderungen an Inhalten (Karten, Boards etc.) nach dem Backup jedoch verloren. Man sollte daher zumindest zusätzlich vor Anwendung des Workarounds unten die Collection einzeln sichern:
$ mongoexport -d kudos-licence-service -c userlicences -o /tmp/userlicences-col.json
2020-04-01T13:33:15.734+0000 connected to: localhost
2020-04-01T13:33:15.736+0000 exported 62 recordsWichtig: Container sind kurzlebig! Sobald der Pod und damit der Container neu gestartet wird, ist das in /tmp gespeicherte Backup verloren! Ich empfehler daher unbedingt, beide Shells durch zweimaliges eingeben von exit zu schließen und das Backup auf den Host zu kopieren:
kubectl cp $(kubectl get po | grep mongo | awk '{print $1}'):/tmp/userlicences-col.json ./tmp/userlicences-col.json aus dem Datenbank-Pod wird damit in das aktuelle Arbeitsverzeichnis auf dem Host kopiert.
Workaround: Verknüpfte Lizenzen zurücksetzen
Daher schaute ich mir die Datenbank an. Hierfür muss man eine Shell im MongoDB-Pod öffnen. Alle weiteren Befehle gehen davon aus, dass kubectx installiert ist und man sich auf dem entsprechenden Cluster im Kudos-Boards Namespace befindet.
kubectl exec -it $(kubectl get po | grep mongo | awk '{print $1}') -- shDa man sich nun im Datenbank-Pod befindet, kann man mit dem Befehl mongo den CLI-Clienten öffnen. Darin wechselt man zur Datenbank kudos-licence-service
use kudos-licence-serviceDas Mapping von Benutzern zu Lizenzen befindet sich in der Collection userlicences. Ohne Quellcode habe ich via Reverse Engineering folgendes herausgefunden: Der Lizenzservice sucht bei der Nutzung von Kudos Boards nach einer Zuordnung in dieser Collection. Existiert keine, wird die höchste Lizenz (hier Kudos Boards Premium) mit dem Benutzer verknüpft. Dies wurde mit einzelnen Accounts sowie allen 62 bestehenden Mappings getestet. Man kann diese Collection daher mit folgendem Befehl leeren:
> db.userlicences.deleteMany({})
{ "acknowledged" : true, "deletedCount" : 62 }Dies löscht sowohl die funktionierenden Mappings, als auch die fehlerhaften. Da für beide Arten von Nutzern beim nächsten Aufruf eine neue Lizenz erzeugt wird, spielt dies keine Rolle. Durch das löschen der inkonsistenten Mappings funktioniert die Premium-Lizenz anschließend auch wieder bei jenen Benutzern, die bisher Fehlermeldungen erhalten haben.