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?

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.

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.

nodejs-5 -> nodejs-5.1.0

nodejs-4 -> nodejs-4.2.2

Das Spiel kennt ihr: Wenn ihr nodejs-4 oder nodejs-5 in eueren Scripten benutzt reicht es, den Dienst einfach neu zu starten.

Der Default bleibt bis auf weiteres node-0.10 da wohl noch einige Zeit ins Land gehen muss, bis die meisten Projekte Support für Node.js (4|5) eingebaut haben…

Wir haben auf allen Hosts Roundcube (also das Webmail-Interface auf https://webmail.$servername.uberspace.de) auf die neueste Version gehoben. Dabei haben wir einen Versionssprung von 1.0.5 auf 1.1.3 hingelegt und unser Deployment-Setup so angepasst, dass wir in Zukunft mit einem Fingerschnippen Updates einspielen können.

Außerdem haben wir etwas an der Konfiguration geschraubt. Neu hinzu gekommen sind:

// prefer displaying HTML messages
$config['prefer_html'] = false;

// display remote inline images
// 0 - Never, always ask
// 1 - Ask if sender is not in address book
// 2 - Always show inline images
$config['show_images'] = 1;

// save compose message every 60 seconds (1min)
$config['draft_autosave'] = 60;

// Add this user-agent to message headers when sending
$config['useragent'] = '';

Diese Einstellungen sind per User im Webinterface änderbar und führen zu mehr Privatsphäre und Sicherheit.

Seit jeher animieren wir unsere User mit ihren Uberspaces mehr anzustellen, als out-of-the-box möglich ist und sich selbst und uns damit zu überraschen. Dazu gehört unter anderem: Installiert euch doch an Software was ihr wollt. In den allermeisten Fällen ist es gar nicht notwendig, einen root-Account zu haben, mit ein bisschen Geduld und Spucke - und wenn der Quellcode vorliegt - kann man eigentlich alles auch im Userspace installieren. Und hier gilt: Viele Wege führen nach Rom: Man kann entweder alles per Hand frickeln oder aber - wenn’s denn etwas bequemer sein soll - per toast oder brew. Wir sind der Meinung: Macht’s euch lieber bequem 🍸.