Die Verantwortung der freien Preiswahl

Der Anlass

Wir haben vor einger Zeit begonnen, User, die weit unter unserer Preisempfehlung von 5€ / Monat bezahlen, darauf hinzuweisen, dass wir uns etwas mehr wünschen. Hier ein Auszug aus der Mail:

Du hast derzeit einen Wunschpreis von 1,00 € eingestellt, der deutlich unter unserem Preisvorschlag von 5,00 € monatlich liegt. Wir möchten dich daran erinnern, dass du unseren Dienst nur zu diesem Preis in Anspruch nehmen kannst, weil andere User freiwillig einen höheren als den vorgeschlagenen Preis bezahlen und dir den Account so querfinanzieren. Wir erhoffen uns davon, dass diejenigen, die es sich leisten können, andere User, die sich das nicht leisten können, mit tragen.


Firmware-Update durchs Schlüsselloch

Gestern haben wir uns daran begeben, zwei neue Router in Betrieb zu nehmen und standen vor einer Blockade. Aus der Ferne konnten wir nur per serieller Konsole auf die Geräte zugreifen, weil der der Netzwerkanschluss noch nicht funktionierte.

HTTPS-Ausfall von 4 Hosts am 6.6.2018

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.


Über Auftragsverarbeitung

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.


DSGVO, wir kommen!

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.


⚛️ Uberlab

Kann man bei euch eigentlich…

Ein Klassiker im Support ist die Frage, ob und wie man bei uns Dinge wie Wordpress, Ghost, Nextcloud, (…) möglichst einfach installieren kann. Die Antwort ist meistens “klar geht das, wir haben das im Wiki verlinkt oder schau doch mal bei der Suchmaschine deiner Wahl.” Viele von euch schreiben Anleitungen für die Installation, die dann aber irgendwo veröffentlicht werden müssen. Wir haben da bisher immer darum gebeten, im Zweifelsfall selbst eben einen Blog aufzusetzen oder den Artikel als Gastbeitrag in einem anderen Blog zu veröffentlichen. Das hat natürlich Grenzen und nicht jeder hat Lust und Zeit dazu, für eine einzelne Anleitung gleich einen eigenen Blog aufzusetzen. Das ist mehr als verständlich und so verstaubt sicherlich die eine oder andere Anleitung unveröffentlicht auf lokalen FestplattenSSDs. Das muss doch irgendwie anders gehen…


Reboot tut (nicht immer) gut

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.


Let's Encrypt: TLS-SNI und Shared Hosting

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.


Meltdown & Spectre - Bugs in Intel-CPUs

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.


Die Sache mit den virtuellen DocumentRoots

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.