Meldungsnummer: 201803061809
Zeitraum: seit 01.03.2018
Betroffen: ownCloud-Benutzer mit Desktop- und Mobilclients
Auswirkungen: Clients verloren regelmäßig Zugriff
Seit etwa fünf Tagen fielen die ownCloud-Clients dadurch auf, dass diese gelegentlich, in unregelmäßigen Abständen, ihre Authorisierung zu vergessen schienen. Da in dieser Zeit vom GWDG ownCloud-Team keine weiteren Änderungen am System durchgeführt wurden, standen wir hier vorerst ratlos vor einem sehr diffusen Problem.
Für alle, die sich nicht für technische Details des Problems interessieren, hier die kurze Zusammenfassung:
Eine größere Latenz zwischen den Datenbank-Servern führte zu dem beschriebenen Verhalten. Eine Zwischenlösung wurde implementiert, die saubere Lösung im Testsystem ausgerollt.
Nun zu den technischen Details:
Wir benutzen in ownCloud als Datenbank-Server ein Galera Cluster mit Maxscale als Connection Router. Das Datenbank-Cluster besteht aus drei Knoten, die redundant über drei Standorte verteilt sind. Der Connection Router benutzt beim Verteilen der Anfragen ein sogenanntes Read-Write-Splitting, welches Schreibzugriffe immer auf einen Server und Lesezugriffe auf die beiden anderen Server verteilt. Der Vorteil davon ist, dass dann eine sehr leselastige Anwendung wie ownCloud von mehreren lesenden Servern profitieren kann. So weit, so gut.
Die ownCloud-Clients benutzen seit Version 10 die sogenannte oAuth-Authorisierung. Hierbei muss theoretisch einmalig ein sogenanntes Refresh-Token im Client gespeichert werden, um sich mit dem Refresh-Token für zukünftige Anmeldungen ein sogenanntes Auth-Token vom Server abzuholen.
Das Erstellen des Refresh-Tokens bemerken die Benutzer, wenn Sie im Browser einmalig zustimmen müssen, dass dieser Client auf den eigenen ownCloud-Account zugreifen darf. Läuft das mit dem Refresh-Token erzeugte Auth-Token ab, holt sich der Client ein neues Auth-Token. Dieser Prozess sollte vom Benutzer nicht bemerkt werden und passiert stündlich.
Möchte sich ein Client also kurz darauf mit dem neu erhaltenen Auth-Token am Server anmelden, kann es passieren, dass durch zu langsame Replikation des Datenbank-Clusters das Token noch nicht auf den lesenden Servern angekommen ist. Die Authorisierung schlägt fehl und der Benutzer wird erneut aufgefordert, der Erzeugung eines neuen Refresh-Tokens zuzustimmen.
Als kurze Zwischenmaßnahme wurde in allen Produktivsystemen auf das Read-Write-Splitting verzichtet und alle Server gegen einen einzelnen Datenbank-Server konfiguriert.
Wir testen aktuell in den Testsystemen einen Filter, der alle zu einem Schreibzugriff gehörenden Lesezugriffe innerhalb eines bestimmten Intervalls auf den gleichen Datenbank-Server routet. Sollte sich dieser innerhalb dieser Woche als stabil erweisen, wird der Filter auch in den Produktivsystemen ausgerollt.