Magie ist kompliziert - aber halt auch cool. Auf Uberspace 7 setzen wir auf ein klein wenig Magie, um Let's Encrypt Zertifikate für alle eure Domains zu holen. Das klappt auch voll gut! ... meistens.

tldr-intermezzo: HTTPS für User-Domains (also alle relevanten) ist vom 6.6.2018 4 bis circa 8 Uhr auf 4 Hosts (whipple, taylor, kojima und klemola) ausgefallen. Es handelte sich dabei um einen einmaligen Fehler und kein generelles Problem. Fürs Warum und zukünftige Gegenmaßnahmen, einfach weiterlesen.

"error: ngx_http_lua_module required" oder:
Wie war das nochmal mit Lua und nginx?

Mit der eingangs erwähnten auto-ssl-Magie läuft in unserem nginx/openresty nicht nur Config, sondern auch Lua-Code. Dieser hat eine Hand voll Lua-Modulen als Dependencies. Wenn der nginx initial gestartet wird, landen all diese Module im RAM und verbleiben für die Laufzeit des Prozesses auch dort. Im Falle eines Reloads werden die Worker-Prozesse des nginx neugestartet, woraufhin sie sich die notwendigen Module neu laden. Der Master bleibt unangetastet, gibt aber natürlich Meta-Informationen an die Worker weiter.
Wenn nun ein nginx-Update ausgerollt wird ändern sich ggf. die Module auf der Festplatte. Da sie aber in RAM liegen, ist das erstmal egal -- bis zu einem Reload. Dann laden die Worker ihre Module neu, sind verwirrt und krach-bumms-dependencysalat:

2018/06/06 03:47:13 [error] 7586#7586: *5636697 lua entry thread aborted: runtime error: /usr/local/openresty/lualib/resty/core/base.lua:23: ngx_http_lua_module 0.10.13+ required
stack traceback:
coroutine 0:
        [C]: in function 'require'
        .../local/openresty/luajit/share/lua/5.1/resty/auto-ssl.lua:88: in function 'ssl_certificate'
        ssl_certificate_by_lua:2: in function <ssl_certificate_by_lua:1>, context: ssl_certificate_by_lua*, client: 2a00:d0c0:200:0:b9:1a:9c:57, server: [::]:443

Unschön, aber einfach durch einen einfachen Restart fixbar.

Updates!

In eurem und unseren Sinne rollen wir regelmäßig OS-Updates aus. Da uns das oben geschilderte nginx-Problem bekannt ist, bekommen alle nginxe anschließend einen Restart: HTTPS da ➡️ ihr glücklich ➡️ wir glücklich. Genauso haben wir auch am Abend des 5.6. Updates gemacht.

Ein Kollege hat - ein paar Tage zuvor - einem Testhosts Updates verpasst, den nicht eintretenden Weltuntergang abgewartet und dann schließlich am 5.6. mit dem passenden Ansible-Playbook auf alle Hosts ausgerollt und wie beschrieben den nginx durchgetreten. Monitoring war still, Hosts wirkten gesund und Twitter hatte auch keine Beschwerden zu verzeichnen.

Durch ein unabhängiges Problem mit dem .NET-Repository von Microsoft haben es die Updates allerdings nur auf vier Hosts geschafft: whipple, taylor, kojima und klemola. Genau die vier Ausfallkandidaten.

der tödliche Reload

Aufmerksame Leserinnen können sich nach dem länglichen Intro schon denken, was passiert ist: der nginx-Restart wurde nicht wie geplant ausgeführt und irgendetwas(TM) hat einen Reload getriggert. Gemerkt hat das leider niemand sodass die vier Hosts einfach mal weitergelaufen sind -- bis um kurz vor vier Uhr früh.

Genau dann läuft das cron.daily und darin ein Logrotate was für einen -- Trommelwirbel -- nginx Reload sorgt:

Jun 06 03:47:01 taylor.uberspace.de anacron[20891]: Job `cron.daily' started
Jun 06 03:47:01 taylor.uberspace.de run-parts(/etc/cron.daily)[7429]: starting logrotate
Jun 06 03:47:05 taylor.uberspace.de uberspace-generate-nginx-config[7542]: generating config for pumuckl
Jun 06 03:47:05 taylor.uberspace.de uberspace-generate-nginx-config[7542]: generating config for blargh
(...)
Jun 06 03:47:05 taylor.uberspace.de systemd[1]: Reloaded HTTPS-Frontend (NGINX HTTP and reverse proxy server).

Anschließend war der Webserver nicht mehr motiviert weitere Anfragen für User-Domains (nicht jedoch die taylor.uberspace.de-Domain!) zu beantworten. Da zufällig keiner unserer privaten Uberspaces betroffen war, haben wir das dann auch erst durch Useranfragen gemerkt und dann durch eine pauschale Runde nginx-Restarts behoben.

aber habt ihr denn kein Monitoring?!

Doch, doch, natürlich. Aber leider nur für die taylor.uberspace.de-Domain. Domains, die durch User hinzugefügt werden testen wir vor jedem Deployment und nach jedem Commit automatisiert in unserem GitLab; jedoch nicht mehr auf jedem einzelnen Produktivsystem. So wurden wir erst duch Useranfragen auf das Problem aufmerksam.

Die Zukunft(TM)

Dieser Fehler hat auf 4 Hosts für eine Downtime auf von circa 7 Stunden verursacht. Auch wenn diese Großteils vor in Europa üblichen Wachzeiten war, ist das natürlich inakzeptabel.

Wir haben initial mehrere Maßnahmen getroffen, um solche Fehler in Zukunft zu vermeiden oder zumindst schneller zu bemerken:

1. Wir werden die technischen Hürden überkommen müssen und ein Monitoring für produktive User-Domains bauen. Dieses hätte uns in diesem Fall aufgeweckt, sodass die Downtime nur Minuten, statt Stunden, betragen hätte.
2. OS-Updates werden künftig wie normale Uberspace-Updates über GitLab ausgeführt. So ist sichergestellt, dass ein fehlgeschlagenes Update auffällt, klar ist wann Updates gelaufen sind und Logs bleiben nachvollziehbar.

Einer unserer Leitsätze lautet: Haben wir etwas richtig gemacht oder haben wir etwas dazu gelernt? In diesem Fall bitten wir die betroffenen User um Entschuldigung und haben etwas dazu gelernt.

First things first: Es gibt nun einen fertigen Vertrag zur Auftragsverarbeitung, der den Segen unseres externen Datenschutzbeauftragen bekommen hat. Du findest ihn unter https://uberspace.de/dpa und wir haben alles vorbereitet, damit du ihn Anfang ab nächster Woche im Dashboard per Klick abschließen kannst. Du kannst ihn insofern bereits lesen und prüfen oder prüfen lassen, beispielsweise durch deinen Datenschutzbeauftragten, und dann nächste Woche deinen Klick setzen.

Was noch fehlt, ist die Abnahme unseres Entwurfs zur Dokumentation der technischen und organisatorischen Maßnahmen durch unseren externen Datenschutzbeauftragten - dessen Workload, wie man sich vielleicht vorstellen kann, im Rahmen allgemeiner DSGVO-Panik gerade durch die Decke geht und der wundersamerweise dennoch Zeit findet, sich jedwedes Dokuments innerhalb von 2-3 Werktagen anzunehmen. Die vorige von uns gelieferte Fassung fand bereits Zuspruch und bedurfte nur noch geringer Änderungen an der Struktur des Dokuments, so dass die letzte Abnahme nur noch eine Formalität ist.

Aber mal einen Schritt zurückgetreten und durchgeatmet:

Was ist eigentlich diese Auftragsverarbeitung, von der alle reden?

Grundsätzlich ist erst einmal wichtig zu verstehen, dass der Dreh- und Angelpunkt die Frage ist, ob personenbezogene Daten im Spiel sind oder nicht, denn wenn nicht, kannst du im Grunde aufhören zu lesen. Im Rahmen von Webhosting wird hierbei gerne schnell auf das Thema Logging abgestellt. In diesem Punkt können wir dich beruhigen: Wenn ein access_log erstellt wird (unter U6 ist das der Fall, unter U7 ist es standardmäßig nicht der Fall, kann aber aktiviert werden), so sind darin grundsätzlich alle IP-Adressen gekürzt und gelten insofern nicht mehr als möglicherweise personenbezogene Daten. Es ist also unsererseits dafür gesorgt, dass nicht allein durch die Benutzung deines Uberspaces schon personenbezogene Daten anfielen. (Unter U6 gibt es mit dem error_log derzeit noch den Pferdefuß, dass darin vollständige IPs zu finden sind, was sich technisch auch nicht vermeiden lässt; wir werden dem in Kürze dafür mit deutlich reduzierter Aufbewahrungsdauer begegnen. Das error_log ist aber bei U6 wie bei U7 standardmäßig aus, und bei U7 haben wir eine saubere Lösung dafür gefunden, auch im error_log nur gekürzte IPs zu zeigen.)

Zeit also, um den Blick darauf zu lenken, wie du deinen Uberspace nutzt: Veröffentlichst du beispielsweise einen Blog ohne Kommentarfunktion (so wie dieser hier, den du gerade liest)? Dann sind nämlich keine personenbezogenen Daten im Spiel. Verwendest du eine Kommentarfunktion? Dann ist immer noch die Frage, ob du dort einen Klarnamen und/oder eine E-Mail-Adresse erfasst oder ob deine Besucher ohne diese Angaben anonym kommentieren können - und, ob du deren IP-Adresse speicherst oder nicht. Oder verwendest du einen externen Kommentarservice wie z.B. Disqus? Dann werden ggf. erfasste personenbezogene Daten eben nicht mehr bei uns verarbeitet, sondern bei Disqus, und die Frage der Auftragsverarbeitung verschiebt sich von uns zu denen.

Verwendest du E-Mail? Dann haben wir es auch hier mit Auftragsverarbeitung zu tun, denn wann immer du eine Mail an jemanden sendest oder von jemandem erhältst, gelangt ein personenbezogenes Datum - nämlich die Mailadresse des Gegenübers - auf unsere Systeme. Da hilft auch keine E-Mail-Verschlüsselung, denn die Mailadressen stehen ja als Metadaten sozusagen außen auf dem Briefumschlag, was für den Transport ja auch zwingend erforderlich ist.

Soll heißen: Um personenbezogene Daten geht es zwar nicht automatisch mit Nutzung deines Uberspaces für Webhosting - aber sie sind sehr schnell im Spiel. Die Frage, ob Auftragsverarbeitung vorliegt, hängt insofern davon ab, wie du deinen Uberspace nutzt, und das kannst nur du selbst beantworten.

Ein anderer wichtiger Dreh- und Angelpunkt ist aber auch die Frage, ob du deinen Uberspace zu unternehmerischen Zwecken nutzt oder nur zu persönlichen und familiären Zwecken - Artikel 2 (2) c DSGVO stellt nämlich klar, dass die Verordnung darauf keine Anwendung findet und dich insofern auch das Thema Auftragsverarbeitung nicht jucken muss.

Nur für den Fall, dass du jetzt sagst "Ach sooo! Hättet ihr das nicht gleich sagen können?" - Ja, hätten wir, aber es erschien uns dennoch sinnvoll, dich selbst wenn es deinen konkreten Nutzungsfall nicht betrifft, ein wenig mit in die Gedankenwelt der DSGVO zu nehmen. Und außerdem gilt zu beachten: Die genannten persönlichen und familiären Zwecke sind sehr eng gefasst, und du musst nicht erst ein Unternehmen gründen, um über die Schwelle zu hüpfen, ab der die DSGVO dann doch gilt. Die Rechtsprechung hat schon in der Vergangenheit gezeigt, dass bereits beim Einblenden von Werbeanzeigen oder der Bereitstellung von Affiliate-Links ein Blog als Einkommensquelle und damit nicht mehr als reine Privatsache angesehen wird, und es ist davon auszugehen, dass das auch in Bezug auf Datenschutzfragen ähnlich gehandhabt werden dürfte.

Wenn du dir nun ziemlich sicher bist, dass du deinen Uberspace vielleicht nicht zu 100% nur zu persönlichen oder familiären Zwecken verwendest, und dass auf deiner Website personenbezogene Daten verarbeitet werden, zum Beispiel mit einem Blog mit Kommentarfunktion mit Erfassung einer Mailadresse, dann heißt es: Hallo, Auftragsverarbeitung! Denn damit ziehst du uns als Dienstleister hinzu und verarbeitest die Daten nicht mehr ganz alleine. Der Begriff der "Verarbeitung" ist dabei sehr weit gefasst und erfordert überhaupt nicht, dass wir die Daten im wörtlichen Sinne auch verarbeiten, also tatsächlich irgendetwas damit tun. Vielmehr ist bereits der Umstand, dass nicht sicher ausgeschlossen werden kann, dass wir auf personenbezogene Daten, die du auf deinem Uberspace verarbeitest, zugreifen können. Ob wir das in Praxis auch tun oder nicht, ist dabei völlig unerheblich.

In diesen Fällen einen Vertrag zur Auftragsverarbeitung abzuschließen, entspringt insofern deinem Interesse und nicht originär unserem. Unser Interesse ist, dass du weiterhin - rechtskonform - bei uns hosten kannst, wozu wir dir den Abschluss eines Vertrags zur Auftragsverarbeitung anbieten müssen. Gegenüber denen, deren personenbezogene Daten du erfasst, bist nämlich du selbst verantwortlich, und das heißt, du musst bei der Auswahl der Unternehmen, die du hinzuziehst, um dir dabei zu helfen, die Daten zu verarbeiten (in unserem Fall also mit der Bereitstellung einer Hostingplattform, die dich davon entbindet, dir eigene Hardware kaufen zu müssen, in ein Rechenzentrum zu stellen, sie zu warten, sie auf korrekte Funktion zu überwachen etc.) entsprechend Sorgfalt walten lassen; das schuldest du denen, deren Daten du verarbeitest. Mit dem Abschluss eine Vertrags zur Auftragsverarbeitung stellst du klar, dass wir ausschließlich weisungsgebunden mit deinen Daten umgehen dürfen, also damit nicht einfach tun können, was wir wollen. Außerdem bekommst du durch die Dokumentation der technischen und organisatorischen Maßnahmen eine konkrete Zusammenstellung der Dinge, die wir zum Schutz deiner Daten unternehmen, und damit mehr als ein werbespruchhaftes "Deine Daten sind bei uns sicher". Das bedeutet natürlich nicht, dass nicht dennoch etwas schiefgehen kann - aber die Verantwortlichkeiten dafür sind dann klar geregelt. Gegenüber denen, deren personenbezogene Daten du verarbeitest, stellt es ja einen qualitativen Unterschied dar, ob du denen sagst: Joah, ich hab da so EDV-Zeugs, da liegen die drauf; keine Ahnung, ob der Betreiber die aktuell hält oder eine Datensicherung macht - oder ob du denen sagst: Das EDV-Zeugs von den Ubernauten wird ordentlich gemacht; es gibt einen sauberen Vertrag, und wir wissen, welche konkreten Maßnahmen die in puncto Datenschutz unternehmen, und ich befinde diese Maßnahmen für ausreichend, um denen zuzutrauen, dass sie auch mit deinen Daten seriös umgehen, und das heißt auch: Ausschließlich gemäß meiner Weisungen.

Die technischen und organisatorischen Maßnahmen sind im Gegensatz zum eigentlichen AV-Vertrag volatil - sie liegen dem Vertrag insofern nur als Anlage bei. Insbesondere bei Technik ist es eben so, dass die durch schlichtes Nichtstun - im Verhältnis - schlechter wird, einfach weil die Welt drumherum sich fortentwickelt und Stillstand früher oder später nicht mehr dem entspricht, was man gemeinhin als "Stand der Technik" bezeichnet. Insofern entwickeln sich auch die Maßnahmen, die wir zum Schutz deiner Daten unternehmen, weiter. Die technischen und organisatorischen Maßnahmen können sich insofern jederzeit verändern - aber entsprechend nur in Richtung "besser" ("sicherstellen, dass das Sicherheitsniveau der festgelegten Maßnahme nicht unterschritten wird", wie es dazu in Punkt 5.2.2 des AV-Vertrags heißt).

Mit der Bereitstellung des Vertrags zur Auftragsverarbeitung und der technischen organisatorischen Maßnahmen ist die Zielgerade der DSGVO-Konformität für uns dann in greifbarer Nähe (ein paar Kleinigkeiten fehlen noch, die aber auch schon vorbereitet sind). Aber auch wenn hier dann vermutlich erleichtert die Sektkorken knallen, im branchenübergreifenden Sprint zum 25.5. ein gutes Ziel erreicht zu haben, so geht der Weg danach weiter - nicht zuletzt deshalb, weil die DSGVO auch viele Fragezeichen mit sich bringt, die im Lauf von Monaten oder auch Jahren noch Gerichte beschäftigen werden, wie denn Dieses oder Jenes konkret auszulegen ist. Die Bestellung eines externen Datenschutzbeauftragten ist für uns das klare Bekenntnis, Datenschutz nicht als lästiges Übel, sondern als Selbstverständlichkeit zu betrachten, und wir haben damit einen Wegbegleiter, der uns - wie wir mit inzwischen zwei persönlichen Treffen zusätzlich zur überbordenden E-Mail-Kommunikation feststellen konnten - mit großer Begeisterung dabei hilft, besser zu werden. Darauf freuen wir uns mit euch.

Die Datenschutzgrundverordnung (DSGVO), die vor knapp zwei Jahren eingeführt und europaweit ab dem 25.05.2018 anwendbar wird, hat bei uns wie auch bei vielen anderen zu Fragen und Unsicherheiten geführt. Nun sind wir aber langsam aber sicher auf der Zielgeraden, die nötigen Vorgaben fristgerecht umzusetzen. Dazu gehört neben diversen neuen Dokumentationspflichten insbesondere die Bereitstellung eines Vertrags zur Auftragsverarbeitung, der aktuell in Kooperation mit unserem externen Datenschutzbeauftragen finalisiert wird und mit dem voraussichtlich in der nächsten Woche gerechnet werden kann.

Apropos! Wir haben so einige Zeit gerätselt, ob wir gemäß der Anforderungen des Bundesdatenschutzgesetzes (BDSG) und/oder der DSGVO bereits die Kriterien erfüllen, um einen Datenschutzbeauftragten benennen zu müssen oder nicht: Was sind Personen, die "regelmäßig mit automatisierter Datenverarbeitung (Erhebung und Nutzung) zu tun haben"? Trifft das auf einen Supportmitarbeiter zu? Trifft es auf einen Mitarbeiter zu, der lediglich das Blech in ein Rack schraubt? Trifft es auf die Buchhalterin zu, die Kontoumsätze abfragt, aber auf Server keinen Zugriff hat? Wird bei der Verarbeitung von persönlichen Daten ein Detailgrad überschritten, der die Bestellung eines Datenschutzbeauftragten erforderlich macht? Ist Webhosting Auftragsdatenverarbeitung, wenn die Software, die vielleicht am Ende eine Lücke hat und persönliche Daten leakt, nicht von uns, sondern von unseren Usern installiert wird? Ist das Anfertigen von Backups Auftragsdatenverarbeitung, obwohl wir damit nur bestehende Sorgfaltspflichten erfüllen? Fragen über Fragen, und wer sich erst ins offene Feld der Jura-Foren bewegt, der versteht in der Regel hinterher eher weniger als mehr. Um dies ein wenig zu verdeutlichen - kleiner Rückblick:

Es war 2011 und damit im IT-Leben eine halbe Ewigkeit her, als IT-Fachanwalt Thomas Stadler unter dem wunderbaren Titel Aberwitziger Datenschutz made in Germany bloggte:

Wenn man zudem das Hosting, wie es der Landesdatenschutzbeauftragte tut, als Auftragsdatenverarbeitung im Sinne von § 11 BDSG begreift, müssten damit eigentlich fast alle deutschen Websites vom Netz genommen werden und Massenhoster wie 1&1 und Strato könnten ihr Geschäft sofort einstellen. Denn wenn die Rechtsansicht der Datenschutzbehörde zutreffend wäre, würde dies bedeuten, dass jeder Webseitenbetreiber mit seinem Host-Provider eine schriftliche Vereinbarung über eine Auftragsdatenverarbeitung abschließen müsste, die die äußerst strengen Anforderungen von § 11 Abs. 2 BDSG erfüllt. Die Haltung des niedersächsischen Landesbeauftragten kann man daher getrost als aberwitzig bezeichnen.

Wir sind dieser Lesart offen gesagt ziemlich lange gefolgt, müssen aber anerkennen, dass sich spätestens im Kontext des DSGVO-Flächenbrands der Wind dahin gedreht hat, dass sich die Situation heute so darstellt, dass Herrn Stadlers als "abwitzig" beurteilte Einschätzung heute in großer Breite als Stand der Dinge angesehen wird - denn letzten Endes können wir technisch gesehen auf die Daten unserer User zugreifen; das ist eben so und wir machen daraus auch kein Geheimnis. Wenn nun ein Shop bei uns gehostet wird und ein Endkunde dort eine Bestellung tätigt, fließen natürlich logischerweise dessen persönliche Daten durch unseren Webserver; das, was man gemeinhin als "Verarbeitung" betrachten würde, passiert dann aber in der Shopsoftware - die diese Daten höchstwahrscheinlich in eine Datenbank schreibt, sie aktualisiert und archiviert. Diese Shopsoftware haben wir aber weder installiert, noch benutzen wir jene, noch warten wir jene, noch kennen wir jene. Es erschien uns insofern nie wirklich plausibel, inwiefern wir hier Daten im Auftrag verarbeiten sollten - ein Grund, warum wir uns lange gegen den Abschluss von Verträgen zur Auftragsverarbeitung gewehrt haben (man beachte die Vergangenheitsform).

Was man nicht vermeiden kann, das sollte man besser lieben lernen. Die DSGVO mit offenen Armen zu empfangen, ist aber leichter gesagt als getan: Selbst viele Anwälte betrachten sie als eines der sperrigeren Dokumente, mit denen man so im Unternehmensalltag konfrontiert wird, und das ist ein Problem.

Niemand von uns ist Jurist, und niemand von uns brennt für die entsprechenden Gesetzestexte. Wir sind IT-Menschen und interessieren uns für Protokolle, Verschlüsselung, Rechtetrennung, Anonymisierung, Pseudonymisierung, für Datenschutz im Sinne von "Wir wollen nicht, dass deine Daten verlorengehen" und auch Sinne von "Wir wollen nicht, dass deine Daten in falsche Hände geraten". Unser Geschäftsmodell basiert auch nicht auf der Verwertung deiner Daten, sondern darauf, uns für die Bereitstellung technischer Ressourcen sowie die entsprechende Unterstützung bezahlen zu lassen, damit wir von deinen Daten dafür getrost die Finger lassen können.

Was wir tun, tun wir mit Liebe, und uns ist insofern schon vor längerer Zeit klargeworden, dass uns jemand fehlt, der diese Liebe nicht nur für den Datenschutz, sondern vor allem auch für das Datenschutzrecht aufbringt. Nachdem es einige Zeit so aussah, dass wir dafür einen passenden Fachanwalt gefunden hatten, was sich dann aber in der Praxis als nicht unseren Vorstellungen entsprechend fruchtbar herausgestellt hat (und uns insofern noch einige Zeit im Plan hat zurückfallen lassen), können wir nun mit Freude verkünden, dass wir nach entsprechender Vorbereitung und persönlichen Gesprächen eine Rechtsanwaltsgesellschaft gefunden haben, die Datenschutzrecht mit Herzblut lebt, uns fortan in Datenschutzfragen berät und schult und auch als unser externer Datenschutzbeauftragter fungiert. Für uns sorgt das für weitaus besseren Schlaf, weil wir nun Leute an unserer Seite haben, die sich mit den rechtlichen Aspekten besser auskennen als wir, und für euch sollte es für besseren Schlaf sorgen, weil Rechtskonformität bei der Datenverarbeitung damit kein Fragezeichen mehr bleibt. Auf gute Zeiten!

TLDR: Es gab heute um 13:15 einen ungeplanten Reboot und eine damit verbundene, sehr kurze Downtime bei allen U7-Hosts. Grund war, dass wir wegen einem journald-Bug einen Reboot benötigt haben, diesen aber (intern) nicht sauber kommuniziert haben: Code ausgerollt, zack Reboot! Das tut uns leid und sollte in Zukunft nicht mehr passieren. Mehr dazu weiter unten.

Heute am 22.01.2018 gegen 13:15 wurden alle unsere Uberspace 7 Hosts nicht 100% geplant rebootet. Die meisten Hosts waren nach weniger als zwei Minuten wieder da; geplant oder gar angekündigt war der kurze Ausfall allerdings dennoch nicht. Wir möchten euch in diesem Blogpost darlegen, wie es überhaupt dazu gekommen ist.

Unser Deployment-Setup sieht es vor, dass manche Ansible-Rollen einen Reboot triggern dürfen. Bisher wurde diese Funktionalität nur von der Quota-Rolle genutzt, die Mount-Flags der Root-Partition umsetzen muss. Das geht bei unserem Datensystem und Setup eben nur mit einem Reboot. Im Normalfall passiert das während dem initialen Deployment des Systems - also lange bevor User ihre Accounts darauf bekommen.

The curious case of journald

Das Problem war eigentlich ganz einfach: Die systemd-Logs im journald wurden zu schnell gelöscht, wir wollten die gerne länger aufheben. Dazu gibt es natürlich ein Config-File und eine passende Option SystemMaxUse=, die beschreibt wie viel Platz maximal durch die Log-Files belegt werden darf. Wir haben diese Option also angepasst, den journald neugestartet (reloads unterstützt er nämlich nicht) und siehe da: Die Logs sind auf unserem Test-Systemen länger verfügbar. Alles gut.

Alles gut, bis wir versucht haben die Änderung zu integrieren. Plötzlich ist nämlich unser IMAP/POP3-Server dovecot beim Reload der Config unerwartet verstorben. Nach einem systemclt restart dovecot hat allerdings alles wie gewohnt funktioniert. Zunächst war uns der Zusammenhang zwischen einer journald-Änderung und einem Dovecot-Reload recht schleierhaft. Als wir uns allerdings mit strace an den Prozess gehängt haben, wurde die Sache klarer:

(...)
write(2, "Jan 18 11:30:39 master: Warning:"..., 75) = -1 EPIPE (Broken pipe)
(...)
+++ exited with 81 +++

Dovecot versucht während dem Reload etwas nach stderr (also File-Deskriptor 2) zu schreiben und scheitert dabei, weil die Pfeife kaputt ist. Grund ist, dass unsere Version von journald durch einen Bug nicht in der Lage ist bei einem Restart die schon offenen Log-Handles der laufenden Services an die neue Instanz weiterzugeben. Alle Prozesse, die also nach dem journald-Restart etwas ins systemd-Log schreiben möchten, müssen also mit dieser Situation umgehen. Dovecot tut es, indem er sich beendet. Dieser Bug ist neueren Versionen von systemd bereits gefixt, auf CentOS 7 allerdings nicht.

Die einzig saubere Möglichkeit dem journald eine neue Config zu geben, ist in unserem spezifischen Setup also ein Reboot. Zum Glück müssen wir gerade diese Config nur einmalig, oder nie wieder anfassen, sodass ein Reboot an sich kein großes Problem darstellt.

Kommunikation, Kommunikation, Kommunikation

Nachdem Janto und ich das zugrunde liegende journald-Problem gefunden haben, hat die journald-Config einen Reboot-Trigger bekommen, die Tests liefen durch und wir waren glücklich. Moritz hat ein paar Tage später (so wie immer) ein Release zusammengepackt, das Changelog geschrieben und vertwittert, dass es jetzt ein Uberspace 7.0.25 gibt. Was aber niemand außer uns beiden Devs wusste, ist, dass dieses Release einen Reboot auslöst. Hier sehen wir unser großes Versäumnis, das letzten Endes zu der oben beschrieben kleinen Downtime geführt hat.

Die Moral von der Geschicht'

Wir haben in diesem Fall Glück im Unglück, weil die meisten Hosts in unter 2 Minuten wieder verfügbar waren. Wir haben den "Ausfall" also großteils selbst erst mitbekommen, als er schon wieder vorbei war. Dennoch ist es absolut nicht in unserem Interesse unangekündigt und solange die Sonne scheint Hosts zu rebooten.

Damit das in Zukunft nicht wieder passiert, haben wir uns darauf verständigt in unserem internen Changelog Änderungen, die einen Reboot triggern können, klar als solche zu kennzeichnen. So können wir die Reboots, wie fast alle anderen in der Vergangenheit auch, via Twitter ankündigen und zu einer weit ruhigeren Zeit spät nachts durchführen.

Auch wenn wir mit unserem Kommunikationsfail nur eine sehr kurze Downtime erzeugt haben, die von den allermeisten vermutlich nicht mal registriert wurde, möchten wir hiermit um Entschuldigung bitten. Wir haben daraus gelernt und werden versuchen solche Fälle in der Zukunft zu vermeiden.

TLDR: Eine Hand voll Shared-Hosting-Anbietern ist im Moment von einer Lücke im Zusammenhang mit Let's Encrypts tls-sni-01 Challenge betroffen. Wir nicht. Warum steht weiter unten.

Let's Encrypt unterstützt neben der bekannten http-01 Challenge (das ist die mit den wunderschönen /.well-known/acme-challenge/evaGxf...-URLs) auch andere Validierungsformen wie dns-01 (involviert "Magic"-Records im DNS) und auch tls-sni-01. In diesem Fall findet die Validierung im TLS-Protokoll selbst, noch vor HTTP statt. Dazu müssen spezielle, selbst-signierte Zertifikate ausgeliefert werden. Die von euch, die das genauer interessiert: hier geht's lang zum Standard-Dokument.

Nun hat ein Sicherheitsforscher Probleme mit der Implementation von tls-sni-01 bei vielen Shared-Hosting-Anbietern gefunden. Diese Lücke ermöglicht es einer Angreiferin Zertifikate für fremde Domains auf dem selben Host (bzw. unter der selben IP-Adresse) zu erhalten. Wenn es gerade eben darum geht festzustellen, ob dem Antragssteller die angefragte Domain überhaupt gehört, ist das eher ungut.

Wir sind von dieser Lücke bei ...

• ... Uberspace 6 nicht betroffen, weil unser uberspace-add-certificate ausschließlich Zertifikate zulässt, die von einer offiziellen CA ausgestellt wurden. Die für den Angriff notwendigen Zertifikate schaffen es also gar nicht bis in den Webserver.
• ... Uberspace 7 nicht betroffen, weil a) wir dort auf http-01 setzen und b) dort im Moment keine eigenen Zertifikate möglich sind.

Wir wünschen also fröhliches und sicheres weiterbasteln! :)

TLDR: Wir sind (wie alle mit Intel-CPUs) von Meltdown und Spectre betroffen. Es gibt Fixes. Sie einzuspielen erfordert einen Reboot. Siehe Liste dazu weiter unten.

Das Problem

Anfang Jänner wurde bekannt, dass alle neueren Intel-CPUs, AMD-CPUs in manchen Konstellationen und sogar einzelne ARM-CPUs von zwei Timing-Sicherheitslücke betroffen sind. Sie tragen die wunderschönen Namen Meltdown und Spectre. Diese Lücken ermöglichen es im Worst-Case privaten Speicher aus dem Kernel auszulesen und so fremde Daten in die Hände zu bekommen.

Der Fix

Das tatsächliche Problem kann dabei nur in der CPU selbst gefixt werden. Es ist jedoch möglich in Software nachzubessern, sodass die Lücken nicht weiter ausnützbar sind. Das Linux-Projekt, die Compiler-Toolchain LLVM aber auch Browser wie Firefox haben hier entsprechende Patches veröffentlicht.

... und bei uberspace?

Wir setzen (wie so ziemlich alle) CPUs von Intel ein. Es sind demnach alle Uberspace VMs, sowie die Wirt-System auf denen diese laufen verwundbar. Da die jetzt notwendigen Patches in unserem Fall den Kernel selbst betreffen, können wir sie nur zusammen mit einem Reboot einspielen. Das bedeutet für eure Webseiten und Services eine Downtime von 5 bis 15 Minuten. Wann genau diese für euren Uberspace stattfindet, haben wir in der Liste weiter unten dokumentiert.

Sollten dazu weiter Fragen aufkommen oder sollte es im Zusammenhang mit den Reboots zu Problemen kommen, melde dich gerne bei unserem Support: hallo@uberspace.de oder auf Twitter @ubernauten.

Reboots

Wir haben in der Zeit von 05.01.2018 00:30 bis 06.01.2018 00:30 alle unsere Uberspace Hosts gepatcht und neugestartet. Wir erwarten in diesem Zusammenhang keine weiteren Downtimes.

tl;dr

• Wir hatten uns in der Entwicklung darauf verständigt, virtuelle DocumentRoots - ein Feature von U5 und U6 - bei U7 nicht mehr als Feature anzubieten, sondern im Lauf der U7-Beta ein neues Dashboard zu releasen, mit dem es viel einfacher sein wird, mehrere Uberspaces zu verwalten, so wie wir uns das als "best practice" vorstellt haben. (Der Plan mit dem neuen Dashboard besteht natürlich weiter, und die Arbeit daran hat auch schon begonnen.)
• Wir haben schon damit gerechnet, dass diese Entscheidung erläuterungsbedürftig werden könnte. Der Widerspruch etlicher User traf uns allerdings in größerem Umfang, mit stärkerer Enttäuschung und mit Argumenten, die wir zu bedenken hatten. Wir wollten keinen "Okay, okay, okay"-Schnellschuss machen und unsere Entscheidung einfach wieder umwerfen, aber wir haben uns mit Usern ausgetauscht und Argumente und Use Cases eingesammelt, darüber gesprochen, und am Ende haben wir beschlossen, die virtuellen DocumentRoots entgegen der ursprünglichen Planung auch auf U7 einzuführen.
• Nach wie vor raten wir deutlich davon ab, dieses Feature zum Hosting mehrerer unterschiedlicher Projekte in einem Account zu verwenden, weil zwischen jenen Projekten dann keine Rechtetrennung besteht. Wenn Rechtetrennung wichtig ist - und das ist sie im Zweifelsfall fast immer - solltest du wie bisher dem Rat folgen, mehrere Uberspaces anzulegen. Wir werden das vereinfachen, versprochen.

Worum geht's eigentlich?

Vom Konzept her ist ein Uberspace dazu gedacht, ein Projekt darauf zu hosten. Dafür wird /var/www/virtual/<user>/html als DocumentRoot angeboten. Schon ziemlich in der Anfangszeit trafen Fragen bei uns ein, ob man da nicht die Möglichkeit schaffen könnten, für kleinere Sachen einfach separate Verzeichnisse anzulegen, um keinen separaten Uberspace dafür anzulegen - "das lohnt doch gar nicht". Wir waren mit Uberspace gerade erst gestartet, voller Tatendrang, ein wenig blauäugig vielleicht auch, und dachten uns: Klar, basteln wir doch schnell eine RewriteRule, und schon war das Feature geboren: User konnten ab sofort in /var/www/virtual/<user> einfach weitere Verzeichnisse ablegen, die so hießen wie Hostnamen, und schon wurden Anfragen nach jenen Hostnamen aus diesem Verzeichnis bedient (vorausgesetzt, der Hostname wurde auf den Uberspace aufgeschaltet). So weit, so gut - oder besser gesagt: So weit, so okay.

Probleme, Probleme

Im Support schlagen - bis heute - immer wieder die gleichen Probleme auf:

• Wer innerhalb eines virtuellen DocumentRoots mit RewriteRules arbeiten möchte, benötigt RewriteBase / - das ist einfach so, und wir haben keinen Weg gefunden, das zu vermeiden. Wir weisen bereits deutlich in der Dokumentation darauf hin und vermeiden damit sicherlich eine Reihe von Anfragen, aber aus bleiben sie dennoch nicht.
• Die Umgebungsvariable DOCUMENT_ROOT, die der Apache-Webserver für Applikationen bereitstellt, beinhaltet prinzipiell den echten DocumentRoot, also den Pfad des html-Verzeichnisses, nicht den virtuellen DocumentRoot. Häufig ist das irrelevant; wenn allerdings User oder Applikationen diese Variablen aus Ausgangswert für irgendwelche selbst-konstruierten Pfade verwenden, fällt einem das auf die Füße.
• User haben des Öfteren solche virtuellen DocumentRoots angelegt und sich dann - bis hin zu einer Supportanfrage - gewundert, warum sie nicht funktionieren, obwohl sie einfach nur vergessen haben, jenen Hostnamen auch in die Konfiguration des Webservers eintragen zu lassen. Umgekehrt haben manche verzweifelt Dateien in ihrem html-Verzeichnis geändert und sich gewundert, warum sich die Änderungen nicht im Web widerspiegelten, bis wir sie darauf hingewiesen haben, dass sie für den verwendeten Hostnamen offenbar früher mal irgendwann einen virtuellen DocumentRoot angelegt hatten und dann vergessen hatten, dass er da ist.

Das alles sind natürlich vergleichsweise leicht erklär- und lösbare Schwierigkeiten - Schwierigkeiten, die mit dem echten DocumentRoot html aber eben nicht auftreten.

Tragisch wird es aber dann, wenn es um Einbrüche mittels Lücken in von Usern installierter Software geht. Lückenhafte WordPress-Themes oder veraltete Joomla- und Drupal-Installationen bilden da in der Praxis so das Grusel-Trio. Und hier ist dann das Problem: Derartige Einbrüche streuen typischerweise Backdoors überall hin, wo der Angreifer Schreibrechte hat. Und das heißt beim Einsatz von virtuellen DocumentRoots: Wenn ich da ein halbes Dutzend Dinge in einen Account stopfe (ein CMS, ein Blog, einen Merch-Shop, einen persönlichen RSS-Reader, ein Ticketsystem und noch eine Applikation, die ich irgendwann mal ausprobiert und dann vergessen habe), dann sind eben alle diese Applikationen den Sicherheitslücken aller dieser Applikationen ausgesetzt - eine einzelne Lücke reicht aus, und schon sind Backdoors auch in den Verzeichnissen von Applikationen installiert, die gar keine bekannten Lücken beinhalten.

Natürlich können wir dann sagen: Naja, darauf haben wir dich doch deutlich hingewiesen. Aber es ist ja nicht sonderlich zielführend, einem User, dem wir gerade schon die Gesamtheit seiner DocumentRoots wegen eines Einbruchs sperren mussten, noch ein "selber schuld" an den Kopf zu knallen, egal wie freundlich und konstruktiv man das formuliert.

Außerdem versuchen wir, in die nicht ganz so nahe Zukunft zu blicken, denn nachdem sich herauskristallisiert hat, dass Uberspace wohl keine Eintagsfliege wird, sondern sich sogar ziemlich gut und zu unserem Haupt-Umsatzträger entwickelt, haben wir natürlich auch gewisse Ideen und Pläne, wo wir gerne hin wollen. Das heißt auch, dass wir zwischen maximaler Flexibilität und guter Usability gelegentlich auch mal einen Tradeoff machen müssen und - da machen wir uns nichts vor - nicht mit jeder Entscheidung alle User immer glücklich machen können, auch wenn wir natürlich darum bemüht sind, das möglichst gut hinzukriegen. Das fordert aber eben auch Nachdenken und Zeit. Bei U5/U6 haben wir viele Dinge mehr oder weniger auf Zuruf realisiert - teils mit positiven Effekten; teils auch mit Folgen, wo wir uns im Nachhinein gewünscht hätten, vielleicht lieber vorher etwas mehr nachgedacht zu haben, weil wir uns in Situationen gebracht haben, die später nicht mehr zu revidieren waren. Dass wir U7 von Grund auf neu bauen, beinhaltet auch, dass wir jedes einzelne Feature nochmal ans Reißbrett bringen und uns fragen, wie sich das auswirken kann - vom nackten Feature abgesehen also auch zu fragen: Was für Support wird das generieren, und wieviel? Wie stabil wird das sein? Welche Fehler in der Handhabung oder im Betrieb können wir antizipieren? Sehen wir möglicherweise Kompatibilitätsprobleme mit anderen Komponenten von U7? Da kann man hier und da sehr wohl zu dem Schluss kommen, dass man etwas schon bei U5/U6 praktisch optimal gebaut hat; manches hingegen wird ganz anders als früher gebaut, selbst wenn es sich aus Usersicht sogar ähnlich oder identisch benutzen lässt.

Zu jenen Abwägungen zwischen Flexibilität und Usability gehört beispielsweise die bisher nur ganz lose Idee, sich vielleicht später einmal mit Ansible-Playbooks zu beschäftigen, die beliebte Applikationen auf einem Uberspace installieren. Ihr wisst schon: So ein Pendant zu One-Click-Installern, aber eben in nachvollziehbar, weil man ja in die zugrundeliegenden Playbooks eben reinschauen kann, um zu sehen, was konkret da passieren wird, und die man ggf. auch forken und abwandeln kann, wenn man nicht einverstanden ist - und das eben auf der Basis eines verbreiteten Open-Source-Tools und nicht auf einer selbst gebauten proprietären Lösung. Dafür ist aber eben stärker als bisher Voraussetzung, dass ein definierter Zustand vorgefunden wird, und dafür erschien uns sinnvoll, festzulegen, dass solche Playbooks ihre Dinge eben immer in den einen, offiziellen DocumentRoot installieren sollten und alles andere die Dinge arg verkomplizieren würde.

Also war die - aus unserer Sicht - naheliegende Idee geboren: Wir lassen das mit den virtuellen DocumentRoots fortan einfach bleiben. Statt zu empfehlen, separate Uberspaces anzulegen, forcieren wir künftig, dies zu tun. Das erspart uns nebenbei den oben genannten Support - was natürlich zwei Aspekte hat: Einerseits ist es natürlich ohne Frage gut für uns, wenn der Support entlastet wird, damit er mehr Zeit für andere Fragen hat; andererseits ist es für die User Experience natürlich auch besser, wenn ein User gar nicht erst über ein Problem fällt, statt erst darüber zu fallen und dann erstmal Hilfe suchen zu müssen. Den Plan, das Anlegen mehrerer Uberspaces über ein neues Dashboard signifikant zu vereinfachen, hatten wir ohnehin schon lange - und er passte gut dazu.

Vielleicht war das ein wenig ungeschickt

Nun ist es natürlich so: Das neue Dashboard gibt es noch nicht, auch wenn die Arbeit daran inzwischen begonnen wurde. Es erscheint natürlich irgendwie unklug, erst das fragliche Feature der virtuellen DocumentRoots als bei U7 abgeschafft zu erklären, und erst dann irgendwann später ein neues Dashboard vorzustellen, was dazu in der Lage ist, das zu kompensieren, aber wir hatten uns das wie folgt gedacht:

• Wir haben ja nun nicht das bestehende Feature bei U5/U6 entfernt (das stand überhaupt nie zur Debatte), sondern es lediglich bei einer künftigen Produktversion weggelassen.
• Wir sind bei U7 ohnehin schon viel, viel, viel zu lange von Release early, release often abgewichen und hatten einen dicken Knoten zu durchschlagen, was wir nicht durch Abhängigkeiten á la "Das können wir erst tun, wenn jenes Feature in jenem anderen Produktteil - dem Dashboard - fertig ist" noch weiter hinauszögern wollten.
• Es erschien uns schlüssig, zu argumentieren: Wenn du virtuelle DocumentRoots brauchst, kannst du ja einfach noch bei U6 bleiben, denn da gibt es sie ja. U7 ist erst eine Beta, und wir werden zwar nicht dort das Feature einbauen, aber parallel dazu im Dashboard entwickeln, so dass du ihm, sobald du dort eine viel einfachere Verwaltung mehrerer Uberspaces hast, gar nicht nachzutrauern brauchst.

Also haben wir's gemacht, wie wir es eben gemacht haben, und das war... vielleicht ein wenig ungeschickt.

Argumente, Argumente

Uns war wichtig, dass wir jetzt nicht einfach so sagen: Ohje, die User sind unzufrieden, also bringen wir's hektisch wieder. Wir hatten uns ja immerhin etwas dabei gedacht, das Feature nicht mit aufzunehmen - aber der Druck war schon spürbar. Also hat Matthias sich drangesetzt und hat die Punkte, die User so vorgebracht haben, gesammelt und strukturiert:

• Es könnte sein, dass mehrere Projekte in einem Uberspace auf denselben Datenbestand zugreifen - beispielsweise ein Staging-System.
• Nur, weil wir keine virtuellen DocumentRoots mehr anbieten, verhindern wir ja nicht, dass User sich nicht dennoch einen Haufen Applikationen in einen einzigen Uberspace packen, also eben CMS, Blog, Shop, ... nur dann eben nicht in Form von Subdomains, sondern das müsste dann in Unterverzeichnissen laufen. Den gewünschten forcierten Sicherheitsgewinn hätten wir damit dann nicht erzielt.
• Gleiches gilt z.B. für die Installation mehrerer Dienste auf mehreren Ports, kombiniert mit einer .htaccess-Datei mit RewriteRules, die Requests anhand unterschiedlicher %{HTTP_HOST}-Werte an unterschiedliche Ports schicken.
• Derzeit ist eben die Verwaltung mehrerer Uberspaces noch nicht wirklich gegeben, außer rudimentär via OpenID. Ein neues Dashboard wird das lösen.
• Insbesondere für ein gemeinsames Aufladen gibt es noch keine wirklich runde Lösung. Das wird sich ändern, insofern ist das perspektivisch eher kein Problem mehr, aber im Moment eben schon noch.
• Einige User empfinden es als Einschränkung, dann nicht mehr "mal eben schnell" etwas testen zu können. Unser Argument wäre hier, dass gerade zum Testen ein ganz neu angelegter Uberspace, der anschließend entsorgt werden kann, doch eigentlich die besonders gute Lösung wäre, vor allem, weil man damit dann keine Produktivdaten einem Risiko aussetzt; allerdings wenden User auch ein, dass solche Tests auch mal länger als den kostenlosen Testmonat dauern können und nicht automatisch weggeräumt werden sollen (wogegen wir wiederum einwenden können, dass es riskant ist, Tests lange liegenzulassen - im Zweifelsfall wird einem dann ein Jahr später über eine zwischenzeitlich entdeckte Sicherheitslücke in der testweise installierten Applikation dann der Account aufgemacht; leider auch eine Praxis-Erfahrung). Aber diese Argumente kann man trefflich Ping-Pong spielen lassen.
• User verwenden virtuelle DocumentRoots zum Teil für Mikro-Projekte (nennen wir sie mal "Web-Visitenkarte"), teils mit rein statischen Inhalten, bei denen Rechtetrennung kein Thema ist, weil dort ohnehin keine dynamischen Inhalte ausgeführt werden.
• Insbesondere für solche kleinen Mikro-Projekte erscheint einigen Usern selbst der symbolische Mindestpreis von 1 Euro als zu hoch. Teils ließ sich aus Äußerungen direkt oder indirekt herauslesen, wir seien jetzt wohl "geldgeil" geworden, weil das Anlegen von 10 Uberspaces für 10 Mikro-Projekte dann eben halt auch nicht mehr für 'nen Fünfer oder gar weniger im Monat zu haben sei.
• Auch ein Datenschutz-Aspekt wurde genannt, den wir so tatsächlich gar nicht auf dem Schirm hatten: Wenn unter <user>.uber.space und unter domain.tld forciert die gleichen Inhalte abrufbar sind, kann man regelmäßig aus einem Usernamen auf einen Domainnamen schließen. (Wobei sich das immer noch via .htaccess hätte verhindern lassen, aber wir haben gelernt, dass es User gibt, die für den internen Hostnamen einfach einen separaten, leeren DocumentRoot angelegt haben und jenen somit abgeklemmt haben.)
• Etwas weg vom technischen Bereich gingen dann Äußerungen, dass sich User die Meinung, wie denn mit mehreren Projekten umgegangen werden möge, nicht von uns "vorkauen" lassen möchten. Teils fiel auch der Begriff "Elfenbeinturm".

Zurück ans Reißbrett

Unsere teaminternen Gespräche dazu waren hart, und wir können offen zugeben, dass mehrere von uns im Verlauf dieser Gespräche ihre Meinung geändert haben; in unterschiedliche Richtungen; teils sogar mehr als einmal. Worin wir uns aber sehr schnell einig waren: Wenn User beginnen, den Eindruck zu äußern, wir säßen in einem Elfenbeinturm, dann machen wir etwas nicht richtig, oder zumindest kommunizieren wir etwas nicht richtig. Sehr wahrscheinlich aber auch schlicht und einfach gleich beides.

Wir können ohne Umschweife zugeben: Wir finden nicht alles super, was User bei uns so machen bzw. wie sie es machen - also, aus technischer Sicht. So, jetzt ist es raus. Steinigt uns. (Bitte nicht.)

Allerdings ist Uberspace seit Tag 1 ein Produkt, bei dem wir ein großes Augenmerk darauf gelegt haben, möglichst viel von der Freiheit, die Linux und die Shell so bieten, an User weiterzugeben. Und das hat selbstverständlich zur Folge, dass unterschiedliche User unterschiedliche Problemstellungen auch unterschiedlich angehen und es nicht an uns ist, da zwischen "falsch" und "richtig" zu urteilen. Die - ganz prinzipielle - Herausforderung ist: Wie kriegen wir ein Produkt hin, das für User einfach zu benutzen ist und ihnen aber dennoch möglichst viele Freiheiten lässt?

U5/U6 sind davon charakterisiert, dass wir in erster Linie viele Freiheiten gelassen haben. Das ist allerdings teils mit Ecken und Kanten verbunden, wo wir heute sagen würden: Ohjeohje, da müssen wir aus Usability-Sicht aber nochmal ran, das können wir so nicht shippen. Denn nur weil wir zu einem nicht gerade kleinen Teil Nerd-User haben, die schon lange auf einer Shell Zuhause sind, heißt das ja nicht, dass wir uns nicht darum bemühen sollten, Dinge flexibel, aber eben auch einfach zu machen. Ein Uberspace soll aus unserer Sicht einfach ein gutes Produkt sein und kein Statussymbol á la "Darauf können sich die Leute, die das bedienen können, etwas einbilden". Deshalb sind wir bestrebt, den Spagat zu schaffen, etwas zu bauen, was für alle leichter zu benutzen ist, aber denen, die tiefer graben wollen, keine Steine in den Weg legt.

Jeder der einen Spagat hinlegen kann, weiss, dass diesem ein langer Lernprozess vorausgeht. Und wir haben daraus gelernt. Für diese Erfahrung - die wir auch bei künftigen Designentscheidungen stets im Kopf behalten werden - können wir jedem Einzelnen, der uns Contra gegeben hat, nur danken.

Sagt Hallo zu biela, brorsen, encke, faye, finlay, halley, olbers, tempel, tuttle und wolf! Wir haben mehrere Terabyte Plattenplatz, mehrere Dutzend CPU-Kerne und mehrere hundert GB RAM springen lassen und zehn Hosting-Systeme für euch gebaut, damit nach den 50 Usern, die unsere Closed Beta testen konnten, nun alle anderen, die schon auf U7 neugierig sind, ebenfalls loslegen können.

Welche Features machen die Beta schon heute besser als U6?

• vollautomatisches HTTPS-Handling mit Let's Encrypt für alle Domains
• HTTP wird grundsätzlich auf HTTPS umgeleitet
• Diverse Security-Header werden als Default gesetzt
• wir unterstützen nun HTTP/2
• OCSP Stapling
• PHP ohne Startverzögerungen (eigene PHP-FPM-Instanz pro User)
• user.uber.space & user@uber.space
• MariaDB 10.1 ohne Klimmzüge
• insgesamt deutlich frischere Toolchain an Kommandozeilentools
• Webserver-Logging ist nun standardmäßig komplett aus (Datensparsamkeit FTW!), kann aber auf Wunsch eingeschaltet werden und liefert dann Logs mit gekürzten IP-Adressen
• komplett neues Handbuch auf manual.uberspace.de - aus einem Guss, auf Englisch, mobiltauglich und mit ChangeLog
• supervisord als leistungsstärkerer daemontools-Nachfolger zum Verwalten eigener Daemons

Was ist sonst noch fertig?

• Python 2.7, 3.4, 3.5, 3.6
• PHP 5.6, 7.0, 7.1, 7.2
• Perl 5.16.3
• Lua 5.1
• GCC 4.8 (C/C++)
• Cronjobs
• Subversion
• SQLite 3
• node.js 6, 8, 9
• virtuelle Mailuser (vmailmgr)
• maildrop
• ruby
• Adminer und phpMyAdmin
• Webmail
• Rspamd als Ersatz für SpamAssassin und DSPAM

Was kann die Beta noch nicht?

• Programmiersprachen: Ruby, Erlang und node.js
• Datenbanken: PostgreSQL, CouchDB und MongoDB
• virtuelle Mailuser (vmailmgr)
• Backups im direkten Userzugriff (wir machen durchaus Backups, aber der Zugriff ohne Support-Eingriff darauf fehlt noch)
• Adminer und phpMyAdmin
• Handbuch auf Deutsch
• ezmlm-idx
• maildrop
• gitolite 3
• Ports öffnen
• 2-Faktor-Authentifizierung für SSH
• Redis
• SpamAssassin
• Webmail

Welche Features werden wir auch nicht mehr einbauen?

• gitolite 2 (ersetzt durch gitolite 3)
• DSPAM (unmaintained)
• daemontools (unmaintained, ersetzt durch supervisord)
• toast (unmaintained)
• CVS (unmaintained)
• Namensräume für Mail-Domains (hohe Komplexität und ein Support-Albtraum; nutze lieber separate Uberspaces dafür)
• Hostnamens-Verzeichnisse in /var/www/virtual/USER (hoher Supportaufwand, da technisch nicht 100% kompatibel zu echten DocumentRoots; motiviert zum Hosting unterschiedlichster Applikation im gleichen Account und vereinigt die Sicherheitsrisiken aller jener Applikationen; nutze lieber separate Uberspaces dafür)

Wie komme ich an einen U7-Beta-Account?

Auf https://uberspace.de/register?u7=1 bekommst du eine Checkbox angeboten, mit der einen Account auf U7 statt auf der derzeit stabilen Version U6 anlegen kannst.

Kann ich meinen bestehenden Uberspace auf U7 upgraden?

Nein - U7 ist ein neues Produkt. Wir haben es auf Basis von CentOS 7 gebaut (daher die Versionsnummer); die aktuelle stabile Version basiert noch auf CentOS 6. Insbesondere alle selbst kompilierten Dinge würden insofern schon aufgrund sehr abweichender Library-Versionen an dieser Stelle brechen. Wir haben auch an diversen Stellen inkompatible Änderungen vorgenommen und einige alte Zöpfe abgeschnitten. Keine Sorge: Wir werden U6 bis zum Ende der Supportzeit der Distribution (im Jahr 2020) weiterhin pflegen; es gibt also keinerlei Anlass, jetzt panisch unter Druck Dinge migrieren zu müssen. Aber was du schon seit mehreren Jahren auf U6 (oder gar noch auf U5) hostest, möchte mit hoher Wahrscheinlichkeit ohnehin einmal liebevoll von dir umsorgt werden - du verbringst ja vermutlich auch nicht dein ganzes Leben in der gleichen Wohnung, und ein Umzug ist eine gute Gelegenheit, schöne Dinge mitzunehmen, in die Jahre gekommene Dinge dabei vielleicht einmal neu anzumalen, und im besten Fall auch mal ein wenig zu entrümpeln und sich von Dingen zu trennen. Trau dich!

Warum machen wir die Beta jetzt öffentlich?

Well... Fuck it, ship it.

Wir haben sehr lange daran gearbeitet, U7 zu konzipieren und "ganz nebenbei" unsere Arbeitsweise und auch unsere Tools neu zu erfinden. Das Produkt ist natürlich nicht fertig (deshalb heißt es ja auch "Beta"), aber es kann auf jeden Fall so viel, dass unsere Beta-User schon jede Menge Dinge erfolgreich darauf ausprobieren konnten. Wir hätten es vielleicht schon früher tun können; wir könnten genauso gut auch Argumente finden, warum wir es erst später tun möchten. Wir haben uns nun aber im Development auf ein - wie wir finden - ziemlich rundes Bündel an Features geeinigt, das von einer vergleichsweise großen Gruppe von Usern als "für ihre Zwecke ausreichend fertig" betrachtet werden kann. Deshalb... releasen wir die Beta jetzt einfach mal, auch wenn noch Dinge fehlen.

Heißt "Beta", dass das System irgendwie instabil ist, noch nicht die volle Performance hat oder nochmal plattgemacht wird?

Beta heißt nur, dass das Produkt noch nicht alle Features hat, die wir dafür so auf dem Schirm haben. Das, was da ist, ist stabil, durchläuft beim Deployment umfangreiche Tests und unterliegt im Produktivbetrieb dem üblichen Monitoring. Die Hosts laufen produktiv auf vollwertiger, extra dafür angeschaffter Hardware mit dem üblichen Redundanzlevel - und wir haben mit mehr RAM- und CPU-Ressourcen pro User kalkuliert als bisher. Wir werden zu einem späteren Zeitpunkt, wenn wir die Zeit für gekommen halten, einfach das Beta-Label abkratzen. Alle Accounts bleiben dann so wie sie sind erhalten und laufen einfach weiter.

Aber auch, wenn die Beta bereits durch 50 User der Closed Beta mit interessanten Edge Cases malträtiert wurde und wir dabei viele Kinderkrankheiten behoben haben: Wir machen uns und auch euch nichts vor - U7 ist ein von Grund auf neu entwickeltes Ding, das trotz vieler Tests vielleicht noch die eine oder andere Kante mitbringen könnte, die bisher weder wir noch unsere Tester gefunden haben. Bitte seid nachsichtig und sagt uns einfach Bescheid - wir gehen jedem Problem nach.

Kann ich meinen Usernamen behalten?

Usernamen sind bei uns prinzipiell global eindeutig; es kann also nur genau einen Account unter einem Usernamen geben. Das ist nicht zuletzt wichtig, um Aufladungen - die den Usernamen im Verwendungszweck tragen - klar einem Account zuzuordnen.

Wir überlegen (bzw. haben halbfertigen Code dafür), im Dashboard eine Option einzubauen, um übergangsweise einen zweiten Uberspace auf U7 anlegen zu können, wobei das klare Ziel ist, nach einiger Zeit den alten Account (bzw. den neuen, wenn du nicht zufrieden mit U7 bist und lieber noch auf U6 bleiben willst) zu löschen. Diese Funktionalität liefern wir aber noch nicht direkt jetzt.

Werden Beta-Accounts berechnet?

Ja. Sie unterliegen aber natürlich wie jeder andere Uberspace auch einem kostenlosen Testmonat. Wenn das bestehende Featureset dir bereits ausreicht, kannst du deinen Beta-Account ja auch schon produktiv nutzen; wir haben hier bereits fünfstellige Beträge in neue Hardware investiert, um die Beta-Hosts mit Systemressourcen auszustatten, und wir haben mehrere tausend Arbeitsstunden in die Entwicklung der nächsten Generation unserer Hosting-Plattform gesteckt, die auch als Beta schon viel leistet. Wenn du mit dem Featureset noch nicht ausreichend bedient bist, gehst du kein Risiko ein: Lösche den Uberspace wieder bzw. lasse ihn durch Nicht-Aufladung auslaufen. Verfolge gerne die weitere Entwicklung und lasse uns wissen, was dir noch fehlt, denn wenn wir dich heute noch nicht mit U7 kriegen können, dann wollen wir es morgen!

Standard WordPress-Installationen der Version 4.7.4 sind im Moment für die Lücke CVE-2017-8295 anfällig. Mithilfe dieser Lücke kann ein Angreifer Password-Reset-Mails an beliebige Mailserver umleiten und so an den kritischen Link gelangen. Seitens WordPress gibt es hierfür noch keinen Fix.

Das funktioniert, da WordPress den Host-Header 1:1 für diverse Mail-Header in der ausgehenden Mail benutzt. Wie das genau funktioniert könnt ihr in der Exploit-DB nachlesen.
Ein Angriff würde also beispielsweise so aussehen:

POST /wp/wordpress/wp-login.php?action=lostpassword HTTP/1.1
Host: injected-attackers-mxserver.com   <== oh noes! D:
Content-Type: application/x-www-form-urlencoded
Content-Length: 56
 
user_login=admin&redirect_to=&wp-submit=Get+New+Password

In unserem Setup werden Requests anhand ihrer Host-Header an die jeweiligen Uberspaces und damit an die WordPress-Instanzen verteilt. Wenn nun eine Angreiferin den Header modifiziert, landet der Request gar nicht erst bei der angegriffenen WordPress-Instanz, sondern auf unserer "Diese Domain kennen wir leider nicht"-Seite. Ein WordPress, das bei uns gehostet ist, ist für diese Lücke also nicht anfällig.

Kurz um: alles gut. weitermachen.

Heute morgen gegen halb acht begann dietrich, einer unserer KVM-Wirte, folgende Meldungen nach /var/log/messages zu spucken:

Mar  2 07:28:22 dietrich kernel: mce: [Hardware Error]: Machine check events logged
Mar  2 07:28:23 dietrich kernel: EDAC MC1: 1 CE memory read error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x186f358 offset:0x500 grain:32 syndrome:0x0 -  area:DRAM err_code: 0001:0090 socket:1 ha:0 channel_mask:1 rank:1)
Mar  2 07:29:35 dietrich kernel: mce: [Hardware Error]: Machine check events logged
Mar  2 07:29:35 dietrich kernel: EDAC MC1: 1 CE memory read error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x186f358 offset:0x500 grain:32 syndrome:0x0 -  area:DRAM err_code: 0001:0090 socket:1 ha:0 channel_mask:1 rank:1)
Mar  2 07:30:45 dietrich kernel: EDAC MC1: 1 CE memory read error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x186f358 offset:0x500 grain:32 syndrome:0x0 -  area:DRAM err_code:0001:0090 socket:1 ha:0 channel_mask:1 rank:1)
Mar  2 07:31:25 dietrich kernel: mce: [Hardware Error]: Machine check events logged
Mar  2 07:31:26 dietrich kernel: EDAC MC1: 1 CE memory read error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x186f358 offset:0x500 grain:32 syndrome:0x0 -  area:DRAM err_code:0001:0090 socket:1 ha:0 channel_mask:1 rank:1)
Mar  2 07:31:32 dietrich kernel: EDAC MC1: 1 CE memory read error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x186f358 offset:0x500 grain:32 syndrome:0x0 -  area:DRAM err_code:0001:0090 socket:1 ha:0 channel_mask:1 rank:1)

Was schon nicht ganz so schön aussah, mündete dann kurz darauf in ein komplettes Einfrieren der Maschine, und damit auch der vier darauf laufenden Gäste aries, columba, octans und sagitta.

Ein erster Reboot-Versuch über das IPMI-Modul von dietrich verlief wenig zufriedenstellend - nachdem das Gerät einmal vom Strom getrennt und wieder verbunden war und erste Bootmeldungen der Hardware zu sehen waren, fror es wieder ein. Erst nach einem weiteren Trennen und wieder Verbinden des Stroms bootete es komplett hoch. Wir haben aufgrund der RAM-Meldungen aber darauf verzichtet, die vier Gäste direkt auf dietrich wieder zu booten, um zu vermeiden, dass hier ein erneut auftretendes Problem sie direkt noch einmal abstürzen lässt.

Stattdessen haben wir die vier Gäste auf Replikationspartnern gebootet, die jeweils den kompletten Datenbestand vorhielten. Wir haben dabei in der Kette der KVM-Wirte einige weitere, nicht ausgefallene Gäste auf andere Wirte migriert, um die zusätzliche Belastung durch die temporär durch den dietrich-Ausfall mitzutragenden Systeme so gering wie möglich zu halten. Dadurch stemmen jetzt die in der KVM-Kette neben dietrich liegenden Systeme vorübergehend 5 statt wie sonst 3-4 Gastsysteme. Alle Wirte sind generell mit ausreichend RAM bestückt, um im Zweifelsfall noch zwei Gastsysteme mehr als üblich aufnehmen zu können; damit konnten wir hier entsprechend handeln.

dietrich läuft nun aktuell wieder, aber nur als Replikationspartner für die nebenliegenden KVM-Wirte. Gastsysteme beherbergt er nun aktuell nicht; so haben wir die Möglichkeit, den RAM-Vorfall zu prüfen, Speicherriegel zu testen und ggf. durch Ersatz auszutauschen.

Der erste Host - octans - war seit 8:01 Uhr wieder erreichbar; der letzte Host - columba - seit 8:41 Uhr. Ein ungeplanter Crash durch einen Hardwaredefekt zieht in der Regel einen Filesystem-Check (fsck) und einen Quota-Check nach sich, was den Bootvorgang gegenüber einem geplanten, sauberen Reboot verlängert; auch führt MySQL nach einem Crash einen Recovery-Vorgang durch, was dazu führt, dass MySQL noch einige Minuten länger nicht erreichbar ist, während alles andere schon wieder läuft. Inzwischen sind aber alle Recovery-Prozesse durch und im Monitoring alle Checks wieder grün. Solltet ihr noch Probleme beobachten, meldet euch bitte bei hallo@uberspace.de.

Was lernen wir als kleine Kinder von unseren Eltern? Immer in beide Richtungen schauen bevor die Straße überquert wird. -- Nur was ist mit Einbahnstraßen? Ist es schlau sich den unnötigen Blick in die verbotene Gegenrichtung zu sparen, oder ist es schlau das Unerwartete zu erwarten und trotzdem in beide Richtungen zu schauen?

Wenn es um Computer geht ist es meist am besten, auch mit dem Unerwarteten zu rechnen, das ist zum Beispiel eine wichtige Lektion wenn es um IT-Security geht, aber auch beim Debugging kann das viel Kopfzerbrechen sparen (aber leider meist keine Zeit). Aber auch in der Kommunikation mit Menschen kann das eine wichtige Lektion sein, sonst passieren manchmal nicht nur Dinge die gewollt waren, sondern auch Dinge die nicht gewollt waren. Besonders gefährlich ist, wenn Dinge als implizit gegeben angenommen werden und nicht explizit gesagt werden.

Soetwas ist uns heute mit dem DNS an einem unserer drei Rechenzentrums-Standorte passiert. Dort wird der Traffic zum Schutz gegen DDoS-Attacken derzeit teilweise gefiltert, spezifisch wird DNS-Traffic aktuell komplett blockiert, außer zu einer kleinen Liste von ausgewählten externen Resolvern. Alle Server in diesem Rechenzentrum müssen diese Resolver benutzen, sie können weder selbst Namen im DNS auflösen noch externe Resolver darum bitten, beides verhindert der Filter. (Plot-Twist: Wegen dieses Filters funktionierte auch unser Monitoring für "funktioniert DNS-Auflösung in diesem Rechenzentrum?" seit einer Weile nicht mehr und war daher stumm geschaltet. Das ist nebenher einer der Gründe warum wir das Setup ändern wollten. Dazu weiter unten mehr.)

Nun wollen wir auf neue, interne Resolver umstellen, unter anderem damit wir selbst Caching betreiben können, aber auch damit wir z.B. DNSSEC zuverlässig nutzen können und einen besseren Blick darauf haben, was auf den Resolvern vor sich geht. Also schrieben wir die freundlichen Leute vom RZ-Betreiber an, gaben ihnen die Liste der IP-Adressen unserer neuen Resolver und baten darum, die für DNS-Traffic komplett frei zu schalten, damit wir die benutzen können.

Und schon war's passiert.

Was wir meinten war: Die Filter-Regeln sollen ergänzt werden, nämlich um eine Regel die unsere neuen Resolver benutzbar macht. (Damit wir dann im nächsten Schritt anfangen können auf diese Resolver umzustellen. Danach könnte dann die alte Filter-Regel weiter angepasst werden, sie kann aber auch einfach bestehen bleiben.)

Was beim Rechenzentrums-Betreiber ankam war: Alte Filterregel durch neue ersetzen.

Und schwups ging mit einem Mal ab 14:10 das DNS nicht mehr, außer auf drei neuen Resolvern, die aber noch keiner unserer Server benutzte. So schnell geht's manchmal. Ärgerlich, aber wenigstens war es aus technischer Sicht schnell zu beheben. Doppelt ärgerlich, weil unser Monitoring nicht sofort Alarm schlagen konnte (schönen Gruß von weiter oben), deswegen dauerte es über eine halbe Stunde bis es deutlich auffiel und wir mit der Fehlersuche und Behebung beginnen konnten. Besonders ärgerlich, weil diese Art Missverständnis eigentlich nichts Neues ist und wir auf solche Details achten, in diesem Fall aber echt kalt erwischt wurden. So oder so: Ab 15:15 ging alles wieder.

Das hätte nun durch deutlichere Kommunikation (weniger implizite Annahmen, mehr explizite Ansagen meinerseits, oder auf der Gegenseite mehr explizitie Rückfragen) verhindert werden können. Es hätte auch technisch verhindert werden können, wenn die neuen Resolver erstmal im Forwarding-Modus konfiguriert und alle Server im Rechenzentrum schon im Vorfeld auf die neuen Resolver umgestellt worden wären. In dem Fall hätten die neuen Resolver zunächst die alten Resolver benutzt und die Anfragen erstmal nur durchgereicht. Nach der Filter-Umstellung hätte dann auf den neuen Resolvern das Forwarding nach und nach abgestellt werden können. Aber dazu hätte eben das Unerwartete erwartet werden müssen. Hier beißt sich dann die Katze der Vorsicht in den Schwanz: Erstmal in Ruhe die neuen Resolver testen, oder um einem möglichen Missverständnis bei der Umstellung vorzugreifen schon vorher alles auf die neuen Resolver umstellen?

Es sollte eben immer erst in beide Richtungen geschaut werden. Das Problem bei Computern ist, dass es mehr als zwei Richtungen gibt und oft unklar ist wie viele es eigentlich sind.