Die Sache mit den ETAs

Eines unserer Grundprinzipien ist: Wir geben keine ETAs. Features kommen, wenn sie fertig sind und nicht zu versprochenen Zeitpunkten. Wir sind der Meinung, dass es nicht gut sein kann, unter Zeitdruck an etwas zu arbeiten und sind fertig, wenn wir eben der Meinung sind, dass wir fertig sind; wenn wir soweit hinter unserer Arbeit stehen, dass wir sie vertreten können und gut finden. Wir haben kein Venture Capital und keine Abteilung im Rücken, die darauf pocht, neue Features schnellstmöglich und unpoliert auf den Markt zu werfen und profitabel zu machen. Daher nehmen wir uns die Zeit, die wir eben brauchen und finden diese Herangehensweise richtig und wichtig. Allerdings haben wir bei einer Sache mit diesem Grundprinzip gebrochen und das ist Uberspace 7. Unser erster ETA war Ende 2015, dann war es Anfang 2016. Jetzt haben wir daraus gelernt und wollen euch in einer Reihe von Blogeinträgen ein wenig an unserem Lernprozess teilhaben lassen und erklären, warum das alles (gefühlt) so schrecklich lange dauert. Aber erst mal ein Schritt zurück: Uberspace 7?

Auf dem 32c3 haben wir erstmals unsere Uberspace-Sticker verteilt. Die Nachfrage dort war so groß, dass sie uns nach 2 Tage schon wieder ausgegangen sind. Nach dem Event hat sich die Tatsache, dass es jetzt Sticker von uns gibt, relativ schnell rumgesprochen, sodass wir einen Haufen Anfragen dazu bekamen. Letzten Endes haben wir “klein beigegeben”, das ganze offiziell gemacht und aufgrund der Anzahl der Anfragen eine eigene Queue in unserem Ticketsystem eingerichtet.

Eines der (wenigen) Dinge, die ich von meinem Studium mitgenommen habe ist: Was mehr als zwei mal getan werden muss, sollte automatisiert werden. Und damit geht es wohl in keiner Branche so sehr darum, sich selbst abzuschaffen, wie in unserer. Nach dem automatisiertem Zertifikatsimport haben wir uns natürlich nicht zurück gelehnt und die Füße baumeln lassen, sondern die durch die weggefallenen Supportanfragen gewonnene Zeit genutzt, um munter weiter in die Tasten zu hauen. Et voilà: Jetzt ist es soweit. Es hat sich ein bisschen etwas getan hinter den Kulissen:

Wir werden in den nächsten Tagen ein Update von OpenSSH auf Port 22 auf Version 7.1 vornehmen. In den aktuellen Versionen von OpenSSH ist DSA standardmäßig deaktiviert und wir werden diese Konfiguration übernehmen, da DSA schon lange als unsicher gilt und uns daher ein Dorn im Auge ist. Solltest du also (immer noch) DSA-Schlüssel für den SSH-Login verwenden, ist es jetzt an der Zeit, diese schnellstmöglich austauschen. Im Wiki beschreiben wir, wie du dir einen RSA-Schlüssel mit 4096 Bit generieren kannst.

Wir bei Uberspace haben - wie ihr vielleicht wisst - kein festes gemeinsames Büro (Die Firmenanschrift in Mainz ist lediglich Jonas’ Anschrift, bei der wir uns zwar alle ab und zu einfinden, dann aber nicht direkt bei ihm einziehen), sondern arbeiten an ganz unterschiedlichen Orten: Von Zuhause, wo das Fahrrad uns hinträgt, im Coworking Space, auf dem Sofa, im Café, im Garten, kurz gesagt: Wo wir eben wollen und wo es Internet gibt. Nachdem ich letztes Jahr bereits einen Monat mit meinem Rucksack durch Thailand geschlendert bin, habe ich dieses Jahr das Experiment gewagt, das Angenehme mit dem Nützlichen zu verbinden, aus einem Monat Aufenthalt zwei Monate zu machen und zwischendurch auch mal zu arbeiten.

Wir haben haben das erste Release von PHP 7 (also die 7.0.0) auf alle unsere Hosts verteilt. Aktiviert werden kann es wie gewohnt:

$ echo PHPVERSION=7.0 > ~/etc/phpversion
$ killall php-cgi

Wichtig: Wer sich eine eigene php.ini angelegt hat, sollte jene durch eine frisch angelegte Version auf Basis der zentralen php.ini ersetzen und ggf. vorgenommene Erweiterungen dort erneut vornehmen, ansonsten dürfte insbesondere der opcache-Support, für den ein Modul über die php.ini geladen wird, nicht funktional sein. Wer eigene PECL-Module kompiliert hat, muss jene für PHP 7 neu bauen, da sich die API-Version geändert hat (von 20131226 auf 20151012).

Achtung! Dieser Blogpost ist die Ankündigung unseres Let’s Encrypt-Supports. Leider haben sich seitdem einige Details wie z.B. der lesencrypt-renewer geändert, sodass die Informationen hier nicht mehr sonderlich aktuell sind. Stattdessen bitten wir dich, einen Blick auf den zugehörigen Wiki-Artikel zu werfen, welchen wir stets auf dem neuesten Stand halten.

Das Wichtigste in Kürze.

Let’s Encrypt?

Für alle, die in den letzten Wochen unter einem Stein gelebt haben: Let’s Encrypt ist eine Initiative, die kostenlos und automatisiert Zertifikate ausstellt, die z.B. für HTTPS nutzbar sind.

Ihr könnt (und sollt!) bei uns ja nun schon lange eigene TLS-Zertifikate für den Webserver benutzen, jedoch war das bisher immer mit einer Mail an den Support verbunden, nach der wir das Zertifikat dann einbinden. Wir haben das bisher nicht etwa so gehandhabt, weil wir zu faul waren, uns etwas anderes zu überlegen oder weil wir euch ärgern wollten, das hatte schlicht sicherheitstechnische Hintergründe: Die Zertifikate werden in unser HTTPS-Frontend Pound eingepflegt und das betrachten wir als außerordentlich kritische Infrastruktur, bei der wir so wenig Angriffsvektoren wie möglich öffnen wollen. Da es ja nun aber doch so aussieht, als ob die freie Verfügbarkeit von TLS-Zertifikaten für jeden direkt vor der Tür steht und wir dies soweit wie möglich automatisieren wollen, haben wir uns mal ein paar Gedanken gemacht, wie das mit dem Zertifikatsimport (so weit wie möglich) ohne unser Zutun ablaufen kann.