[sc name=“head_betriebsmeldungen_de“ meldungsnummer=“201803061809″ zeitraum=“seit 01.03.2018″ betroffen=“ownCloud-Benutzer mit Desktop- und Mobilclients“ auswirkungen=“Clients verloren regelm\u00e4\u00dfig Zugriff“ ]<\/p>\n
Seit etwa f\u00fcnf Tagen fielen die ownCloud-Clients dadurch auf, dass diese gelegentlich, in unregelm\u00e4\u00dfigen Abst\u00e4nden, ihre Authorisierung zu vergessen schienen. Da in dieser Zeit vom GWDG ownCloud-Team keine weiteren \u00c4nderungen am System durchgef\u00fchrt wurden, standen wir hier vorerst ratlos vor einem sehr diffusen Problem.<\/p>\n
F\u00fcr alle, die sich nicht f\u00fcr technische Details des Problems interessieren, hier die kurze Zusammenfassung:<\/p>\n
Eine gr\u00f6\u00dfere Latenz zwischen den Datenbank-Servern f\u00fchrte zu dem beschriebenen Verhalten. Eine Zwischenl\u00f6sung wurde implementiert, die saubere L\u00f6sung im Testsystem ausgerollt.<\/p>\n
Nun zu den technischen Details:<\/p>\n
Wir benutzen in ownCloud als Datenbank-Server ein Galera Cluster mit Maxscale als Connection Router. Das Datenbank-Cluster besteht aus drei Knoten, die redundant \u00fcber 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.<\/p>\n
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\u00fcr zuk\u00fcnftige Anmeldungen ein sogenanntes Auth-Token vom Server abzuholen.<\/p>\n
Das Erstellen des Refresh-Tokens bemerken die Benutzer, wenn Sie im Browser einmalig zustimmen m\u00fcssen, dass dieser Client auf den eigenen ownCloud-Account zugreifen darf. L\u00e4uft 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\u00fcndlich.<\/p>\n
M\u00f6chte 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\u00e4gt fehl und der Benutzer wird erneut aufgefordert, der Erzeugung eines neuen Refresh-Tokens zuzustimmen.<\/p>\n
Als kurze Zwischenma\u00dfnahme wurde in allen Produktivsystemen auf das Read-Write-Splitting verzichtet und alle Server gegen einen einzelnen Datenbank-Server konfiguriert.<\/p>\n
Wir testen aktuell in den Testsystemen einen Filter, der alle zu einem Schreibzugriff geh\u00f6renden 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.<\/p>\n","protected":false},"excerpt":{"rendered":"
[sc name=“head_betriebsmeldungen_de“ meldungsnummer=“201803061809″ zeitraum=“seit 01.03.2018″ betroffen=“ownCloud-Benutzer mit Desktop- und Mobilclients“ auswirkungen=“Clients verloren regelm\u00e4\u00dfig Zugriff“ ] Seit etwa f\u00fcnf Tagen fielen die ownCloud-Clients dadurch auf, dass diese gelegentlich, in unregelm\u00e4\u00dfigen Abst\u00e4nden, ihre Authorisierung zu vergessen schienen. Da in dieser Zeit vom GWDG ownCloud-Team keine weiteren \u00c4nderungen am System durchgef\u00fchrt wurden, standen wir hier vorerst ratlos vor … Weiterlesen<\/a><\/p>\n","protected":false},"author":11,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-9470","post","type-post","status-publish","format-standard","hentry","category-betriebsmeldungen"],"_links":{"self":[{"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/posts\/9470","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/comments?post=9470"}],"version-history":[{"count":5,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/posts\/9470\/revisions"}],"predecessor-version":[{"id":9477,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/posts\/9470\/revisions\/9477"}],"wp:attachment":[{"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/media?parent=9470"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/categories?post=9470"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/tags?post=9470"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}