LL#5 – Liebes Logbuch…
So, das mit dem “Wenn’s klappt, lesen wir uns an dieser Stelle so in knapp zwei Wochen nochmal” vom LL#4 hat ja dann… doch nicht so geklappt, aber wie das so ist: Gegen Ende des Jahres verschiebt sich der Fokus dann doch mehr ins Private, und betrieblich passiert schlicht ein bisschen weniger. Aber nun starten wir frisch ins neue Jahr!
Noch wird das CentOS 7, auf dem unser U7 basiert, rund anderthalb Jahre lang mit Updates versorgt. Es gilt insofern aber auch, keine Zeit zu verlieren, einen würdigen Nachfolger zu bauen. Die in LL#4 angekündigten Überlegungen, sich hierzu vielleicht ganz aus der Welt der RHEL-Nachbauten zu entfernen, haben sich konkretisiert und wir werden hier nun - wenn uns nicht spontan beim Bauen alles um die Ohren fliegt - auf eine Rolling-Release-Distribution setzen. Mehr aktuelle Software, für alle, auf Dauer! Auch ein für unsere Zwecke möglicherweise besser geeignetes Dateisystem ist in der Evaluation, und last but not least hat das Kind intern jetzt auch nicht mehr nur einen Arbeitstitel, sondern auch bereits den endgültigen Namen. Jetzt ist aber erstmal Schluss mit Teasern - wisset, dass wir euch und eure Bedürfnisse auf dem Schirm haben und hinter den Kulissen parallel zur Pflege von U7 fleißig an der nächsten Generation arbeiten, und natürlich auch an einer möglichst schmerzfreien Migration dorthin.
Was außerdem nie zu kurz kommt, ist der Abbau von Altlasten. Zu Zeiten von U5 und U6 hatten wir je einen Host, den wir nicht mit normalen Accounts bestückt haben, sondern den wir dafür genutzt haben, um neue Dinge darauf zu entwickeln und dann von dort aus zu verteilen (ein Vorgehen, das es mit U7 nicht mehr gibt; hier wird nun alles automatisiert in einer CI gebaut). Und wie es dann so ist, wachsen solche Hosts wie betüddelte Haustiere vor sich hin und sammeln auf fast magische Weise “Wo kann ich denn XY grad mal installieren… ach, ich pack das mal auf andromeda”-Altlasten an so wie Teppiche das mit Krümeln tun. Keine Sorge: Den betreffenden U5-Host gibt es schon seit Jahren nicht mehr. Nun ist aber auch die letzte U6-Altlast in Form von andromeda ebenfalls Geschichte. Es gibt halt irgendeinen Punkt, wo man dann mal einen “Brownout” machen muss und einfach mal Dienste abschaltet, um zu gucken, ob dann vielleicht jemandem auffällt, dass sie noch gebraucht wurden. Und so haben wir letztlich auch hier nur so noch zwei, drei Kleinigkeiten gefunden, für die nun aber ein neuer Ort, Dokumentation und saubere Prozesse gefunden wurden.
Spaß mit Banken! Seit einer halben Ewigkeit buchen wir die Transaktionen des Tages um 21 Uhr ein, denn es war durch umfangreiche Tests eindeutig: Nach 18 Uhr kommen keine Transaktionen mehr dazu. Das galt aber offenbar nur bis zum 30.12.2022: Hier sind plötzlich einige wenige Transaktionen erst nach 21 Uhr auf unserem Konto eingetroffen und sind dann prompt nicht mehr vom Buchungslauf erwischt worden. Mit viel Handarbeit haben wir die dann nachbuchen können und mussten dazu eine extra vorgesehene Sperre für Doppelbuchungen auskommentieren, die normalerweise verhindert, dass Buchungen eines Tages importiert werden, für den bereits Buchungen vorliegen. Wir haben dann beschlossen, Buchungen künftig erst um 0:30 Uhr durchzuführen, dann entsprechend für den gestrigen Tag. Das klingt erstmal ganz schlau; es wäre dann aber auch sinnvoll, die Berechnung, welches Datum denn “gestern” war, auch in der Zeitzone Europe/Berlin und nicht in UTC zu machen… das Ende vom Lied war dann: Aus “gestern” wurde in der Berechnung “vorgestern”, und in Kombination mit der temporär entfernten Sperre für Doppelbuchungen wurde dann also der gesamte vorgestrige Tag noch einmal eingebucht… was dann am Ende noch mehr Handarbeit gemacht hat und doppelte Transaktionen wieder rausgefrickelt werden mussten. Aber es ist alles aufgeräumt, alle betroffenen Accounts informiert, der Code gefixt und natürlich - ganz wichtig - auch die Sperre für Doppelbuchungen wieder drin. Nun sollte uns aber wirklich nichts mehr durch die Lappen gehen!
Der interne Aufbau eines zweiten Systems für Backups schreitet weiter voran. Unser rsync-basierendes Backup, das die Basis für die im Manual dokumentierten Backups ist, wird künftig durch ein Blockdevice-Backup mit Hilfe des Proxmox Backup Servers ergänzt. Das hat diverse Vorteile: Erstens, ein zweites Backup auf separater Hardware ist immer gut. Zweitens, ein blockbasiertes Backup lässt sich sehr viel schneller und effizienter machen, denn es kann aus dem Storagelayer einfach abfragen, was sich seit dem letzten Backup geändert hat. Drittens, ein Restore einer kompletten VM lässt sich aus diesen Backups sehr viel besser machen. Am Ende sind “Backups für Nautis, falls jemand versehentlich eine Datei löscht” und “Backups für uns, falls uns größere Dinge komplett abfackeln” zwei sehr unterschiedliche Use Cases, für die nicht notwendigerweise ein- und dieselbe Backup-Strategie die richtige ist. Die neuen Backups stehen insofern nur uns für den Fall von Disaster Recovery zur Verfügung; deshalb brauchen wir hier auch keine lange Aufbewahrungsdauer, sondern nur wenige Tage, denn sie sind nur für den akuten Schadenfall da. Hier laufen nun seit einiger Zeit die initialen Backups nacheinander für alle VMs, und währenddessen wird das Drumherum immer eleganter: Beispielsweise generieren wir Alarme, wenn auf einem Blockdevice ungewöhnlich viel Leselast passiert - denn in der Regel gibt es dann etwas einzugreifen. Wann aber gibt’s auch viel Leselast? Richtig, beim Backup! Ergo gibt es nun eine schicke Funktion, die das Leselast-Monitoring spezifisch für jeden einzelnen Host während des Backups eben jenes Hosts abschaltet, in dem automatisch eine Silence im Alertmanager gesetzt wird. Und inzwischen gibt es auch wunderbare Messwerte im Prometheus, so dass wir leicht prüfen können, wann für einen Host das letzte Backup stattgefunden hat und wie lange es gedauert hat, um daraus dann auch schöne Alarme bauen zu können. Das bisherige rsync-Backup läuft davon völlig unbenommen weiter wie bisher - es ändert sich also nichts, außer dass ihr vielleicht noch ein wenig ruhiger schlafen könnt.
Im November 2021 hatten wir euch darauf vorbereitet, dass wir Accounts, deren Preis auf weniger auf 5 Euro gesetzt wird, periodisch auf 5 Euro zurücksetzen, natürlich mit Vorankündigung und auch mit der Möglichkeit, ihn direkt wieder herunterzusetzen. Das hat unseren Finanzen tatsächlich ziemlich gut getan und uns in 2022 einen guten Gewinn beschert - was nach zwei Jahren teurer Investitionen in viele viele viele SSDs auch mehr als nötig war: Ein guter Gewinn muss eben auch ausgleichen, dass es in den zwei Jahren davor einen solchen eben nicht gab… nun gehen wir natürlich in ein Jahr 2023, das von hohen Ausgaben geprägt sein wird: Die hohen Energiekosten treffen uns natürlich auch in unseren Rechenzentren ganz erheblich, die uns ab Januar Preise von bis zu 0,65€/kWh diktieren - denn wie es aussieht, werden Rechenzentren nach derzeitigem Stand wohl nicht von der Strompreisbremse erfasst. Für uns bedeutet das Mehrkosten für Strom von rund 30.000€ in diesem Jahr - ein ganz schöner Hammer, für den wir auch noch nicht “den” Plan haben, wie wir damit umgehen wollen. Und weil dazu ja auch die Inflation zuschlägt, ist davon auszugehen, dass auch unsere Ausgaben für unsere Gehälter entsprechend steigen werden müssen. Auch mit diesen Gedanken im Kopf ist es gut, mit einem finanziellen Polster in dieses Jahr starten zu können, das uns nicht in akute Bedrängnis bringt, wenn unsere Kosten steigen. Und da dieses finanzielle Polster letztlich ja von euch stammt, an dieser Stelle auch nochmal ganz ausdrücklich: Ein herzliches Dankeschön. Wir geben unser Bestes, wie auch schon in der Vergangenheit, verantwortungsvoll damit umzugehen und viel dafür zu tun, auch noch in ein, zwei, zehn Jahren der Hoster eurer Wahl zu bleiben.
Und schließlich noch: Ein Gruß aus dem Landgericht Hamburg. Dort fand im Januar nun endlich das Gerichtsverfahren statt, bei dem uns drei große Musiklabels dafür verklagen, dass das bei GitHub gehostete Projekt youtube-dl bei uns eine Visitenkarten-Website betreibt. Wir sind dankbar, in dieser Sache die Gesellschaft für Freiheitsrechte mit im Boot zu haben, also auch in der gerichtlichen Vertretung gemeinsam mit unserem Anwalt, der uns in dieser Sache bereits außergerichtlich vertreten hat. Ein mehrstündiger Verhandungstermin vor dem Landgericht Hamburg, an dessen Ende wie erwartet noch kein Urteil stand, denn dafür ist noch zuviel offen, worüber sich das Gericht eben erst noch ein Urteil bilden muss. Jenes ist nunmehr für den 3. März angekündigt und wird wohl von beiden Seiten mit Spannung erwartet - geht es doch einerseits um die Frage, ob Downloads von YouTube als legal zu betrachten sind, wofür wiederum die Frage ist, ob YouTube eine Technologie einsetzt, die im juristischen Sinne als wirksamer Kopierschutz gilt oder nicht; andererseits geht es um die Frage, durch welche Reifen wir als Hoster springen müssen, wenn uns zugetragen wird, dass auf einer bei uns gehosteten Website angeblich eine Rechtsverletzung stattfindet. In beiden Aspekten stehen wir hier vor Gericht gemeinsam mit der GFF auch für eure Interessen ein: Dafür, dass das Herunterladen von Inhalten, für das wir alle bereits mit der GEMA-Abgabe bezahlt haben, nicht einseitig mit technischen Mitteln ausgehöhlt wird, und auch dafür, dass Hoster bei schwer zu prüfenden Anschuldigungen auch in Zukunft “Sorry, das möge bitte ein Gericht entscheiden” sagen können, statt lieber immer auf Nummer Sicher zu gehen und potentiell sehr wohl legale Dinge zu sperren, weil ansonsten größerer juristischer Unbill droht.
Und damit schließe ich unser kleines Logbuch für heute erstmal wieder. Kommt alle gut ins neue Jahr. Und bleibt warmherzig. Auch wenn viele Menschen sich derzeit einem immer größeren Druck ausgeliefert fühlen und sich manchmal Hilf- und Ratlosigkeit breitmacht: Nicht alles hat eine einfache Lösung. Es liegt an dir und an mir und an uns allen, miteinander um so besser umzugehen, damit am Ende niemand auf der Strecke bleibt.
Bis zum nächsten Mal, J.