LL#4 – Liebes Logbuch…

Es gibt mal wieder ein neues U7-Release, dessen Änderungen sich wie üblich im ChangeLog nachvollziehen lassen. Neben diversen Updates und der Bereitstellung weiterer Kommandozeilentools (auf eure Wünsche hin - wir leiten ganz oft aus Supportanfragen ab, was potentiell sinnvoll und praktisch für alle wäre!) haben wir einen Mechanismus eingebaut, der allen supervisord-Services, die keine startsecs-Angabe haben, automatisch startsecs=30 verpasst. Hierbei handelt es sich um eine Einstellung, wie lange ein Service mindestens laufen muss, damit supervisord ihn als korrekt funktionierend betrachtet. Standardmäßig wird hier seitens supervisord nur 1 Sekunde lang gewartet - allerdings ist der Start einiger Applikationen, insbesondere derer mit vielen Abhängigkeiten und Modulen, so komplex, dass er länger als eine Sekunde dauert. Bricht der Service dann erst etwas später ab, startet supervisord ihn neu. Dabei wird unterschieden zwischen den Services, die mindestens startsecs viele Sekunden gelaufen sind: Bricht der Service früher ab, klemmt supervisord ihn nach zwei weiteren erfolglosenen Versuchen ab; hat er aber die Mindestdauer an Laufzeit erreicht, erfolgen diese Neustarts wieder und wieder. Das bedeutet, dass ein kaputter Service dann unendlich oft neu gestartet wird, permanent - und dabei jedes Mal aufs Neue CPU-Zeit verbraucht, in einem Umfang, der dann gelegentlich auch unser Monitoring Alarm schlagen lässt. Das ist schlecht für alle: Für uns, weil es gegebenenfalls zur Unzeit jemanden rausklingelt, um sich so eine Situation persönlich anzuschauen, und für euch, weil solche Vorgänge CPU-Zeit “klauen”, die anderswo sicher besser genutzt wäre. Leider ist es seitens supervisord nicht möglich, hier global einen anderen Wert als 1 Sekunde vorzugeben - das ist fest einkompiliert. Wir haben bereits versucht, anzuregen, eine entsprechende globale Einstellung anzuregen, leider ohne Erfolg. Daher nun die alternative Strategie: Wir verpassen jeder einzelnen Service-Konfiguration die entsprechende Einstellung. Wer an dieser Stelle andere Werte einstellen möchte, ist natürlich herzlich willkommen - die werden dann nicht angefasst.


Freelance-Softwareentwicklerin, Rust (d/w/m)

Das Projekt ist vergeben. Bitte nicht mehr darauf bewerben!

This job posting is written in German. However, we all speak English here. Feel free to apply even if you don’t know German. Translating this post is left as an exercise to the applicant. ;)

Achtung! Es geht hier um Freelancing auf Rechungsbasis mit geringem Umfang. Aktuell gibt es bei uns leider keine unbesetzte Vollzeitstelle.

Unser Development-Team besteht aus Python-Devs, Ansible-Künstlerinnen und klassischen Linux-Admins. Damit kommen wir ganz schön weit! Bei einigen Themen ist da jedoch schneller Schluss als uns lieb ist. Nun könnten wir Python-Menschen anfangen Programmiersprachen wie C zu lernen, nur ist das weder für uns noch für den resultierenden Code eine gemütliche Sache.


LL#3 – Liebes Logbuch…

Nachdem es die letzten Monate hoch her ging und viel passiert ist, war der November bei uns bisher etwas ruhiger. Einige Kolleg*innen haben sich eine lang verdiente Auszeit gegönnt und der Rest hat es auch eher etwas ruhiger angehen lassen, damit es bald mit neuer Energie weitergehen kann. Natürlich ist in den letzten Wochen aber trotzdem einiges passiert.

So haben wir jetzt Inhibition für das Monitoring unserer U7 Hosts mit Prometheus und Alertmanager. Das heißt, unser U7-On-Call wird nicht mehr für jeden Service einzeln angeklingelt, wenn ein Host ausfällt, sondern nur noch dafür, dass der Host nicht mehr erreichbar ist. Gleiches gilt auch dafür, wenn eines unserer Rechenzentren ausfällt, dann bekommt unser Operations-On-Call nur noch eine Info darüber, dass das Rechenzentrum nicht mehr erreichbar ist und wird nicht mit hunderten von Alerts geflutet, sodass das Handy nicht mehr stillsteht. Das ist ganz schön anstrengend, wenn man gerade versucht ein Problem zu beheben ;)


LL#2 – Liebes Logbuch…

Wie lässt sich sozialer Zusammenhalt schaffen, wenn man in der Regel nur remote zusammenarbeitet? Kurz gesagt, eine definitive Antwort haben wir darauf auch nicht, aber wir probieren immer wieder Dinge aus. Eins davon war der “Open Friday”, ein regelmäßiger Termin, wo für uns einen Freitagnachmittag freigehalten haben, um 1-2 thematische Sessions zu machen, die nicht unmittelbar mit der Arbeit zu tun haben - mal ging’s um Grundlagen der Fotografie, mal um Erfahrungen mit Brotbacken, mal wurde aus einem privaten Ehrenamt erzählt, mal haben wir uns gegenseitig unsere Lieblingstools - elektronisch oder auch physisch - vorgestellt. Das hat oft viel Spaß gemacht, aber sich mit der Zeit ein wenig totgelaufen: Trotz niedriger Hürde, in dieser Runde etwas aus dem nicht beruflichen Alltag zu teilen, hatten sich zuletzt immer seltener Beiträge finden lassen, und so haben wir beschlossen, diesen Termin in unseren Kalendern erstmal abzureißen, ebenso wie einen alle zwei Wochen mittwochnachmittags stattfindenden “Telekaffee”. Was wir bei unserem Teamtreffen sehr deutlich gemerkt haben: Die meisten von uns dürsten zwar nach sozialer Aktivität - aber für die wenigsten von uns liefern Online-Formate dann tatsächlich das Gefühl von Zusammenhalt, das wir uns wünschen. Wir ziehen für uns daraus, dass gegenseitige Besuche in nächster Zeit erstmal wieder verstärkt dran sind, und unser bahn.business-Konto verzeichnet entsprechend schon wieder rege Ticketbuchungen. Trotz wehmütiger Gedanken an schöne Freitage: Es ist je nach Kontext oft keine Schande, etwas abzureißen, was einfach nicht mehr gut funktioniert, und zwar auch ohne schon den neuen, besseren Plan in der Schublade zu haben. Damit verbunden heißt es aber auch: darauf zu achten, welche Bedürfnisse sich nun wieder in den Vordergrund schieben - und jene zu artikulieren, damit sich daraus Neues entwickeln lässt.


LL#1 – Liebes Logbuch…

Seit gut über einem Jahr erstellen Mo und ich teamintern etwa alle 2-3 Wochen eine kleine Retrospektive. Wir haben die Erfahrung gemacht, dass es bei konsequentem Home-Office und dem damit verbundenen Fehlen von regelmäßigem Teeküchen-Schnack schnell passieren kann, dass Einzelne gar nicht mehr so unmittelbar mitbekommen, was in anderen Teams als dem eigenen (Operations, Development, Support…) so passiert. Die Retrospektive soll dafür sorgen, dass alle regelmäßig einen kleinen Überblick über “alles” bekommen, was in letzter Zeit so lief. Und nachdem das nun intern über ein Jahr lang gut geklappt hat, wollen wir diese Retrospektive künftig auch nach draußen zu tragen - zumindest die Teile davon, die wir auch für euch für potentiell interessant halten. Unter dem Titel “Liebes Logbuch…” halten wir euch insofern nun parallel dazu ein wenig auf dem Laufenden darüber, was bei uns, vom Changelog abgesehen, hinter den Kulissen noch so passiert ist. Auf geht’s!


Ausfälle der Netzwerkanbindung am Standort FRA4

Am letzten Freitagnachmittag (02.09.2022) und am darauffolgenden Samstagabend hat vielleicht bei der ein oder anderen von euch das Monitoring geklingelt, weil euer Uberspace plötzlich nicht mehr erreichbar war. Warum das so war, möchten wir heute versuchen zu erklären.

So wie auch bei euch, hat auch uns unser Monitoring freitags um 14:37 Uhr alarmiert, dass am Standort FRA4 etwas nicht stimmt. Genau genommen haben wir aufgrund der Menge der Meldungen sofort gesehen, dass der Standort scheinbar nicht mehr erreichbar ist, was wir kurz darauf verifizieren konnten.


Ein Bekenntnis zur freien Preiswahl. Und ein Aber.

Seit der Anfangszeit von Uberspace haben wir ein Preismodell, bei dem du wählst, was du monatlich zu zahlen bereit bist. Dabei ist es auch möglich, einen Preis zu wählen, der für uns eigentlich “zu niedrig” ist. Dieser wird dann von Anderen mit einem höheren Preis querfinanziert. Daran möchten wir auch weiterhin festhalten, führen aber trotzdem ein paar Änderungen ein:

Wählst du einen Preis, der unter dem als Budgetpreis empfohlenen Betrag von 5 Euro liegt, leiten wir dich künftig zunächst auf eine separate Seite um, die noch einmal erklärt, dass wir zu diesem Preis nicht nachhaltig arbeiten können. Es geht für uns darum, dass du einen niedrigeren Preis wirklich nur dann zu wählst, wenn ein Hosting bei uns ansonsten daran scheitern würde. Außerdem möchten wir dich auf dieser Seite über die Regelung für diesen reduzierten Preis informieren.


Organisch wachsen - gar nicht so leicht

Wir fallen mal direkt mit der Tür ins Haus: Wir würden gerne ein bisschen wachsen. Keine Sorge, wir reden hier nicht von heuschreckenartigem Risikokapital oder dem Ziel, den Laden höchstbietend zu verkaufen; ganz im Gegenteil: Wenn wir “ein bisschen” sagen, meinen wir das auch genau so. Konkret so um die 5 bis 10 Prozent, denn zuviel Wachstum auf einmal macht auch Dinge schwierig.

Vertrauenswürdige Zertifizierungsstellen und Softwareentwicklung: Mehr Chaos als gedacht

Neulich ist ja nun ein altes Root-Zertifikat von Let’s Encrypt abgelaufen und sehr zur Überraschung Vieler hat das zu einigen mehr - lösbaren - Problemen geführt als erwartet, auch bei uns. Eine der Ursachen ist, dass sich Listen vertrauenswürdiger Zertifizierungsstellen an viel mehr Stellen finden als man so gemeinhin annehmen würde.

Hintergrund

Kurz und knapp vorweg: Eine Liste vertrauenswürdiger Zertifizierungsstellen legt fest, welchen Zertifikaten vertraut wird und welchen nicht. Und wenn das jetzt irgendwie nach einer doch ziemlich wichtigen Geschichte klingt, dann, weil das eben auch wirklich so ist. Eine Angreiferin kann sich zwar problemlos ein Zertifikat erstellen, das auf die Domain deiner Bank lautet; keine vertrauenswürdige Zertifizierungsstelle sollte ihr allerdings eine Signatur dafür geben. Ohne diese wird dein Browser dich beim Aufruf der Domain per HTTPS mit Warnmeldungen überschütten, dass das Zertifikat nicht vertrauenswürdig ist.


Über Zertifikatsketten und Ablaufdaten

Heute haben ein paar Dinge ganz schön geknarzt, die mit Let’s Encrypt, OpenSSL und CentOS zu tun haben und deren Aufarbeitung vielleicht auch im Detail für euch interessant ist. Direkt vorweg: Die Erreichbarkeit deiner bei uns gehosteten Dinge per HTTPS war davon nicht beeinträchtigt.