LL#16 – Liebes Logbuch…
Auch intern wollen ein paar Tools entwickelt werden. Beispielsweise ist die Bearbeitung von Spamvorfällen immer ein bisschen frickelig: Zunächst muss die Queue-Verarbeitung gestoppt werden; vergisst man das, handelt man sich möglicherweise Inkonsistenzen ein. Die Mails müssen dann entfernt werden und je nach Art des Problems in den Spamfilter gefüttert werden oder nicht (manchmal geht’s zum Beispiel auch um einen Cronjob, der minütlich Fehlermeldungsmails generiert - die sind dann aber halt kein Spam im klassischen Sinne), und nach Abschluss der Arbeiten auch bedacht werden, dass die Queue wieder gestartet werden muss, sonst jammert kurz darauf das Monitoring. All das ist nun in einem Wrapper zusammengefasst. Immer bedenken: Im Zweifelsfall erwischt einen so ein Vorfall nachts um vier, und halb schlaftrunken ist es sehr viel leichter, Flüchtigkeitsfehler zu machen… die werden damit nun besser vermieden.
Mehr Automation gibt’s nun auch in der Buchhaltung. Zum einen müssen wir für die korrekte Besteuerung aus unseren Stripe-Kreditkartenumsätzen einen monatlichen Bericht erstellen, der die Zahlungseingänge (und ggf. Rückzahlungen) nach Ländern gruppiert, was bisher über den CSV-Export aus Stripe per Hand gemacht werden musste. Nun wird das endlich automatisch erstellt und generiert direkt ein fertiges PDF (mittels pandoc, wir haben also wunderschönen TeX-Schriftsatz) für den Steuerberater. Unser internes Banking-Tool hat nun außerdem ein Update erhalten, bei dem einige regelmäßige Zahlungsausgänge, zu denen es keine Belege gibt (Krankenversicherung, betriebliche Altersvorsorge, Büromieten, …) automatisch abhaken kann, was die monatliche Buchhaltung etwas weiter abkürzt. Das System basiert auf einer Tabelle mit regulären Ausdrücken, die dann auf bestimmte Transaktionen anschlagen.
Und noch eine erfreuliche Neuerung aus dem Buchhaltungsbereich. Wir rufen unsere Kontoumsätze automatisiert via FinTS ab, und so kann unsere Buchhaltung den ganzen Monat über die anfallenden Belege mit Transaktionen abgleichen. Mit Zahlungen per Kreditkarte funktioniert das leider nicht so fließend - hier kommt schlicht einmal im Monat ein PDF mit der Abrechnung, und dann muss das alles im Block erledigt werden, was sehr unpraktisch ist. Seit der Fusion der Sparkasse Mainz mit einer anderen Regionalsparkasse zur Rheinhessen Sparkasse hat offenbar auch deren Technik ein Update bekommen - und wir bekommen auch die Kreditkartenumsätze nun über FinTS rein, so dass wir sie nun schon den Monat über bearbeiten können. Hilfreich ist das vor allem, wenn für Transaktionen Belege fehlen und dafür erst nachgefragt werden muss - wenn die Transaktion dann schon Wochen zurückliegt, ist sehr viel mehr Erinnerungsvermögen gefragt.
Es gibt neue Python-Versionen! Das ist jetzt erstmal keine Nachricht wert, denn neue Versionen von allem möglichen gibt es ständig. Hier ist es aber etwas anders: Wir haben bei uns nämlich eine eigene, neuere Version von SQLite als die, die mit CentOS mitkommt und schon Schimmel ansetzt. Wir verwenden aber auch neuere Versionen von PostgreSQL, und die bringen in ihrem Repo… ebenfalls ein sqlite-RPM mit, das zwar neuer ist als das von CentOS, aber älter als das von uns. Und weil das mit einer eigenen ld.so-Config kommt, bekam es plötzlich Präferenz gegenüber unserem eigenen sqlite. Wir haben also etwas gewerkelt und schließlich mit ebenfalls einer eigenen ld.so-Config wieder unserer Version Präferenz verschafft, in dem wir sie in ein extra Verzeichnis verschoben haben, das wir dann bevorzugen konnten. Das klappt auch prima auf den produktiven System - aber auf unseren Build-Systemen, die die Python-RPMs bauen, dafür dann schließlich nicht mehr. Stellt sich heraus: Der Build-Prozess von Python sucht nach SQLite ausschließlich in ganz bestimmten, fest einkodierten Verzeichnissen. Es gibt keinerlei Möglichkeit, zum Beispiel per ./configure-Argument, einen anderen Pfad mitzugeben. Wir musste nun also auch noch in unserer Build-Umgebung tricksen, damit Python unser schönes aktuelles SQLite auch wieder findet. Nachdem diese Hürde genommen wurde, gibt es nun also eine schöne Runde Updates!
Das Operations-Team bringt nach und nach alle internen Systeme von Debian 11 auf Debian 12, was auch unsere Hosting-Cluster für die U7-VMs betrifft. Wie sich das für einen Cluster gehört, ist das alles unbemerkt im laufenden Betrieb gelaufen: Die produktiven VMs können jeweils von einem zu aktualisierenden Clusterknoten per Livemigration wegbewegt werden, dann bekommt jener leergeräumte Knoten sein Update und wird schließlich wieder in den Cluster integriert und seine VMs zurück.
Soviel für heute, bis in Bälde!
J.