LL#8 – Liebes Logbuch…
Es gilt ein wenig Verzug aufzuholen. Die Geschehnisse der letzten Wochen sind im Moment nur als Notizen festgehalten und wollen noch aufbereitet werden - was während intensivem Interrailen zugegebenermaßen etwas ins Hintertreffen geraten ist, denn der Gedanke, dass sich Reisen und Arbeiten doch leicht kombinieren lassen, war vielleicht doch ein wenig blauäugig. Aber dennoch: Dieser Logbuch-Eintrag wird gerade im wunderbaren X2000 von Stockholm nach Malmö geschrieben - das Internet an Bord ist schnell und stabil, das wünsche ich mir daheim in Deutschland auch so…
An unserem Standort FRA1, wo wir zwar derzeit keine U7-VMs betreiben, aber jede Menge eigener Infrastruktur, ist nun ebenfalls der Umbau unserer Legacy-KVM-Hosts in einen Proxmox-Cluster abgeschlossen und sämtliche VMs dorthin migriert (oder stattdessen abgebaut, falls nötig). Damit sind unsere drei Standorte wieder ein wenig einheitlicher geworden.
Ein Seitenprojekt, das wir als Learning aus dem Stromausfall von vor zwei Jahren mitgenommen haben, ist nun erfolgreich abgeschlossen: Insgesamt 5 dedizierte Proxmox Backup Server erstellen neben unseren rsync-Backups nun auch tägliche blockbasierte Backups von allen VMs, um im Fall eines Großschadens ein zweites Backup zu haben, das sich zudem wesentlich leichter wiederherstellen lässt als eine VM auf Basis unserer rsync-Backups wiederherzustellen. Der Prozess der Beschaffung jener Backupserver, die Installation und Einrichtung der Backups hat sich naturgemäß eine ganze Weile hingezogen, weil es halt auch einfach mal sehr viel Arbeit macht und im Fall von FRA1 auch erstmal die dortige Clustermigration abwarten musste, aber nun ist er fertig - inklusive Automatismen, die zum Beispiel für die Dauer eines Backups automatisch eine Silence im Alertmanager setzen, damit wir keine Alarme über eine ungewöhnlich hohe Leselast auf einer VM bekommen, die wir ansonsten nämlich durchaus im Auge haben.
Ein bisschen Feilen im Detail: Auch Proforma-Rechnungen können nun einen länderspezifischen Umsatzsteuersatz haben. Das ist eigentlich relativ egal, weil Proforma-Rechnungen nun mal keine Umsatzsteuer-Rechnungen sind und wir sie eigentlich nur eingeführt haben, weil es einige Organisationen gibt, die außerstande sind, Überweisungen zu tätigen, wenn sie nicht erst eine Rechnung vorliegen haben - aber mit einer Proforma-Rechnung schon zufrieden sind. Nach der Aufladung gibt es dann die UStG-konforme Rechnung, die schon seit eh und je den korrekten Umsatzsteuer-Satz ausweist. Wir wissen aber, dass in der Praxis jene Unternehmen schlicht die Proforma-Rechnung in die Buchhaltung geben und fertig - um so wichtiger ist dann, dass jene wenigstens den korrekten Umsatzsteuersatz trägt.
Zwischendurch hat es mal bei Netlify gerumpelt: Aufgrund interner atmosphärischer Störungen (oder so) wurde dort für unseren Content plötzlich der HTTP-Status 400 ausgegeben, womit die Let’s-Encrypt-Validierung fehlschlug, und dann war HTTPS für Manual und Lab kaputt - sprich, beides war nicht mehr erreichbar. Das war ein bisschen desillusionierend, haben wir diese Sites doch bewusst zu einem anderen Anbieter ausgelagert, um sie erreichbar zu halten, selbst wenn bei uns mal eine größere Störung vorliegen sollte (so wie insbesondere auch unsere Statusseite) und der eben dafür mit redundanter Datenhaltung und überhaupt hoher Resilienz wirbt. Insgesamt hat es leider sehr lange gedauert, bis Netlify überhaupt reagiert hat, und der Supportverlauf hat ehrlich gesagt auch keinen so ganz guten Eindruck hinterlassen. Wir haben währenddessen Lab und Manual vorübergehend auf Uberspaces umgezogen - was es natürlich um so schwieriger macht, das Problem zu debuggen, während es besteht, aber wir können ja nicht ewig tatenlos warten. Inzwischen hat Netlify das Problem gefixt und Lab und Manual konnten wieder sauber zu Netlify zurückkehren.
Unser interner automatischer U7-Rebooter hat ganze Arbeit geleistet: Inzwischen sind alle U7-VMs mindestens einmal von ihm rebootet worden und die höchste Uptime, die wir derzeit haben, liegt bei 5 Monaten. Das mag erstmal widersinnig klingen, weil intuitiv Vielen erstmal eine hohe Uptime wünschenswert erscheint, aber so stellen wir sicher, dass kein System mit hoffnungslos veralteten Kerneln oder antiken Libraries im RAM läuft, und dass Services von Nautis auch hübsch bei Reboots automatisch neu starten bzw. dass es den Nautis auffällt, wenn sie das nicht tun. Klar, bei Updates, die wir selbst vornehmen, haben wir das in der Hand, direkt einen Reboot anzuschließen (und der automatische Rebooter lässt sie dann auch in Ruhe - nicht mehr Reboots als nötig). Aber auch im Userspace wird eben Software installiert, die dem gleichen Problem unterliegt - vielleicht werden bei einem Update Dateien ausgetauscht, aber ein Neustart der Applikation versäumt, und so läuft weiterhin eine veraltete Version. Oder Applikationen, die Memory Leaks haben: Zwar begrenzen wir die RAM-Nutzung von Accounts, aber wenn eine größere Zahl von Accounts mit der Zeit immer mehr RAM braucht, wird’s irgendwann eng. Inzwischen gehen Reboots auch so schnell, dass es in der Regel eine Sache von 1-2 Minuten ist, bis bereits wieder alles läuft. Am Ende laufen so Dinge stabiler und führen auch zu messbar weniger Engpässen.
Unsere rsync-Backups nehmen nun auch Verzeichnisse mit den Namen cache, .cache und tmp aus dem Backup aus, neben dem schon lange bekannten extra für nicht zu sichernde Daten vorgesehenen Verzeichnis no_backup. Hintergrund ist, dass rsync grundsätzlich ziemlich darunter leidet, wenn es mit riesigen Mengen an Dateien konfrontiert ist - dann dauert mitunter das Erstellen der Dateiliste länger als das eigentliche Backup. Wenn das dann dafür sorgt, dass die Backups nicht mehr nur in der ansonsten ressourcenmäßig recht entspannten Nacht, sondern bis weit in den Tag hinein laufen haben, wird’s problematisch. Und es gibt leider eine ganze Reihe von Applikationen, die Dinge in den Cache schreiben und offensichtlich niemals mehr invalidieren - wir reden da also nicht nur über Tausende von Dateien, sondern eher über Hunderttausende. Mit diesem naheliegenden Exclude fluppen die Backups deutlich besser.
In seltenen Fällen schlägt der Prozess der Löschung eines Accounts fehl - immerhin sind dort tausend Dinge zu tun, und manchmal passiert etwas Unvorhergesehenes. Damit diese Dinge nicht unbemerkt bleiben, werden solche Vorfälle nun in unserer Dashboard-Datenbank separat protokolliert und als Prometheus-Metrik exportiert - dann kann sich jemand den Fall konkret anschauen, idealerweise einen generalisierten Fix dafür bauen, und anschließend das Problem als behoben markieren.
Es war nur eine Frage der Zeit, aber Spammer haben unser Stickertool entdeckt, was darin resultiert, dass wir lauter lustige Bestell-PDFs bekommen, in denen uns im Kommentarfeld Angebote für private Solaranlagen und Sonderangebote für Microsoft-Office-Lizenzen begrüßen - oder auch das obligatorische “Ιch suсhe einе ernsthаfte und heiße Βezіеhung…” - um da jetzt nicht auch auf Captchas zurückgreifen müssen, haben wir uns erstmal einer trivialen Methode bedient: Man darf im Kommentarfeld keine URLs eingeben. Das hält im Moment den Spam ziemlich gut raus. :-)
Damit wir besser im Blick behalten, wenn es neue Versionen von Software gibt, die nicht von CentOS, sondern von uns selbst bereitgestellt werden, haben wir intern nun einen kleinen Tracker, der mit http://release-monitoring.org/ arbeitet: In einer YAML-Datei wird die dortige Projekt-ID hinterlegt, sowie in welcher Ansible-Vars-Datei bei uns die aktuell eingesetzte Version steht - und schon gibt’s automatische Informationen, wenn es irgendwo Updates gibt.
Unser Bewerbungsprozess für eine Stelle im Development-Team geht voran: Alle Bewerbungen sind gesichtet und Gesprächstermine mit den Menschen ausgemacht, bei denen wir uns gut vorstellen können, dass wir zueinander passen. Wir sind gespannt, wie’s weitergeht!
Dass wir die Klage der Musikindustrie in erster Instanz verloren haben, hatten wir ja schon in LL#7. Radio Corax hat ein Interview mit mir dazu gebracht. Wir halten euch weiter auf dem Laufenden.
Und weil dieser Logbuch-Eintrag schamlos auf den 21. April rückdatiert wurde, von dem die zugrundeliegenden Notizen stammen, obwohl er erst am 6. Juni verfasst wurde, folgt der nächste Eintrag auf dem Fuß, bis alle Notizen aufgeholt sind! Bis gleich! :)
J.