grommunio 2026.06.2 Upgrade und technische Abnahme: Keycloak SSO, MFA, AutoDiscover und Mailflow

Einleitung

grommunio 2026.06.2 ist aus Betriebssicht nicht nur ein Paketupdate. Spannend wird das Release dort, wo bestehende Komponenten nach dem Upgrade wieder als zusammenhängende Plattform funktionieren müssen: Web, Files, Chat, Archive, Admin und die zentrale Anmeldung über grommunio Auth und Keycloak.

Dieser Beitrag ist deshalb als praktische Upgrade-Anleitung aufgebaut: Was vor dem Upgrade gesichert werden muss, wie der Lauf von 2026.06.1 auf 2026.06.2 nachvollziehbar dokumentiert wird, welche SSO-/Keycloak-Punkte nachgezogen werden mussten und welche Tests danach verpflichtend in die Abnahme gehören. Die Kernbotschaft ist einfach: Ein funktionierendes Paketupdate ist noch kein vollständig verifiziertes Plattform-Upgrade.

Testumgebung und Annahmen

• Datum: 2. Oktober 2026.

• Umgebung: isolierte Test-Appliance mit grommunio 2026.06.1 als Ausgangspunkt.

• Upgrade-Pfad: grommunio 2026.06.1 auf grommunio 2026.06.2.

• Keine Produktion: Test-Host, Test-Domain und reproduzierbarer Ausgangszustand.

• Ziel: Upgrade, zentrale Keycloak-SSO-Flows und Betriebszustand so prüfen, dass daraus eine nutzbare Admin-Checkliste entsteht.

Upgrade-Ablauf als Runbook

Der sichere Ablauf besteht aus drei Phasen: vor dem Upgrade den Zustand beweisbar festhalten, das Upgrade kontrolliert durchführen und danach nicht nur Dienste, sondern echte Benutzer- und Client-Flows prüfen.

1. Snapshot oder Backup prüfen und Wiederherstellungsweg kennen.

2. Paketstände, aktive Dienste, SSO-Baseline und zentrale Endpoints erfassen.

3. Offiziellen Upgrade-Pfad der eingesetzten Appliance-Version prüfen.

4. Upgrade durchführen und Ausgabe vollständig sichern.

5. Reboot-Empfehlung ernst nehmen und kontrolliert neu starten.

6. Nach dem Reboot systemctl --failed und zypper ps -s prüfen.

7. Files, Chat, Archive, Admin und Keycloak nicht nur als Dienst, sondern per Login-Flow prüfen.

8. Autodiscover, Autoconfig, SMTP, IMAP, DAV, ActiveSync und EWS zumindest endpoint-seitig kontrollieren.

9. Auffälligkeiten klar als PASS, FAIL, SKIPPED, NOT TESTED oder NOT APPLICABLE dokumentieren.

Was beim Upgrade von 2026.06.1 auf 2026.06.2 besonders wichtig war

Vor dem Upgrade: Baseline schaffen

Ohne Baseline ist ein Upgrade-Test schnell wertlos. Wenn nachher etwas nicht funktioniert, muss klar sein, ob der Fehler neu ist oder vorher schon vorhanden war. Vor dem Upgrade sollten deshalb Paketstände, Dienste, relevante Endpoints und der vorhandene SSO-Zustand gesichert werden.

rpm -qa | sort | grep -E '^(grommunio|gromox)'
systemctl --failed
zypper ps -s
openssl s_client -connect mail.example.test:443 -servername mail.example.test -verify_return_error
curl --fail https://mail.example.test/web/
curl --fail https://mail.example.test/files/status.php
curl --fail https://mail.example.test/auth/realms/grommunio/.well-known/openid-configuration

Upgrade auf 2026.06.2

Das eigentliche Paketupdate kann je nach Appliance-Stand und Herstellerempfehlung unterschiedlich dokumentiert sein. In der geprüften Umgebung war zusätzlich der Helper grommunio-update vorhanden, während die geprüfte Operations-Dokumentation Package Updates weiterhin über zypper ref und zypper up beschreibt. Für Runbooks gehört deshalb beides in die Prüfung: offizieller Upgrade-Pfad der eingesetzten Version und tatsächlich ausgeführte Befehle.

zypper --non-interactive --gpg-auto-import-keys ref
zypper --non-interactive --gpg-auto-import-keys up

# Nach dem Reboot:
zypper ps -s
systemctl --failed

Für eine produktive Anleitung ist der konkrete Befehl nicht der einzige relevante Punkt. Entscheidend ist, dass der gewählte Upgrade-Pfad zur Appliance-Version passt, dass die Ausgabe gesichert wird und dass danach eine fachliche Abnahme folgt. Ein Runbook sollte daher neben dem Paketbefehl immer auch die Tests unten enthalten.

Paket                         Version nach dem Upgrade
grommunio-release             2026.06.2
grommunio-web                 5.1.20
grommunio-files               34.0.4
grommunio-keycloak            26.7.4
grommunio-auth                0.2.37
gromox                        3.11.136
grommunio-admin-api           1.21.23
grommunio-chat-v10            10.5.8
grommunio-archive             1.4.9

Wie vollständig haben wir die Appliance getestet?

Der finale Abnahmelauf wurde produktionsnah aufgebaut: nicht nur 127.0.0.1, sondern der echte Lab-FQDN mail.example.test mit SNI, Hostname-Prüfung und explizit vertrautem Lab-Zertifikat. Der Report trennt echte PASS-Ergebnisse klar von nicht getesteten oder nicht anwendbaren Bereichen.

Für Partner und Kunden ist daraus ein Runbook ableitbar: erst Baseline, dann Upgrade-Pfad prüfen, dann Update ausführen, danach System Health, Files, Keycloak/OIDC, Browser-SSO, Mailflow, Autodiscover, Autoconfig, DAV, EWS und EAS prüfen. Clients wie Thunderbird, Outlook oder ActiveSync bleiben nur dann PASS, wenn sie wirklich mit frischem Profil oder kontrolliertem Testclient durchlaufen wurden.

Technische Abnahme

Die Ergebniskontrolle folgt dem einheitlichen grommunio-Format. PASS bedeutet, dass der konkrete Prüfpunkt aktiv ausgeführt und belegt wurde. FAIL, SKIPPED und NOT TESTED bleiben bewusst sichtbar, damit aus einem Paketupdate keine Scheinsicherheit wird.

Pflichttests nach dem Upgrade

Die folgende Liste ist der eigentliche Abnahmekern. Ein grommunio-Upgrade sollte erst dann als abgeschlossen gelten, wenn diese Punkte entweder bestanden oder bewusst als nicht getestet dokumentiert sind.

• System: Paketstand, failed Units, Reboot-State, zentrale Dienste.

• Identity: Keycloak Realm, OIDC Discovery, Clients, Redirect URIs, Callback-Verhalten.

• MFA: Required Actions, TOTP-Setup, Admin-Zugriff erst nach MFA.

• Web: Login, Reload, Mailbox sichtbar, keine Auth-Fehler.

• Files: occ status, needsDbUpgrade false, serverseitige OIDC Discovery, Files UI.

• Chat: SSO-Login, Benutzerzuordnung, Kanalansicht.

• Archive: SSO-Login, Suchoberfläche, keine OIDC-Fehler.

• Admin: SSO Button, preferred_username Mapping, Rolle, Dashboard.

• Mail: SMTP Submission, STARTTLS, AUTH, IMAP-Zustellung.

• Discovery: Autodiscover und Autoconfig für Clients.

• Protokolle: DAV per PROPFIND, EWS per echter SOAP-Anfrage, ActiveSync mindestens mit erwarteter Auth-Challenge und anschließend mit echtem Client, falls produktiv genutzt.

• Meet: Webroute und Jitsi-Backend-Dienste getrennt prüfen.

• Negative Tests: falsches Passwort darf keine Anwendungssession erzeugen.

• Logout/Session: lokaler Logout und Keycloak-Session-Verhalten getrennt betrachten.

Was bedeutet PASS in diesem Test?

Bei Browser-SSO bedeutet PASS nicht einfach HTTP 200. Ein Flow wurde erst dann als erfolgreich gewertet, wenn die Anwendung aufgerufen wurde, der Redirect zum richtigen Identity Provider führte, die Authentifizierung funktionierte, erforderliche MFA-Schritte abgeschlossen wurden, der OIDC-Callback zurückkam, eine Anwendungssession entstand und ein eindeutiges authentifiziertes UI-Element sichtbar war.

Für native Protokolle ist PASS enger definiert: SMTP/IMAP wurde als Mailflow mit Zustellung geprüft, DAV mit authentifiziertem PROPFIND und EWS mit einer echten SOAP-GetFolder-Anfrage auf die Inbox. ActiveSync wurde zusätzlich mit einem kontrollierten Testclient für Provisioning, FolderSync und initialen Sync geprüft. Ein echtes iOS- oder Android-Gerät mit Kunden-Policy und Push-Verhalten bleibt ein separater Pflichtschritt, wenn genau diese Endgeräte produktiv genutzt werden.

Client- und MFA-Matrix

Zentrale Browser-Anmeldung und native Clients müssen getrennt bewertet werden. Keycloak, OIDC und MFA sichern die Web- und Browser-Flows. IMAP, SMTP, DAV, EWS und ActiveSync können je nach Client und Konfiguration andere Authentifizierungswege verwenden. Deshalb darf ein erfolgreicher Browser-MFA-Test nicht automatisch als Thunderbird-, Outlook- oder Mobile-Sync-Abnahme gewertet werden.

Thunderbird und echte Endgeräte als letzter Abnahmeschritt

Für Kunden, die Thunderbird produktiv einsetzen, endet die Abnahme nicht beim XML. Der Clientpfad wurde deshalb mit Thunderbird 156.0 und frischem Profil erneut geprüft: IMAP/SMTP-Konto, Inbox, SMTP Submission mit Attachment und Zustellnachweis per IMAP. Die vertiefte Native-Clients-Abnahme ist als eigener Folgebeitrag dokumentiert: /de/tech/grommunio-native-clients-keycloak-sso-2026.

Bewusst nicht als vollständiger Thunderbird-PASS gewertet sind Kalender- und Kontakte-CRUD über CalDAV/CardDAV sowie ein vollständiger EWS-GUI-Pfad. Diese Punkte gehören in eigene Clienttests, wenn sie beim Kunden produktiv relevant sind.

Für ActiveSync wurde der Schritt nachgezogen: Ein kontrollierter EAS-Testclient hat Connectivity, Provisioning, FolderSync mit 14 Ordnern und einen initialen Sync über 11 Collections erfolgreich durchgeführt. Das ist ein belastbarer Server- und Protokollnachweis. Was es nicht ersetzt, ist ein kundenspezifischer iOS- oder Android-Test mit echten Policies, Push-Verhalten, Geräteverwaltung und Benutzerabläufen.

Erster Stolperstein: Files auf HTTP 503

Nach dem Paketupdate war grommunio Files zunächst nicht vollständig betriebsbereit. Die Anwendung antwortete mit HTTP 503, obwohl das Paketupdate selbst erfolgreich war. Die Ursache war kein globaler Plattformausfall, sondern ein ausstehendes Datenbank-Upgrade von Files.

sudo -u grofiles php -d memory_limit=1024M /usr/share/grommunio-files/occ upgrade

Das ist eine wichtige Betriebserkenntnis: Ein erfolgreiches Paketupdate bedeutet nicht automatisch, dass alle datenbankgestützten Komponenten bereits auf dem neuen Schema laufen. Files sollte nach einem Upgrade aktiv mit occ status, Logs und einem echten Login geprüft werden.

Zentrale Authentifizierung mit grommunio Auth und Keycloak

Die stärkere Zentralisierung der Anmeldung ist der eigentliche Schwerpunkt dieses Tests. grommunio Auth stellt die Keycloak-Integration bereit, die einzelnen Anwendungen verwenden eigene OIDC-Clients beziehungsweise Adapter, und Keycloak wird zur zentralen Stelle für Login, Required Actions und MFA.

Keycloak
                         |
                    grommunio Auth
                         |
         +---------------+----------------+
         |               |                |
         v               v                v
        Web            Files            Admin
         |               |                |
         +-------+-------+-------+--------+
                 |               |
                 v               v
                Chat           Archive

Meet wird bewusst getrennt betrachtet: Die Webroute /meet/ antwortete im finalen Endpoint-Test mit HTTP 200, und die relevanten Dienste jitsi-jicofo, jitsi-videobridge und prosody waren aktiv. Für eine Kundenfreigabe sollte zusätzlich ein echter Zwei-Browser- oder Zwei-Client-Raumtest erfolgen, weil ein erreichbares Frontend allein noch keine Medienpfad-Abnahme ist.

Welche SSO-Flows tatsächlich funktioniert haben

Komponente       Ergebnis        Besonderheit
Web              erfolgreich     Keycloak-Login bis in die Weboberfläche
Files            erfolgreich     DB-Upgrade, TLS-Vertrauen und Callback geprüft
Chat             erfolgreich     bestehende Accounts auf SSO migriert
Archive          erfolgreich     Adapter-Konfiguration nachgezogen
Admin            erfolgreich     preferred_username-Mapping plus MFA bis Dashboard

SSO-Login-Belege pro Modul

Für die Abnahme reicht es nicht, am Ende nur ein Dashboard zu zeigen. Pro Modul muss sichtbar sein, wie der SSO-Einstieg funktioniert: direkte Weiterleitung zu Keycloak oder lokale Login-Seite mit Keycloak-Schaltfläche. Die folgenden Screenshots zeigen genau diesen Einstiegspunkt je Anwendung.

https://mail.example.test/auth/realms/grommunio/

Screenshot: Web: Der unauthentifizierte Zugriff führt direkt zur Keycloak Login-Maske.

https://mail.example.test/files/

Screenshot: Files: Die lokale Login-Seite bietet den Einstieg über grommunio Keycloak.

https://mail.example.test/auth/realms/grommunio/

Screenshot: Files: Nach Klick auf grommunio Keycloak wird die zentrale Keycloak Login-Maske geöffnet.

https://mail.example.test/chat/login

Screenshot: Chat: Die Login-Seite zeigt den Keycloak-Einstieg neben dem lokalen Login.

https://mail.example.test/auth/realms/grommunio/

Screenshot: Chat: Nach Auswahl von Keycloak landet der Browser im zentralen Realm.

https://mail.example.test/auth/realms/grommunio/

Screenshot: Archive: Der unauthentifizierte Zugriff führt zur Keycloak Login-Maske.

https://mail.example.test/web/

Screenshot: grommunio Web ist nach dem Keycloak-Login mit einer Test-Mailbox erreichbar.

https://mail.example.test/files/

Screenshot: grommunio Files lädt nach OIDC-Callback und abgeschlossenem Files-Datenbankupgrade.

https://mail.example.test/chat/login

Screenshot: grommunio Chat erreicht nach SSO eine angemeldete Kanalansicht.

https://mail.example.test:8443/login

Screenshot: Der Admin-Login bietet nach dem Upgrade den SSO-Einstieg an.

https://mail.example.test/auth/realms/grommunio/

Screenshot: Nach dem Klick auf SSO landet der Browser bei Keycloak im grommunio-Realm.

https://mail.example.test:8443/

Screenshot: Nach Authentifizierung und MFA-Setup ist das grommunio Admin Dashboard erreichbar.

Chat: bestehende Accounts auf SSO umstellen

Bei bestehenden Installationen ist Chat besonders wichtig, weil vorhandene Accounts nicht automatisch bedeuten, dass der neue Login-Pfad schon sauber verwendet wird. Bestehende Chat-Accounts sollten deshalb gezielt auf SSO geprüft und bei Bedarf migriert werden.

grommunio-admin chat sso enable

Danach gehören Chat-Dienst, Login-Button und Kanalansicht in die Abnahme.

Archive und Admin: fehlende Adapter nachziehen

In bestehenden Umgebungen sollte nach dem Upgrade geprüft werden, ob die Adapter-Konfigurationen für Archive und Admin tatsächlich vorhanden sind. Falls sie fehlen oder nicht zum Realm passen, müssen sie gezielt nachgezogen werden. Das ist kein pauschaler Fehler von grommunio Auth, sondern ein sinnvoller Kontrollpunkt für Upgrades.

/usr/share/grommunio-auth/setup-grommunio-auth-clients.sh archive admin

Wichtig ist die Unterscheidung: Was stellt der Hersteller bereit, was sollte automatisch passieren, und was ist in einer konkreten Umgebung tatsächlich passiert? Genau diese Trennung macht einen Upgrade-Test verwertbar.

Files: TLS und OIDC Discovery

Files benötigt die OpenID-Provider-Metadaten nicht nur im Browser, sondern auch serverseitig. Wenn interne oder selbstsignierte Zertifikate verwendet werden, müssen OS Trust Store und Files-Umgebung diese CA kennen.

In einer sauber aufgebauten produktiven PKI sollte dieser Sonderfall normalerweise nicht auftreten. Die Architekturlektion bleibt trotzdem wichtig: OIDC ist nicht nur Browser-Kommunikation, sondern betrifft auch serverseitige Discovery und TLS-Vertrauen.

Stolperstein: OIDC Callback und PATH_INFO

Der Files-OIDC-Callback unter /files/index.php/apps/user_oidc/... ist ein guter Kandidat für Upgrade-Probleme, wenn nginx, PHP-FPM oder Rewrite-Regeln angepasst wurden. Statt eine komplette Nginx-Konfiguration zu veröffentlichen, ist die Prüfliste wichtiger.

• Kommt der Browser nach Keycloak wirklich auf die erwartete Callback-URL zurück?

• Wird index.php als Script erkannt und der Rest als PATH_INFO übergeben?

• Sieht PHP-FPM denselben Pfad wie Nginx?

• Gibt es 403, 404 oder 500 im Callback statt einer Anwendungssession?

• Sind Nginx-Errorlog, PHP-FPM-Log und Files-Log zum gleichen Zeitpunkt geprüft?

Admin SSO: Identity Mapping ist wichtiger als das Passwort

Ein besonders wichtiger Befund betrifft grommunio Admin. Die Admin API löst den OIDC-Claim preferred_username gegen die grommunio Admin User Datenbank auf. Ein lokales Admin-Passwort allein macht daher noch keinen funktionierenden SSO-Login.

Keycloak
   |
   | preferred_username
   v
grommunio Admin API
   |
   | User lookup
   v
grommunio Admin Database

• Welche föderierte Identität bekommt Adminzugang?

• Welcher Username wird als preferred_username übertragen?

• Gibt es dazu einen passenden grommunio Admin User?

• Welche Rolle besitzt dieser User?

• Soll der lokale admin-Account überhaupt für SSO verwendet werden?

• Welche MFA-Policy gilt für Admin-Zugänge?

MFA bis zum Dashboard getestet

Der Admin-Test war kein oberflächlicher Button-Test. Der Browser wurde von Admin zu Keycloak geleitet, Keycloak erzwang die Required Action für TOTP, das MFA-Setup wurde abgeschlossen, und erst danach kam der Browser zurück ins Admin Dashboard. Genau so soll ein sicherer Flow aussehen.

1. Admin SSO auswählen.

2. Redirect zu Keycloak.

3. Authentifizierung durchführen.

4. TOTP-Setup als Required Action abschließen.

5. MFA verifizieren.

6. Zurück ins grommunio Admin Dashboard.

Warum Browser-SSO wirklich geprüft werden muss

Ein HTTP 200 sagt wenig darüber aus, ob ein Identity Flow funktioniert. SSO besteht aus Redirects, Cookies, OIDC-Callbacks, Anwendungssessions, MFA-Required-Actions und UI-Zuständen. Deshalb sollte die Abnahme immer als echter Browserablauf durchgeführt werden.

Application
    ↓
Redirect
    ↓
Keycloak
    ↓
Authentication
    ↓
MFA / Required Actions
    ↓
OIDC Callback
    ↓
Application Session
    ↓
Authenticated UI

Für eine belastbare Abnahme sollte der Browserlauf protokolliert werden: aufgerufene Anwendung, Redirect-Ziel, Callback, sichtbarer Login-Zustand und Fehler aus Browser-Konsole oder Serverlogs. So bleibt nachvollziehbar, ob Web, Files, Chat, Archive und Admin wirklich über SSO funktionieren.

Eine Anmeldung, mehrere Anwendungen

SSO bedeutet nicht zwingend, dass eine Anwendung ohne jeden Redirect sofort eine eigene Session besitzt. In der Praxis kann der Ablauf weiterhin über Keycloak laufen, aber die bestehende Identity-Session wird wiederverwendet. Genau dieses Verhalten wurde zusätzlich in einem gemeinsamen Browser-Kontext gemessen.

Wechsel im selben Browser-Kontext       Beobachtung
Web Login                                erfolgreich als alice@example.test
Web -> Archive                           transparente Keycloak-Session wiederverwendet
Web -> Files                             Files zeigte den eigenen Login/SSO-Einstieg
Web -> Chat                              Chat zeigte den eigenen Login/SSO-Einstieg
Web -> Admin                             nicht im selben User-Kontext getestet

https://mail.example.test/files/

Screenshot: Cross-App-Test: Files zeigte beim direkten Einstieg weiterhin den eigenen Login mit Keycloak-Schaltfläche.

Das ist kein Widerspruch zu SSO, sondern eine wichtige Abnahme-Erkenntnis: Manche Anwendungen starten den OIDC-Flow transparent, andere erwarten zuerst den expliziten SSO-Einstieg innerhalb der Anwendung.

Autodiscover gehört zur Abnahme

Eine Groupware-Plattform besteht nicht nur aus Weboberflächen. Nach dem Upgrade wurden deshalb auch Autodiscover, Mozilla Autoconfig und zentrale Protokollpfade geprüft. Autodiscover V1 und V2 lieferten verwertbare Antworten, Autoconfig lieferte XML mit IMAP- und SMTP-Informationen, DAV antwortete authentifiziert mit 207 Multi-Status, EWS beantwortete eine SOAP-GetFolder-Anfrage auf die Inbox mit HTTP 200, und ActiveSync wurde bis Provisioning, FolderSync und initialem Sync geprüft.

Mailflow und Protokolle

Zusätzlich wurde SMTP Submission mit STARTTLS, Authentifizierung und lokaler Zustellung in eine Test-Mailbox geprüft. Per IMAPS wurde kontrolliert, dass die Nachricht in der Inbox angekommen ist. Webmail-Versand, Reply und Sent Items bleiben eigene Browser-Tests; ActiveSync-FolderSync wurde mit kontrolliertem Client geprüft, echte Mobilgeräte bleiben bei produktiver Nutzung ein eigener Abnahmeschritt.

Finaler Health Check

• Keine fehlgeschlagenen systemd Units.

• zypper ps -s meldete keinen notwendigen Reboot mehr.

• Keycloak aktiv.

• Admin API aktiv.

• Nginx aktiv.

• PHP-FPM aktiv.

• MariaDB aktiv.

• Redis aktiv.

• Gromox aktiv.

• Chat aktiv.

• Archive aktiv.

• Meet-Webroute erreichbar, jitsi-jicofo, jitsi-videobridge und prosody aktiv.

Upgrade-Checkliste

1. Vor dem Upgrade Paketstände, Services, Endpoints und SSO-Baseline sichern.

2. Offiziellen Upgrade-Pfad der eingesetzten Appliance-Version prüfen; zusätzlich kontrollieren, ob grommunio-update vorhanden ist und welche Paketbefehle die Herstellerdokumentation für genau diese Version beschreibt.

3. Paketupgrade durchführen und Reboot-Anforderung ernst nehmen.

4. Nach dem Reboot zypper ps -s und systemctl --failed prüfen.

5. Files mit occ status prüfen und nötigenfalls occ upgrade ausführen.

6. Chat-Accounts auf SSO migrieren, wenn bestehende Accounts vorhanden sind.

7. grommunio-auth-Adapter für alle relevanten Anwendungen prüfen.

8. TLS-Vertrauen für serverseitige OIDC-Discovery prüfen.

9. OIDC-Callbacks im Browser und in Logs prüfen.

10. Admin-Identity-Mapping über preferred_username bewusst festlegen.

11. MFA für Admin-Zugänge bis zum Dashboard testen.

12. Browser-Smoke-Test für Web, Files, Chat, Archive und Admin dokumentieren.

13. Native Protokolle mit realem FQDN, gültiger Trust Chain und synthetischen Testdaten prüfen.

14. Desktop- und Mobil-Clients nur dann als PASS werten, wenn ein frisches Profil beziehungsweise ein echter Testclient eingerichtet wurde.

Partner-Runbook: Reihenfolge für eigene Umgebungen

Wer den Beitrag als Vorlage für Kundenumgebungen nutzt, sollte die Schritte in dieser Reihenfolge ausführen. Die Werte aus dem Lab wie mail.example.test sind Platzhalter und müssen durch den echten FQDN, die echte Maildomain und die produktive oder interne CA ersetzt werden.

FAQ

Reicht zypper up als Upgrade-Test?

Nein. zypper prüft Pakete, aber nicht, ob Files-Datenbankmigration, OIDC-Discovery, Callback, MFA und Anwendungssessions funktionieren.

Sollte man grommunio-update verwenden?

Auf der getesteten Appliance ist grommunio-update vorhanden und bietet check, update und upgrade an. Gleichzeitig beschreibt die aktuell geprüfte grommunio Operations-Dokumentation Package Updates über zypper ref und zypper up. Für Runbooks heißt das: nicht raten, sondern pro Version die Herstellerdokumentation und das installierte Werkzeug prüfen.

War MFA ein Fehler im Admin-Login?

Nein. Wenn Keycloak eine TOTP-Required-Action erzwingt, ist das erwartetes Security-Verhalten. Wichtig ist, den Flow bis zum abgeschlossenen MFA-Setup und zurück ins Admin Dashboard zu testen.

Muss jeder diese manuellen Schritte ausführen?

Nicht pauschal. Der Artikel trennt Herstellerverhalten, erwartete Automatisierung, mögliche Nacharbeiten in bestehenden Umgebungen und umgebungsspezifische Sonderfälle. Genau deshalb sollten Upgrades vor Produktion reproduzierbar getestet werden.

Fazit

Ein Upgrade auf grommunio 2026.06.2 ist erst nach vollständiger technischer Abnahme wirklich aussagekräftig. Entscheidend sind nicht nur Pakete und Dienste, sondern DB-Migrationen, Identity-Konfiguration, TLS-Vertrauen, Callback-Verhalten, MFA und echte Browser-Flows.

Für produktive Umgebungen ist genau das der Unterschied zwischen einem Update und einem belastbaren Plattform-Upgrade.