Mit dem heutigen Karfreitag beginnen die Osterfeiertage, und während auch wir uns ein paar ruhigere Tage gönnen werden und in erster Linie das Monitoring schauen lassen, dass nichts ausfällt, ist noch etwas Zeit, um wieder ein bisschen auf die letzten Wochen zurückzuschauen.

Aber zunächst, last things first: In der Klage der Musikindustrie gegen uns, weil die Visitenkarten-Website des Projekts youtube-dl bei uns gehostet wird, hat jene vor dem LG Hamburg gegen uns obsiegt. Die Gesellschaft für Freiheitsrechte, die uns und unseren Anwalt in der Verteidigung gegen die Klage unterstützt, hat dazu eine Pressemeldung herausgegeben. Details gibt es bei netzpolitik.org oder für unsere englischsprachigen Freunde bei torrentfreak.com. Wir gehen gegen das Urteil in Berufung. Wer dabei helfen möchte, kann die GFF unterstützen.

Nun aber zu den erfreulichen Sachen! :-)

Eins der größeren Update-Projekte, das schon beim letzten Mal zur Sprache kam, war die Migration von MariaDB 10.3 - über Zwischenschritte - auf MariaDB 10.6. Inzwischen ist dies vollständig abgeschlossen; damit sind wir in Sachen MariaDB nun auf einer Version mit Long-Term-Support - rechtzeitig, bevor die 10.3 am 25. Mai end of life wird. Insgesamt verlief das ziemlich reibungslos; lediglich der Umstand, dass utf8 bei MariaDB 10.3 nun nur noch ein Alias-Zeichensatz für utf8mb3 ist, sorgte bei einigen älteren Applikationen für den Bedarf, den Zeichensatz anzupassen.

Intern hat sich auch wieder viel getan und wir treiben bei uns im Ops-Team die Migration auf Debian-Systeme weiter voran. Dieses Mal waren die Runner für unsere selbst gehostete GitLab-Instanz fällig, die wir unter anderem dafür benutzen, um Pakete für Uberspace oder auch unsere Website oder unsere interne Dokumentation zu bauen.

Und auch in puncto Automation geht es voran: Nachdem nun schon seit längerer Zeit alle Uberspace-VMs in zwei Proxmox-Clustern (an zwei Standorten) laufen, nutzen wir nun auch erstmals die Proxmox-API für mehr Automation im Bereich Development - denn wenn wir Merge Requests in unserem GitLab approven, wird derzeit noch die Google Cloud dafür genutzt, um eine Test-VM zu deployen, unsere Test-Suite darauf loszulassen und sie danach wieder abzureißen. Keine Sorge wegen “Google”: Es sind hier keinerlei Daten von Userinnen involviert; die Google Cloud bietet aber halt eine gute Infrastruktur, um automatisiert VMs anlegen und löschen zu können. Das holen wir nun nach Hause, und zwar mit einer schönen Integration in Netbox, das wir für unsere Hardware- und VM-Inventarisierung nutzen: Dort gibt es nun vordefinierte Development-VMs, deren State man setzen kann (per Hand im Webinterface, oder gescriptet per Netbox-API), und eine von Leah gebaute Brücke reagiert auf diese Statusänderungen, in dem sie entsprechend die gewünschte Development-VM in Proxmox aufsetzt oder löscht. Dazu gibt es eine automatisch jede Nacht frisch angelegte VM, auf der wir tagsüber mal schnell per Hand Dinge rumprobieren und basteln können, für die es noch nicht lohnt, direkt den ganzen Prozess mit GitLab-Issue, Tests, Merge Request, Review etc. anzuwerfen - hier kann nach Herzenslust gefrickelt werden, denn alle wissen: In der Nacht wird diese VM wieder platt und neu gemacht. Unser U7-Nachfolger wird also komplett auf unserer eigenen Infrastruktur entwickelt!

Auch an unserem dritten Standort - dem ersten, den wir hatten: FRA1 - haben wir nun endlich einen ersten Proxmox-Cluster. Für Uberspace ist das nicht direkt relevant, weil wir lediglich zu Zeiten von U5 auch VMs an diesem Standort hatten, uns seit U6 aber voll auf FRA3 und FRA4 konzentrieren. Aber wir haben auch außerhalb von Uberspace noch eine ganze Reihe interner Systeme und auch Kundensysteme, die ebenfalls eine moderne Clusterplattform brauchen, und es bringt uns auch wartungstechnisch viele Vorteile, alle drei Standorte gleich oder zumindest sehr ähnlich aufgebaut zu haben.

Viel Liebe und Arbeit ist in unseren Stellenausschreibungsprozess geflossen - einen Prozess, in dem ich als Inhaber von Uberspace diesmal so gut wie gar nicht involviert bin. Es ist bei uns seit jeher Tradition, dass die Bewerbungsgespräche nicht mit dem Chef, sondern mit zwei anderen Leuten unseres kleinen Betriebs geführt werden: einer/einem unmittelbaren Kollegin/Kollegen aus dem jeweiligen Team (in diesem Fall, dem Development-Team), mit dem es künftig - auf Augenhöhe, nicht im Hierarchieverhältnis - zusammenzuarbeiten gilt, und einer/einem weiteren unmittelbaren Kollegin/Kollegen aus einem anderen Team, um nochmal einen zweiten, potentiell anderen Blickwinkel zu bekommen. Unsere Stellenausschreibung haben wir bewusst im generischen Femininum verfasst, um ganz besonders auch jene Menschen anzusprechen, die gerade im IT-Umfeld oft unterrepräsentiert ist. Inzwischen ist die Bewerbungsphase abgeschlossen, und die Gesprächszusagen oder -absagen sind verschickt. Nun folgen die Gespräche, und wir sind sehr gespannt, wie es laufen wird.

Manchmal sind’s auch nur kleine Änderungen, die für mehr Transparenz sorgen: Unsere Statusseite zeigt nun nicht nur die Vorfälle der letzten 7 Tage, sondern die Vorfälle der letzten 365 Tage. Uns ist wichtig, auch Vergangenes nicht unter den Tisch fallen zu lassen: Mit vielen Vorfällen sind auch Lehren verbunden, die wir darauf ziehen konnten, und uns weiterhin wichtig, auch mit dem offen umzugehen, was nicht rund gelaufen ist.

Wir haben außerdem den AV-Vertrag, den wir unseren Userinnen anbieten, geringfügig überarbeitet, und zwar in dem Aspekt, dass es bei der Hinzunahme von Unterauftragnehmern nun eine Widerspruchsfrist gibt. Das Thema ist eher kosmetischer Natur, denn es liegt ja nun gerade in unserer DNA, dass wir unsere Kerndienstleistung komplett selbst erbringen und eben gerade nicht z.B. auf AWS hosten. Auf der anderen Seite könnte es zu Situationen kommen, dass wir mal einen Unterauftragnehmer hinzuziehen wollen und nicht wirklich warten können: Wenn zum Beispiel mal ein Einbruch in Systeme stattgefunden hat, wollen wir beispielsweise ein Forensik-Unternehmen hinzuziehen können - und in diesem Fall wäre es nicht sinnvoll, erst auf den Ablauf einer Widerspruchsfrist zu warten. Gemeinsam mit der IHK Darmstadt, die sich hier entsprechende Änderungen gewünscht hatte, konnte eine Formulierung gefunden werden, die auch unserem eigenen Datenschutzbeauftragten gefällt und den Interessen beider Seiten gerecht werden dürfte. Neu abgeschlossene AV-Verträge gelten auf Basis des neuen Texts; die bereits bestehenden AV-Verträge bleiben bestehen. Wer “upgraden” möchte, kann im Dashboard den Vertrag beenden und direkt neu abschließen.

Aus der Kategorie “ärgerlich, aber nun gefixt” können wir berichten, dass uns aufgefallen ist, dass es tatsächlich vereinzelt User gibt, die die OpenPGP-Funktionalität in unserem Webmail-System genutzt haben, die wir eigentlich gar nicht vorhatten, anzubieten - denn für eine saubere Ende-zu-Ende-Verschlüsselung wäre wünschenswert, wenn die privaten Schlüssel auf den Geräten der Userinnen liegen und nicht auf einem gemeinsam genutzten System. Mit Mailvelope gibt es dazu eine schöne Open-Source-Lösung für den eigenen Browser, die wir allen ans Herz legen, die verschlüsselt kommunizieren wollen, aber keinen eigenen Standalone-Mailclient mit eingebauter OpenPGP-Funktionalität nutzen.

Außerdem haben wir festgestellt, dass wir bei der Einführung von DKIM-Support offenbar zu sicher unterwegs waren mit unseren 4096-Bit-Schlüsseln… die sind nämlich einigen Mailservern zu groß. Wir folgen hier nun der Empfehlung und generieren nur noch 2048-Bit-Schlüssel. Bei allen bereits bestehenden Schlüsseln haben wir untersucht, ob dafür bereits DNS-Einträge angelegt waren; wenn nein, haben wir den eh noch nicht in Verwendung befindlichen Schlüssel ausgetauscht; wenn ja, haben die den 4096-Bit-Schlüssel beibehalten, um DKIM nicht zu brechen - tauschen ihn aber auf Anfrage im Support gerne aus.

Bei einem internen Dauerbrenner-Thema gibt es inzwischen auch Fortschritte, nämlich in dem Bereich, den wir “U-Operations” genannt haben. Damit bezeichen wir den Graubereich von Dingen, die zwar nicht kaputt sind (dann würden sie bereits vom Monitoring alarmiert werden), aber dennoch nicht schön und damit untersuchenswert. Einfaches Beispiel: Wenn eine Disk einer VM vollläuft, wäre es ja nett, davon tagsüber zu erfahren, wo man sich ohne Stress darum kümmern kann, sie irgendwann im Lauf des Tages zu vergrößern, statt Samstagnacht rausgeklingelt zu werden, weil die Disk voll und in der Folge dann Dienste ausgefallen sind. Ähnlich verhält es sich zum Beispiel mit Traffic-Peaks, die nicht nur ein paar Minuten dauern, sondern sich über Stunden hinziehen - denn letztlich bezahlen wir für Traffic ja auch Geld. Auch Last-Peaks sind so eine Sache: Kompiliert jemand mal eine halbe Stunde lang eine Software auf drei CPU-Kernen - geschenkt. Hat aber jemand einen Dienst so kaputtkonfiguriert, dass er permanent neu startet und damit dauerhaft drei CPU-Kerne belegt, und zwar “für nix”: Dann wäre es schön, wenn das beim manuellen Draufschauen eben auch auffällt - gleichzeitig muss aber niemand Samstagnacht dafür rausgeklingelt werden; das reicht dann vielleicht auch Montagmorgen. Aber wie das dann so ist: Was nicht ganz akut zu erledigen ist, bleibt dann gerne auch mal etwas liegen, und die Motivation, sich etwas “weicheren” und unklareren Auffälligkeiten zu widmen, ist deutlich geringer als wenn klar ist: Es ist was kaputt, Userinnen merken das, wir müssen es fixen. Nach langen Ringen haben sich hier nun aber Fortschritte ergeben, die zumindest schon mal eine klare Zuständigkeit für die Bearbeitung solcher Dinge bedeuten, und in Kürze formiert sich dann das Team, das sich damit beschäftigen will, diesen Bereich besser zu strukturieren. Am Ende hilft diese Früherkennung ja auch dabei, Uberspace performanter und verfügbarer zu machen!

Unser Dev-Team hat ein Shell-Testing-Framework gebaut, das den schönen Namen shellinspector trägt. Es wohnt nicht in unserem GitLab, sondern öffentlich auf GitHub, damit auch andere Spaß damit haben können. Mit dem shellinspector können vorbereitete Specfiles durchgespielt werden, die definieren, welche Befehle als welcher User auf welcher Maschine ausgeführt werden, und welchen Output wir erwarten. Damit werden Tests auf ein bestimmtes Verhalten von Kommandos sehr einfach und praxisnah umsetzbar.

Und noch ein bisschen Development-Interna: Um die Konfiguration der von uns häufig benutzen Tools zu vereinfachen und zentral zu verwalten, haben wir einige Templates erstellt: Für .editorconfigs, Makefiles, Taskfiles, bumpver, pre-commits etc. - diese können dann mit dem Python-Tool copier gerendert und später auch aktualisiert werden. Gerade für neue Repos ist das sehr hilfreich und erleichtert den Start, wenn wir da ein Uberspace-übliches Set an Konfiguration einheitlich zur Hand haben.

Das Thema der verpflichtenden Arbeitszeiterfassung geht auch an uns nicht vorbei. Wir versuchen das Beste daraus zu machen und eine Lösung zu finden, die auf der einen Seite unseren Arbeitnehmenden möglichst wenig Arbeit macht, und auf der anderen Seite vielleicht auch wirklich den positiven Effekt haben könnte, chronische Zuviel-Arbeit aufzudecken. Denn wir setzen bei uns Vertrauensarbeitszeit in einem sehr weitreichenden Maß um: Nicht nur Arbeitszeit und -Ort können frei bestimmt werden, sondern auch der Arbeitsumfang an sich, sprich, es gibt vom Arbeitsvertrag her keine Mindestarbeitszeit - denn auch das bedeutet Vertrauen für uns: Wir vertrauen darauf, dass die Menschen, die sich für eine Tätigkeit bei uns entscheiden, eben auch hier arbeiten möchten. Neben einer Untergrenze hat unsere Arbeitszeit aber eben auch keine Obergrenze - was nicht heißt, dass wir uns hier bewusst alle ausbeuten wollen; im Gegenteil: Wir achten sehr aufeinander und sprechen offensiv an, wenn wir den Eindruck haben, dass jemand aus dem Team chronisch “zuviel da ist”. Auch in unseren Check-Up-Gesprächen, die ich mit jeder Person im Team jeden Monat führe, thematisieren wir die jeweilige Arbeitszeit regelmäßig. Wir verbinden mit der Arbeitszeiterfassung die Hoffnung, ggf. aufdecken zu können, wenn Arbeitnehmende unbewusst regelmäßig zuviel arbeiten und das selbst in der Reflektion im Check-Up-Gespräch nicht auffällt. Derzeit evaluieren wir für diesen Zweck Kimai, und damit es nicht so lästig wird, sich an- und abzumelden, entwickeln wir eine Anbindung an unseren Teamchat, so dass der Präsenzstatus aus dem Chat schon mal automatisch in Kimai einfließt und somit selbst dann ein recht brauchbares Arbeitszeitprotokoll zu schaffen, selbst wenn man komplett vergisst, sich für die Arbeit an- oder abzumelden. Weiterhin ist uns hierbei wichtig, dass ich als Arbeitgeber nur die Informationen aus dem System bekomme, die ich benötige, um meinen Verpflichtungen nachzukommen, nämlich zu prüfen, dass Höchstarbeitszeiten nicht überschritten werden und Ruhezeiten nicht unter den Tisch fallen. Wer genau wann genau da ist oder nicht: Das alles möchte ich weiterhin gar nicht wissen.

Anekdote am Rande dazu: Mit Grauen erinnere ich mich an ein Mittagessen mit einem Freund in dessen Homeoffice. Er arbeitet bei einer großen Unternehmensberatung, deren Namen ich nicht nennen mag; wobei, ist vermutlich auch egal, mich würde nicht wundern, wenn das bei den anderen großen auch so läuft. Vor dem Mittagessen griff er nach einer analogen Armbanduhr, legte sie auf den Tisch und platzierte seine Maus darauf. Meinen verwunderten Blick quittierte er mit der Erklärung: Der Sekundenzeiger löst so einmal pro Minute eine winzige Mausbewegung aus. Denn wenn er ansonsten die Maus während der Arbeitszeit längere Zeit nicht bewege, bekäme er sofort einen Anruf seines Vorgesetzten, warum er nicht arbeiten würde - so könnten wir dann in Ruhe ein wenig länger Mittagessen als die halbe Stunde, die ihm dafür maximal eingeräumt würde. Da möchte man sich doch direkt bewerben!

Mit dieser kleinen Geschichte beschließe ich den heutigen Logbuch-Eintrag. Schöne Ostertage euch allen, und bis bald!

J.

• ← Previous Post
• Next Post →