In der Vergangenheit waren wir, was die von uns untersützten PHP-Versionen angeht, sehr liberal. So findet man bei uns, neben den aktuellen Versionen 5.6 und 7.0, sogar noch ein PHP 5.2:
[root@cygnus ~]# /package/host/localhost/php-5.2/bin/php --version
PHP 5.2.17 (cli) (built: Apr 26 2012 11:08:29)
User, die mit solch antiken Versionen bei uns im Support aufschlagen, bekommen üblicherweise einen freundlichen Hinweis auf das aktuelle Jahr. Gelöscht haben wir die alten Versionen dennoch nie. Es lag daher bisher in der Verantwortung der User die PHP-Version auf ein neueres Release umzustellen. Für alle Releases, die sich bereits im “End of Life”-Status befinden und damit keinen offiziellen Support oder Security-Fixes bekommen ist damit nun aber Schluss:
Vielleicht fragt ihr euch, wie man so ein System denn überhaupt entwirft, was die einzelnen Phasen der Entwicklung sind und wie unsere Arbeitsweise so aussieht. Mit herzlichen Grüßen aus dem Bergwerk folgt hier ein kleiner Einblick in unsere tägliche Arbeit und den aktuellen Stand der Dinge.
… und was wir anders machen würden, wenn wir nochmal von vorne anfangen würden.
Der Verwendungszweck von Überweisungen ist ein täglicher Quell der Überraschung: Entgegen unserer Bitte, einfach nur “Uberspace Username” in den Verwendungszweck zu packen, erhalten wir täglich ein Bündel Überweisungen mit so schönen Angaben wie “Für meine Internetseite”, “für 6 Monate, vielen Dank”, “Verwendungszweck” (!) oder allen möglichen Schreibweisen, die teilweise plausibel auf kreative Handschrifterkennung der Bank hinweisen. In erster Linie ist das zum Nachteil des Accountinhabers, denn während Buchungen, deren Verwendungszweck dem vorgegebenen Schema entspricht, automatisiert eingebucht werden, landet alles andere in einer manuellen Nachkontrolle, wird also ggf. erst etwas später gutgeschrieben oder landet im schlechtesten Fall in den offenen Buchungen, wenn wir keinen passenden Account ermitteln können.
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.