Copyright ©
Mindbreeze GmbH, A-4020 Linz, 2021.
Alle Rechte vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen und/oder Marken der jeweiligen Hersteller.
Diese Unterlagen sind streng vertraulich. Durch die Übermittlung und Präsentation dieser Unterlagen alleine werden keine Rechte an unserer Software, an unseren Dienstleistungen und Dienstleistungsresultaten oder sonstigen geschützten Rechten begründet. Die Weitergabe, Veröffentlichung oder Vervielfältigung ist nicht gestattet.
Aus Gründen der einfacheren Lesbarkeit wird auf die geschlechtsspezifische Differenzierung, z.B. Benutzer/-innen, verzichtet. Entsprechende Begriffe gelten im Sinne der Gleichbehandlung grundsätzlich für beide Geschlechter.
Diese Anleitung gilt für G7 Appliances.
Mindbreeze InSpire verwendet zur Verwaltung der Anmeldedaten die Softwarekomponente Keycloak. Im diesem Abschnitt werden die wichtigsten Anwendungsfälle (Passwort ändern, Benutzer anlegen…) beschrieben. Darüber hinaus finden Sie hier weiterführende Dokumentation: Keycloak 11.0 Server Administration
Bei der ersten Anmeldung im Management Center werden sie dazu aufgefordert das Passwort zu ändern. Möchten Sie zu einem späteren Zeitpunkt das Passwort eines Benutzers ändern, gehen Sie wie folgt vor: Navigieren Sie im Management Center zum Menüpunkt „Setup“, „Credentials“ und dann unter „Manage“ „Users“. Suchen Sie den betreffenden Benutzer mit der Suchfunktion, oder klicken Sie auf „View all users“ um eine Liste der Benutzer anzusehen. Klicken Sie bei dem betreffenden Benutzer auf „Edit“. Im Tab „Credential“ können Sie ein neues Passwort setzen. Mit der Einstellung „Temporary“ bestimmen Sie, ob der Benutzer beim nächsten Anmelden selbst das Passwort ändern muss. Bestätigen Sie Ihre Eingaben mit „Reset Password“.
Sie können mehrere Benutzer anlegen. Navigieren Sie im Management Center zum Menüpunkt „Setup“, „Credentials“ und dann unter „Manage“ „Users“. Klicken Sie rechts auf „Add user“ vergeben Sie anschließend den Benutzernamen „Username“ und klicken Sie auf „Save“. Wechseln Sie anschließend ins Tab „Credentials“ um ein Passwort zu setzten. Dies ist im vorherigen Abschnitt „Passwort ändern“ beschrieben. Nachdem Sie ein Passwort gesetzt haben müssen Sie dem Benutzer noch Rollen zuweisen, ansonsten ist der neue Benutzer nicht sinnvoll nutzbar. Dazu siehe folgenden Abschnitt „Rollen verwalten“. Um die Funktion „Passwort vergessen/zurücksetzen“ benutzen zu können, wird empfohlen für jeden Benutzer eine gültige E-Mail-Adresse anzugeben.
Der Zugriff auf die verschiedenen Bereiche vom Management Center (z.B. „Reporting“, „Configuration“) werden mit Rollen geregelt. Beispielsweise muss ein Benutzer die Rolle „InSpire Config Administrator“ besitzen, um im Management Center den Punkt „Configuration“ benutzen zu können. Standardmäßig sind bereits mehrere „InSpire“-Rollen angelegt. Sie können die Liste aller verfügbaren Rollen folgendermaßen abrufen: Navigieren Sie im Management Center zum Menüpunkt „Setup“, „Credentials“ und dann unter „Configure“, „Roles“. Der Benutzer „admin“ besitzt standardmäßig alle Rollen. Sie können Benutzer wie folgt Rollen zuweisen oder entfernen: Navigieren Sie im Management Center zum Menüpunkt „Setup“, „Credentials“ und dann unter „Manage“ „Users“. Suchen Sie den betreffenden Benutzer mit der Suchfunktion, oder klicken Sie auf „View all users“ um eine Liste der Benutzer anzusehen. Klicken Sie bei dem betreffenden Benutzer auf „Edit“. Wechseln Sie zum Tab „Role Mappings“. Hier können Sie die Rollen zuweisen.
Im Auslieferungszustand sind mehrere Rollen vorkonfiguriert, die für den Betrieb erforderlich sind. Dieser Abschnitt beschreibt, welche Rollen das sind, und welche Bedeutung diese Rollen haben.
Die Rollen lassen sich in 3 Kategorien unterteilen:
Im Folgenden wird Mindbreeze „InSpire Management Center“ als MMC abgekürzt.
Folgende Mindbreeze InSpire Rollen sind standardmäßig angelegt:
Rollenname | Beschreibung | Beispiele (Auszug) |
„InSpire Administrator” | Zugriff auf MMC „Update” und „InSpire Global Settings“ | Updates Installieren, Conainermanagement |
„InSpire app.telemetry Administrator” | Zugriff auf MMC „Reporting“ (app.telemetry) | Diagnostik, Log-Dateien lesen, Feedback lesen. Diagostik-Konfiguration lesen und ändern. |
„InSpire Application Impersonation“ | Berechtigt im Client die Verwendung von „Trusted Peer Authentication“ Siehe Dokumentation: „Konfiguration von Trusted Peer Authentication für Mindbreeze InSpire“ | „Trusted Peer Authentication“ im Client verwenden, Im Namen anderer Benutzer suchen. |
„InSpire Config Administrator” | Zugriff auf MMC „Configuration” | Mindbreeze InSpire Konfiguration lesen und ändern |
„InSpire Index User” | Zugriff auf die Diagnose-Servlets „filter“ und „index“ | Index/Filter Status Abfragen, detaillierte Diagnosemöglichkeiten |
„InSpire Index Writer” | Zugriff um Dokumente zu Indizieren | Dokumente indizieren oder löschen, Dokumente filtern, Zugriff für externe Konnektoren |
„InSpire Overview User” | Grundlegender Zugriff auf das MMC | |
„InSpire Services Administrator” | Zugriff auf MMC „Services” | Nodes starten/stoppen, Reindex |
„InSpire Webmin Administrator” | Zugriff auf MMC „System” | Dateien herunterladen, hochladen und bearbeiten, Zeitzonen verwalten |
“InSpire Vocabulary Administrator” | Zugriff auf MMC „Synonyms, Replacements, Vocabulary“ | Synonyme, Replacements und Vocabulary bearbeiten |
“InSpire Relevance Administrator” | Zugriff auf Insight Apps, Query Boosting, Relevance | Relvance und Boosting bearbeiten |
“InSpire Resource Administrator” | Kombination aus InSpire Vocabulary Administrator und InSpire Relevance Administrator | Kombination aus den Rollen „InSpire Vocabulary- und InSpire Relevance Administrator“ |
Folgende Keycloak Administrationsrollen sind standardmäßig angelegt:
Rollenname | Beschreibung | Beispiele (Auszug) |
„admin“ | Zugriff auf „Credentials“ | Benutzer anlegen / löschen, Rollenzuordnungen ändern |
„create-realm“ | Nicht verwendet | |
„offline-access“ | Nicht verwendet | |
„uma_authorization“ | Nicht verwendet |
Darüber hinaus finden Sie hier weiterführende Dokumentation: Keycloak 11.0 Server Administration
Folgende app.telemetry Rollen sind standardmäßig angelegt:
Rollenname | Beschreibung | Beispiele (Auszug) |
„Fabasoft app.telemetry Administrators” | Voller Administrationszugriff auf app.telemetry | Konfigurationsänderungen |
„Fabasoft app.telemetry Dashboard Users” | Zugriff nur auf Public-Dashboards und Dashboards die dieser Gruppe zugewieden wurden. | |
„Fabasoft app.telemetry Logpool Users“ | Zugriff nur auf Reports und Log-Pools die dieser Gruppe zugewiesen wurden. | |
„Fabasoft app.telemetry Users” | Read-Only Zugriff auf alle app.telemetry Daten | |
„Fabasoft app.telemetry Web Form Users” | Zugriff auf die Feedback Inbox, Forms und Website-Konfiguration |
Weiterführende Dokumentation findet sich unter: Fabasoft app.telemetry Installation Guide.
Aus Sicherheitsgründen haben alle Cookies, welche vom Management-Center bzw. Keycloak-Service ausgestellt werden, die Option SameSiteauf Strict gesetzt. Siehe RFC6265.
In Ausnahmefällen kann es notwendig sein, hier das Sicherheitslevel zu reduzieren. Dazu muss in der Datei /var/data/env/reverse-proxy.env SameSiteValue=Lax oder SameSiteValue=None gesetzt werden. Die Einstellung wird nach einem Restart des reverse-proxy Containers aktiv.
Falls die Anmeldedaten-Verwaltung nicht mehr richtig funktioniert, kann die Anmeldedaten-Verwaltung auf Mindbreeze-Standards zurückgesetzt werden. Eine Fehlfunktion kann folgende Ursachen haben:
Das Zurücksetzen auf Mindbreeze-Standards setzt das Passwort vom Administrator zurück und setzt die Konfiguration der für den Betrieb notwendigen Teile der Konfiguration zurück. Andere Teile der Konfiguration werden nicht verändert. Es wird empfohlen, vor dem Zurücksetzten ein Backup anzufertigen.
Das Zurücksetzen auf Mindbreeze-Standards wird wie folgt durchgeführt:
Nach dem Starten aller Container sollten Sie sich im Management Center mit dem Benutzer admin und den Standard-Passwort anzumelden.
Die Datenbank und zugehörige Konfigurationsdateien werden täglich lokal gesichert. Das Sicherungsziel ist im keycloak Container wie folgt:
/data/backup/curr
Dieses Verzeichnis ist auch am Host verfügbar unter
/var/data/keycloak/data/backup/curr
Dieses Verzeichnis muss in einer externen Sicherung inkludiert werden.
Die lokale Sicherung kann auch manuell angestoßen werden. Die Sicherung wird dabei immer im selben, oben beschriebenen Verzeichnis abgelegt. Die Sicherung beeinflusst den laufenden Betrieb nicht. Es ist Zugriff auf die Kommandozeile notwendig. Führen Sie folgende Befehle aus:
# open a shell inside the keycloak container
docker exec -it keycloak bash
# within the keycloak container, impersonate the jboss user
su jboss –
# as jboss user, execute the backup script
./backup.sh
# this can take a few minutes
Eine Sicherung kann manuell mit der Kommandozeile wiederhergestellt werden. Da die Container mehrmals neugestartet werden müssen, sind die Dienste während dieser Zeit nicht verfügbar. Vorbedingung für die Wiederherstellung ist ein intaktes Sicherungsverzeichnis, welches innerhalb von /var/data/keycloak/data/ abgelegt oder kopiert wurde. Im diesen Beispiel befindet sich das kopierte Sicherungsverzeichnis unter /var/data/keycloak/data/restore . Führen Sie folgende Befehle aus:
# stop the keycloak container
docker stop keycloak
# remove the keycloak container
docker rm keycloak
# locate the restore script (docker_export_import_db.sh),
# it is /var/data/upload/image/keycloak/scripts/docker_export_import_db.sh, if the appliance has never been updated, it is /var/data/upload/image/keycloak/scripts/ docker_export_import_db.sh
# run the restore script with the current version number of Mindbreeze, the restore directory path relative to the keycloak container and in import mode
/var/data/upload/image/keycloak/scripts/docker_export_import_db.sh 19.1.2.345 /data/restore import
# this can take a few minutes
# watch the console output for the message “import finished successfully”, then actively exit the script
# the restore process creates a temporary container that must be removed
# stop the temporary keycloak container
docker stop keycloak
# remove the temporary keycloak container
docker rm keycloak
# now create the real keycloak container
# locate the create script
# it is /var/data/upload/image/keycloak/create.sh, if the appliance has never been updated, it is /var/data/upload/image/keycloak/create.sh
# run the create.sh script
/var/data/upload/image/keycloak/create.sh
# restart all container to apply the restored data
systemctl restart docker
# this can take a few minutes
Folgende Logdateien können bei einer Fehlerdiagnose von Nutzen sein:
# in-progress backups
/var/data/keycloak/data/temp/backup.log
# finished backups
/var/data/keycloak/data/curr/backup.log
# keycloak server logs within the keycloak container:
/opt/jboss/keycloak/standalone/log/server.log
# security logs within the inspire container:
/var/log/secure
Eine mögliche Ursache dieses Fehlers sind fehlende oder fehlerhafte Konfigurationsdatein.
Prüfen Sie die Datei /var/data/keycloak/config/keycloak_h2_db_name. Mit InSpire Version 20.3 oder älter soll die Datei den Inhalt keycloak_4_6_0 haben. Mit InSpire Version 20.4 oder neuer soll die Datei den Inhalt keycloak_10_0_2 haben.
Falls die Datei fehlt oder der Inhalt nicht übereinstimmt, korrigieren Sie dies und versuchen sie erneut das Upgrade.
Generell muss vor einem Downgrade eine vollständige Sicherung (nicht nur von Keycloak) durchgeführt werden.
Bei gewissen InSpire Versionen ist ein Downgrade nicht ohne Beibehaltung aller Keycloak-Daten möglich. Dies Betrifft Daten wie beispielsweise zusätzlich angelegte Clients, (Synchronisierte Benutzer, angepasste User Role Mappings) Dazu gehören folgende (alte) Versionen:
Das heißt, beispielweise werden bei einem Downgrade von 20.4 auf 20.3 nicht alle Keycloak-Daten beibehalten, bei einem Downgrade von 20.3 auf 20.2 werden die Keycloak Daten behalten.
Falls ein Downgrade auf solche Versionen durchgeführt werden soll, müssen die Keycloak-Daten nach dem Downgrade manuell wieder eingegeben werden.
Bei Downgrades ist zwischen 2 grundsätzlichen Fällen zu unterscheiden:
Die Keycloak-Daten sind unter anderem in Datenbank-Dateien im Verzeichnis /var/data/keycloak/data/data/ gespeichert. Die Datenbank-Dateien beinhalten die Keycloak-Version im Dateinamen.
Folgende Abschnitte beschreiben die Schritte, die in den jeweiligen Fällen zu tun sind:
z.B auf einer InSpire 20.4:
# ll /var/data/keycloak/data/data/
total 2076
drwxr-xr-x 2 1000 1000 6 Sep 8 13:43 content
drwxr-xr-x 2 1000 1000 26 Sep 8 13:43 kernel
-rw-r--r-- 1 1000 1000 146 Sep 16 16:57 keycloak_10_0_2.lock.db
-rw-r--r-- 1 1000 1000 1302528 Sep 17 10:16 keycloak_10_0_2.mv.db
-rw-r--r-- 1 1000 1000 7924 Sep 16 16:57 keycloak_10_0_2.trace.db
-rw-r--r-- 1 1000 1000 146 Sep 14 10:50 keycloak_4_6_0.lock.db
-rw-r--r-- 1 1000 1000 798720 Sep 14 11:19 keycloak_4_6_0.mv.db
-rw-r--r-- 1 1000 1000 4507 Sep 14 10:46 keycloak_4_6_0.trace.db
drwxr-xr-x 2 1000 1000 6 Sep 14 10:44 timer-service-data
drwxr-xr-x 3 1000 1000 35 Sep 14 11:19 tx-object-store
In dieser Auflistung erkennen Sie, dass eine keycloak_4_6_0.mv.db Datenbankdatei existiert, die von der vorherigen, alten InSpire Version stammt. Falls Sie hier keine ältere Datenbank-Datei finden können, befolgen Sie stattdessen bitte den Abschnitt „Downgrade ohne vorherige Version“
Da nun die alte Datenbankdateien verwenden werden, müssen Sie die Datenbankdateien mit der neuen Version löschen, um ein divergieren der Daten zu verhindern.
# ll /var/data/keycloak/data/data/
total 2080
drwxr-xr-x 2 1000 1000 6 Sep 8 13:43 content
drwxr-xr-x 2 1000 1000 26 Sep 8 13:43 kernel
-rw-r--r-- 1 1000 1000 146 Sep 16 16:57 keycloak_10_0_2.lock.db
-rw-r--r-- 1 1000 1000 1302528 Sep 17 10:16 keycloak_10_0_2.mv.db
-rw-r--r-- 1 1000 1000 7924 Sep 16 16:57 keycloak_10_0_2.trace.db
-rw-r--r-- 1 1000 1000 146 Sep 17 11:15 keycloak_4_6_0.lock.db
-rw-r--r-- 1 1000 1000 798720 Sep 17 11:15 keycloak_4_6_0.mv.db
-rw-r--r-- 1 1000 1000 8469 Sep 17 11:15 keycloak_4_6_0.trace.db
drwxr-xr-x 2 1000 1000 6 Sep 14 10:44 timer-service-data
drwxr-xr-x 3 1000 1000 35 Sep 14 11:19 tx-object-store
In diesem Fall müssen Sie die Dateien keycloak_10_0_2.lock.db, keycloak_10_0_2.mv.db und keycloak_10_0_2.trace.db löschen.
Anschließend überprüfen Sie den Inhalt folgender Dateien:
# cat /var/data/keycloak/config/keycloak_version
4_6_0
# cat /var/data/keycloak/config/keycloak_h2_db_name
keycloak_10_0_2
Der Inhalt der Datei /var/data/keycloak/config/keycloak_h2_db_name muss geändert werden. Ändern Sie die Versionsnummer auf dieselbe (alte) Version, die in der Datei /var/data/keycloak/config/keycloak_version vorhanden ist.
überprüfen Sie anschließend den Inhalt folgender Dateien, die Versionen sollten nun (mit der alten Version) übereinstimmen:
# cat /var/data/keycloak/config/keycloak_version
4_6_0
# cat /var/data/keycloak/config/keycloak_h2_db_name
keycloak_4_6_0
Damit ist das Downgrade aus Sicht von Keycloak abgeschlossen.
# ll -a /var/data/keycloak/data/data/
total 796
drwxr-xr-x 6 1000 root 173 Sep 17 11:32 .
drwxr-xr-x 4 1000 root 32 Sep 14 11:00 ..
drwxr-xr-x 2 1000 1000 6 Sep 8 13:43 content
drwxr-xr-x 2 1000 1000 26 Sep 8 13:43 kernel
-rw-r--r-- 1 1000 1000 146 Sep 17 11:15 keycloak_10_0_2.lock.db
-rw-r--r-- 1 1000 1000 798720 Sep 17 11:15 keycloak_10_0_2.mv.db
-rw-r--r-- 1 1000 1000 8469 Sep 17 11:15 keycloak_10_0_2.trace.db
drwxr-xr-x 2 1000 1000 6 Sep 14 10:44 timer-service-data
drwxr-xr-x 3 1000 1000 35 Sep 14 11:19 tx-object-store
Falls hier doch Datenbankdateien älterer Versionen aufgelistet sind, fahren Sie stattdessen mit dem Abschnitt „Downgrade nach Update“ fort.
bash /var/data/upload/image/keycloak/scripts/recreate_volumes.sh -f
bash /var/data/upload/image/keycloak/create.sh
docker start keycloak
Sie können mit dem Kommando journalctl -f den Fortschritt beobachten. Mit dem Log-Eintrag „Initial Config Successful“ ist die Operation abgeschlossen. Starten Sie anschließend alle Container neu mit folgendem Kommando: systemctl restart docker
Nach einem Downgrade von Version 21.3 auf 21.2 können Credentials nicht mehr geladen werden, es werden entsprechende Fehlermeldungen im Log angezeigt und betroffene Services starten nicht mehr. Beispiel für diesen Fehler im Log:
/opt/mindbreeze/bin/mesmaster.exe[245]: 2021-12-13 17:53:19,109 [Threadpool worker] ERROR: Failed to load build-in credentials store file /etc/mindbreeze/builtincredentials.proto
Um dieses Problem zu beheben müssen folgende Schritte auf der Kommandozeile durchgeführt werden:
docker exec -it inspire bash
rm /etc/mindbreeze/builtincredentials.proto
systemctl restart mesinspireadminapi
Damit wird die Datei im korrekten Format neu generiert und anschließend werden die betroffenen Services automatisch neu gestartet. (In einem verteilten Betrieb kann es ein paar Minuten dauern, bis die Änderungen auf alle Nodes synchronisiert sind)