content/blog/2024/06/2024-06-18_campdays/index.md

++++
+title = "Lungern, Löten, Lummerland – die Campdays im Juni 2024"
+authors = ["nik", "lumi", "tuxilio"]
+
+[taxonomies]
+tags = ["Bericht"]
+zielgruppe = ["Kinder und Jugendliche", "Hacker und Maker"]
+aspekt = ["Campdays", "Tinkering"]
+
+[extra.depiction]
+image = "allgemein_sofa.jpg"
+alt = "Viele Kinder mit fast leeren Pizzatellern sitzen, die Füße hochgelegt, draußen auf grünen Sitzsack-Sofas"
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.3ddrucker]]
+image = "3ddrucker_1.jpg"
+alt = "Kinder und Erwachsene sitzen auf grünen Stühlen vor einem Bambulab P1S"
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.3ddrucker]]
+image = "3ddrucker_2.jpg"
+alt = "Kinder und Erwachsene sitzen auf grünen Stühlen vor einem Bambulab P1S"
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.spardose]]
+image = "spardose_1.jpg"
+alt = "Ein Jugendlicher zeichnet auf einem Convertible ein Design. Zwei andere Kinder schauen dabei zu; auf dem Tisch drumherum liegen einige Münzen und ein Messschieber."
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.spardose]]
+image = "spardose_2.jpg"
+alt = "Blick über die Schulter auf ein Convertible, auf dem ein Design in Krita gezeichnet wird."
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.ssg]]
+image = "ssg_1.jpg"
+alt = "Ein Jugendlicher erklärt an einem Beamer-Bild ein Tera-Template für den Static-Site-Generator Zola."
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.lummerland]]
+image = "lummerland_gartentisch.jpg"
+alt = "Drei Jugendliche sitzen draußen um einen Gartentisch. Einer lötet auf einer Lötunterlage, einer macht etwas an seinem Laptop."
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.lummerland]]
+image = "lummerland_loeten.jpg"
+alt = "Ein Jugendlicher an einem Gartentisch lötet an einem Chassis eines Waggons; vor ihm liegen zwei kleine Elektromotoren."
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.lummerland]]
+image = "lummerland_coding.jpg"
+alt = "Drei Jugendliche sitzen mit Laptops auf einer Sitzsack-Sofa-Garnitur auf der Wiese, zwischen ihnen liegen einige Elektronikbauteile."
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.lummerland]]
+image = "lummerland_bruecke.jpg"
+alt = "Ein Jugendlicher guckt unter einer Brücke einer Garten-Miniaturbahn hindurch."
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.lummerland]]
+image = "lummerland_test.jpg"
+alt = "Drei Jugendliche hocken vor dem gebastelten Waggon aufdem Gleis der Miniaturbahn und probieren ihn aus."
+credits = "Dominik George, CC-BY-NC-ND"
+
+[[extra.gallery.sommerfest]]
+image = "sommerfest_ehrungen.jpg"
+alt = "Mehrere Leute stehen auf einer Wiese, einige mit Urkunde in der Hand."
+credits = "Karin Meyer"
+
+[[extra.gallery.sommerfest]]
+image = "sommerfest_grillen.jpg"
+alt = "Tom steht vor dem Linuxhotel mit Schürze an einem Gasgrill."
+credits = "Karin Meyer"
+
+[[extra.gallery.sommerfest]]
+image = "sommerfest_laufen.jpg"
+alt = "Mehrere Kinder und Jugendliche laufen um die Insel mit der Lummerland-Miniaturbahn."
+credits = "Dominik George, CC-BY-NC-ND"
++++
+
+Die [Campdays](@/gemeinschaft/offene-gemeinschaft/campdays/index.md) sind das regelmäßige Barcamp der
+[Teckids-Gemeinschaft](@/gemeinschaft/offene-gemeinschaft/wer.md). Diesen Sommer
+fand es wieder einmal im [Linuxhotel](https://www.linuxhotel.de/) in Essen statt,
+wo wir drinnen und draußen viele Möglichkeiten nutzen konnten.
+
+<!-- more -->
+
+Von Freitagabend bis Sonntagnachmittag haben wir eine abwechslungsreiche Zeit mit
+vielen kreativen Technikthemen und auch Freizeit mit Singen, Sport und einem kleinen
+Sommerfest verbracht.
+
+## Barcamp-Sessions
+
+### Unboxing unseres 3D-Druckers
+
+Über die letzten Monate hatte sich eine Gruppe, geführt von JJ und Mats, mit der Anschaffung eines
+3D-Druckers beschäftigt. Hierzu hatten sie [in unserem Forum](https://forum.teckids.org/t/eigener-3d-drucker-fuer-die-teckids-gemeinschaft/2721)
+Anforderungen aufgestellt und Angebote verglichen und dann letztendlich einen Bambulab P1S bestellt.
+
+Der Drucker wurde pünktlich zu den Campdays geliefert und konnte dann im Linuxhotel ausgepackt und
+ausprobiert werden. Es wurde schon viel gedruckt, aber es standen auch noch einige Überlegungen an:
+Der Drucker ist seitens Bambulab eigentlich so konzipiert, dass er mit der proprietären
+Bambulab-Cloud arbeiten soll. Weil uns wichtig ist, dass alle in der Teckids-Gemeinschaft alle unsere
+Ausstattung uneingeschränkt benutzen können, gab es da noch einiges zu prüfen und zu diskutieren.
+
+{{ gallery(name="3ddrucker") }}
+
+### Elektronische Spardose mit Münzzähler
+
+Die Session zur automatisierten Spardose begann mit einer Einigung, welches Ziel mit der Spardose
+erreicht werden sollte: Einwurf und Entnahme von Münzen und deren automatische Zählung und Anzeige.
+Außerdem haben wir diskutiert, welches der [schon im Forum vorgeschlagenen Designs](https://forum.teckids.org/t/automatisierte-spardose/3332)
+grob hilfreich sein könnte.
+
+Geeinigt haben wir uns darauf, dass man die Münze auf eine Art Rampe legt, deren Schlitze immer größer
+werden, sodass die Münzen ihrer Größe nach sortiert werden. So fällt die Münze in den passenden Schacht
+und ein Infrarot-Sensor schlägt aus.
+
+Das Design wurde dann im zweiten Teil der Session von einer Hälfte der Teilnehmenden weiter ausgearbeitet
+und verbessert – so ist die Rampe nun nicht mehr gerade, sondern spiralförming, was zu einer kompakteren
+Spardose führt. Die zweite Hälfte beschäftigte sich damit, wie die Infrarot-Diode und der Infrarot-Empfänger
+angeschlossen und angesteuert werden können.
+
+{{ gallery(name="spardose") }}
+
+### Eine Lok für die Lummerland-Bahn
+
+Im Park des Linuxhotels gibt es eine Miniaturbahn, die die Insel [Lummerland](https://de.wikipedia.org/wiki/Lummerland)
+nachbildet. Für ein paar eisenbahnbegeisterte Teilnehmende war das diesmal ein Hauptgrund für die Campdays im Linuxhotel.
+
+In einer Session, die sich bis in den späten Abend zog, bauten wir eine eigene kleine Lok für die Modelleisenbahn.
+Zuerst druckten wir dafür mit dem 3D-Drucker Räder und einen Wagen aus und schlossen daran einen ESP8266 und Motoren an.
+Über einen kleinen Taster konnte man die Lok ein- und ausschalten – beim ersten Test wurde diese jedoch zu schnell
+und entgleiste.
+
+Daher begannen wir, zu testen, wie schnell oder schwer die Lok sein darf. Dabei testeten wir auch verschiedene Radgrößen
+aus. Später bauten wir zusätzlich noch ein Relais zum Schalten der Motoren ein. Schließlich programmierten wir noch eine
+Weboberfläche, mit der man die Lok ein- und ausschalten und steuern kann.
+
+{{ gallery(name="lummerland") }}
+
+Die Lummerland-Bahn bietet noch sehr viel Potential für weitere Bastelideen. Deshalb haben sich die Teilnehmenden
+schon gewünscht, einmal einen ganzen Tag nur mit diesem Thema im Linuxhotel zu verbringen und
+[entwickeln das Thema im Forum weiter](https://forum.teckids.org/t/lok-fuer-die-lummerland-bahn-beim-linuxhotel/3590).
+
+### Static-Site-Generatoren
+
+Bei der Session zu Static-Site-Generatoren beschäftigten wir uns damit, wie man eine eigene Website von
+Grund auf mit [Zola](https://www.getzola.org/) bauen kann. Ein Static Site Generator ist ein Werkzeug,
+das dabei hilft, statische Seiten aus Eingabedateien - wie zum Beispiel Markdown - zu erstellen. Dieser
+nimmt die Inhalte, wendet eine ausgewählte Vorlage an und generiert daraus statische HTML-Seiten.
+
+Zola ist ein in [Rust](https://www.rust-lang.org/) geschriebener Satic-Site-Generator, es gibt aber noch
+viele weitere.
+
+Wir begannen mit dem Erstellen der Seite und folgtem dem Einstigestutorial der Zola-Seite. Dabei
+beschäftigten wir uns zuerst mit dem Erstellen des Grundgerüsts und einer ersten index-Seite.
+Danach schrieben wir selbst verschiedene Layouts, mit denen eine Seite dann gebaut wird.
+
+Im Rest der Session probierten wir veschieden Dinge aus, über eine eigene 404-Seite bis hin zu einer
+Suche und eigenen Stylesheets.
+
+{{ gallery(name="ssg") }}
+
+## Sommerfest
+
+Am Samstagabend haben wir unser etwas vorgezogenes, kleines Sommerfest gefeiert. Einige Eltern
+sowie Bewohner\*innen der Villa Vogelsang kamen hinzu, um unter anderem der Würdigung ausgewählter
+Mitgleider der Teckids-Gemeinschaft beizuwohnen. Neben dieser Ehrung gab es genug Platz für
+sportliche Aktivitäten, Grillen und das freie Karaoke-Spiel [Performous](http://performous.org/).
+
+{{ gallery(name="sommerfest") }}

content/blog/2024/06/_index.md

++++
+transparent = true
+render = false
+in_search_index = false
++++

content/blog/2024/07/2024-07-08_stellenausschreibung/index.md

++++
+title = "Wir suchen dich als Chancenmanager*in"
+authors = ["nik"]
+
+[taxonomies]
+tags = ["Ankündigung"]
+
+[extra.depiction]
+image = "sharepic.png"
+alt = "Sharepic"
++++
+
+Unsere Gemeinschaft und ihre Aktivitäten wachsen. Deshalb suchen wir
+eine\*n Chancenmanager\*in, damit Aufgaben, die kontinuierlichen Einsatz
+erfordern, zuverlässig erledigt werden und unsere Ehrenamtlichen den
+Rücken frei haben.
+
+<!-- more -->
+
+{% message(title="Neuausschreibung") %}
+Die Stelle wurde ursprünglich im Juli 2024 ausgeschrieben. Seit Januar 2025
+ist die Position wieder verfügbar.
+{% end %}
+
+## Was macht die Teckids-Gemeinschaft?
+
+Die Teckids-Gemeinschaft ist eine Gruppe von Kindern, Jugendlichen und
+Erwachsenen, die gemeinsam das Ziel verfolgen, eine **verstehbare (digitale) Welt**
+zu schaffen. Kern ist dabei, dass wir innerhalb der Gemeinschaft, und damit dann
+auch um uns herum, **informationelle Selbstbestimmung** sowie einen hinterfragenden,
+aktiven und kreativen Umgang mit Technik zur Normalität werden lassen.
+
+Unsere eigenen Aktivitäten richten sich dabei an Kinder und Jugendliche direkt, aber
+auch an Lehrkräfte und Eltern:
+
+* Unsere Workshopfreizeiten wie [Hack'n'Sun](@/projekte/hack-n-fun/freizeiten/hacknsun/index.md)
+* Treffen der Gemeinschaft selber, wie unsere [Campdays](@/blog/2024/06/2024-06-18_campdays/index.md)
+* Impulsvortráge, wie z.B. zu [informationeller Selbstbestimmung](@/blog/2024/03/2024-03-19_normalisiert-selbstbestimmung/index.md)
+* Entwicklung freier Software für Schulen, wie [AlekSIS](https://aleksis.org/de/)
+* Betrieb von Plattformen wie [EduGit](https://edugit.org)
+* Erarbeitung und Erprobung von Konzepten zu Gleichwürdigkeit in Lernorten
+
+Als aktive Gemeinschaft fokussieren wir uns aktuell auf das Rheinland und das
+Ruhrgebiet. Das soll sich aber mittelfristig ändern. Schon jetzt beteiligen wir
+uns mit Programm weiträumig an Veranstaltungen, wie z.B. bei den Linux-Tagen in
+Chemnitz, Graz oder Tübingen.
+
+## Welche Aufgaben hat unser\*e "Chancenmanager\*in"?
+
+Einer der wichtigsten Grundwerte in unserer Gemeinschaft ist es, dass alle Mitglieder
+Spaß an dem haben sollen, was sie machen. Bei einmal übernommenen Aufgaben erwarten
+wir auch eine gewisse Zuverlässigkeit; grundsätzlich sollen aber Alle jederzeit das
+Recht haben, ohne schlechtes Gewissen eine Aufgabe abzugeben, die sie nicht mehr gerne
+machen.
+
+Keine Sorge – davon möchten wir hier keine Ausnahme machen! Allerdings ist die Zeit von
+Ehrenamtlichen oder sogar von unseren aktiven Jugendlichen viel eingeschränkter und die
+Anzahl der Themen, mit denen man sich beschäftigen kann, sehr groß. Deshalb möchten wir
+verschiedene Aufgaben, die für das Verfolgen unserer aktivistischen Ziele wichtig sind,
+an jemande\*n vergeben, der/die dafür durch eine Bezahlung langfristig fest Zeit einplanen
+kann.
+
+### Wichtige Aufgaben für Kontinuität
+
+Diese Aufgaben sollen kontinuierlich und zuverlässig erledigt werden, so dass wir unsere
+Ziele konsequent verfolgen können und unsere jugendlichen und erwachsenen Ehrenamtlichen
+den Rücken frei von unverrückbaren Pflichten haben:
+
+* Verfolgen von Social Media, insbesondere dem Fediverse (Mastodon)
+* Sammlung von Veranstaltungen/Konfrenzen/Barcamps/usw., bei denen wir uns beteiligen sollten
+* Überblick über Fördermöglichkeiten halten
+* Sponsorenakquise
+* Laufende Gespräche mit Partnerorganisationen, Sponsoren, usw. vorantreiben
+* Zusammenarbeit mit unseren Ehrenamtlichen bei der Planung und Vorbereitung von
+  Terminen und Kooperationen
+* Einrichtung und Betreuung von Crowdfunding und Crowdsourcing
+
+### Aufgaben, die du bei Interesse übernehmen darfst
+
+Neben diesen zentralen Aufgaben gibt es weitere Aufgaben, die du, je nach Interesse und
+wenn es die Zeit erlaubt, auch im Rahmen deiner Arbeitszeit erledigen darfst:
+
+* Unterstútzung beim Verfassen von Texten für die Website
+* Unterstützung beim Videoschnitt für Videoberichte und Imagevideos
+
+## Welche Voraussetzungen solltest du erfüllen?
+
+Grundsätzlich solltest du natürlich unsere Ziele und Werte persönlich unterstützen.
+Wir möchten, dass du primär an den oben genannten Aufgaben arbeitest, weil du sie
+selber wichtig findest und ideell hinter ihnen stehst.
+
+Außerdem solltest du folgendes mitbringen:
+
+* Bereitschaft, mit anderen, unabhängig vom Alter, auf Augenhöhe
+  zusammenzuarbeiten
+* Kompetenz im Umgang mit unterschiedlicher Software und
+  die Bereitschaft und Fähigkeit, dich auch in neue Plattformen
+  grundlegend einzuarbeiten
+* Grundlegende Fähigkeiten im Umgang mit einem Linux-Desktop
+* Die Begriffe Fediverse, Mastodon, Discourse, Mailingliste und Wiki
+  sollten dir nicht fremd sein
+* Hohe Sprachkompetenz (Rechtschreibung, Grammatik sowie freier Ausdruck)
+  besonders in deutscher Sprache
+
+Wünschenswert, aber nicht zwingend erforderlich, sind:
+
+* Grundlegende Erfahrungen mit der Arbeitsweise gemeinnütziger Organisationen
+* Wirtschaftliche Grundkenntnisse im Bereich Vereine und Stiftungen
+
+Im Falle einer Zusammenarbeit muss ein aktuelles, erweitertes Führungszeugnis
+vorgelegt werden.
+
+## Was bieten wir dir?
+
+Beim Thema *bezahlte Arbeitszeit* stehen wir ganz am Anfang. Deshalb beginnen wir
+mit einem Minijob, der sowohl von Studierenden als auch von anderen, die an einem
+Nebenjob interessiert sind, besetzt werden kann.
+
+Als Gehalt haben wir uns daher vorerst **520 €** im Monat bei einer Wochenarbeitszeit
+von **8 Stunden** vorgestellt. Das ist aber Verhandlungssache.
+
+Deine Arbeitszeit kannst du dir frei einteilen. Wir stellen uns vor, dass sie im
+Regelfall auf zwei halbe Tage pro Woche verteilt werden sollte. Deinen Arbeitsort
+kannst du frei wählen; wir haben keinen Bürostandort.
+
+Aufgrund des knappen Budgets und weil wir denken, dass du selber am besten weißt,
+was du brauchst, bieten wir keine so genannten "Benefits". Für deine Wünsche, mit
+denen wir dich unterstützen können, sind wir aber offen.
+
+## Wie kannst du dich bewerben?
+
+{% teckids_contact(title="Möchtest du uns unterstützen?") %}
+Bewerben kannst du dich per E-Mail, indem du uns formlos von dir, deiner Motivation
+und davon, was dich mit unseren Ideen und Zielen verbindet, erzählst. Wir würden
+gerne wissen, warum dich die Ideen unserer Gemeinschaft persönlich betreffen, wieso
+du sie voranbringen willst und auch, wieso du das bei uns tun möchtest.
+
+Im Sinne eines fairen Bewerbungsprozesses werden wir zunächst bis mindestens zum **28. Februar 2025**
+Bewerbungen sammeln. Diejenigen, die uns neugierig gemacht haben und bei denen wir
+uns eine Zusammenarbeit grundsätzlich vorstellen können, laden wir dann zum
+Kennenlernen ein. Das geht sowohl online als auch z.B. bei einem Besuch bei unserer
+Hack'n'Sun-Sommerfreizeit in Bonn.
+
+Beginn des Arbeitsverhältnisses soll nach aktuellem Plan der **1. April 2025** sein.
+{% end %}

content/blog/2024/07/2024-07-19_downtime-bericht/index.md

++++
+title = "Recovery-Abenteuer und Storage-Optimierung"
+authors = ["nik"]
+
+[taxonomies]
+tags = ["Bericht", "Sysadmin"]
+zielgruppe = ["Hacker und Maker"]
+
+[extra.depiction]
+image = "rack-sharepic.jpg"
+alt = "Frontansicht einiger typischer Supermicro-Server in einem Rack"
++++
+
+Vom 12. bis 15. Juli waren unsere Dienste offline. Auslöser war ein
+Fehler unseres Ceph-Storage-Clusters, nach dem wir alle Datenbanken
+wiederherstellen mussten.
+
+<!-- more -->
+
+*Hinweis: Die Erklärungen und Grafiken in diesem Post sind teilweise
+vereinfacht und dienen vor allem der Verstehbarkeit der Zusammenhänge,
+nicht der vollständigen Erklärung der beschriebenen Systeme.*
+
+## Kurzer Überblick über unsere Infrastruktur
+
+Teckids betreibt, mit Hilfe eines großzügigen und langjährigen
+Sponsorings der Firma [Speedparner](https://www.speedpartner.de/),
+souveräne Infrastruktur in einem Rechenzentrum in Düsseldorf. Kern
+davon ist ein Cluster aus vier [Proxmox-VE](https://www.proxmox.com/de/proxmox-virtual-environment/uebersicht)-
+Servern, die sowohl den Betrieb der virtuellen Maschinen als auch
+Netzwerk-Storage auf Basis von [Ceph](https://ceph.io/) übernehmen.
+
+Die meiste Hardware ist gebraucht oder sehr alt, mit Ausnahme von
+zwei Servern, die wir 2018 und 2019 beim Thomas-Krenn-Award gewonnen
+hatten. Diese sind jedoch nicht sehr leistungsfähig.
+
+Das größte Problem im Betrieb unserer Dienste in den letzten Jahren
+war die mangelhafte Performance des Storage. Zur Einordnung: Ein einfacher
+`apt install` des vim-Editors auf einer VM konnte bis zu 5 Minuten
+dauern. Ursache dafür waren vor allem langsame, mechanische Festplatten.
+
+## Ausbau und Optimierung des Storage
+
+Mit dem Finanzabschluss unseres Vereinsjahres 2022/2023 haben wir beschlossen,
+in die teilweise Modernisierung unserer technischen Infrastruktur zu
+investieren und dabei mit dem Austausch alle mechanischen Festplatten durch
+SSDs zu beginnen. Für etwas über 2000 € haben wir deshalb Anfang Juli
+14 NAS-taugliche SSDs gekauft.
+
+In einem Ceph-Cluster sind die Daten (*Objekte*) in so genannte *Placement Groups*
+organisiert, die wiederum auf *OSDs* verteitl sind. Die OSDs bilden eine
+Hierarchie, die die physische Verteilung der Datenträger wiederspiegelt. Mittels
+der *CRUSH-Map* garantiert Ceph dann eine bestimmte Verteilung, z.B. um Verfügbarkeit
+und redundante Kopien sicherzustellen. Wenn sich diese Topologie ändert, bspw.
+durch Ausfall eines Datenträgers oder das gezielte Hinzufügen oder Entfernen,
+werden Daten neu verteilt, so dass die gewünschten Garantien wiederhergestellt
+werden.
+
+![Verteilung eines Objekts in Ceph](ceph-objekte.png)
+
+Für den Umbau unseres Storage mussten also verschiedene Überlegungen angestellt
+werden:
+
+* Wieviele und welche Datenträger können gleichzeitig ersetzt werden, so dass
+  zu keiner Zeit zu wenig Speicherplatz vorhanden ist?
+* Wie reduzieren wir die Auswirkungen der Umverteilung (*Rebalancing*) während
+  des Umbaus?
+* Wie werden die Datenträgern in den Servern veteilt, so dass einigermaßen
+  gleichmäßig Speicherplatz zur Verfügung steht?
+
+## Ausfall des Storage
+
+Da auch der Platz für Datenträger in den Servern begrenzt ist, entschieden wir uns,
+zunächst den bisher vorhandenen, kleinen SSD-Cache zu deaktivieren. Das würde zwar
+vorübergehend zu noch schlechterer Performance führen, aber dafür die Dauer der
+Umbaumaßnahmen immens reduzieren. Deshalb haben wir als ersten Schritt am Freitag,
+dem 12. Juli, den Cache vom *writeback*- in den *readproxy*-Modus umgeschaltet. In
+diesem Modus sollten noch im Cache vorhandene Objekte benutzt, jedoch keine neuen
+Objekte mehr gecachet, werden.
+
+In diesem Moment meldeten die ersten VMs Dateisystemfehler und es kam zu Crashes der
+ersten Prozesse. Die tatsächliche Ursache hierfür konnten wir leider nicht gesichert
+feststellen. Am wahrscheinlichsten ist, dass eine schon länger vorhandene Inkonsistenz
+einiger Objekte im Ceph-Storage durch den Cache bisher verdeckt wurde. In dem Moment,
+in dem der Cache de facto deaktiviert wurde, wurden daher inkonsistente Daten ausgeliefert.
+
+## Erster Wiederanlauf der Dienste und PostgreSQL-Crash
+
+Der erste Wiederanlauf der Dienste wurde direkt nach dem Crash versucht. Die betroffenen
+Dateisysteme wurden mittels `fsck` geprüft und repariert und die VMs dann wieder
+regulär hochgefahren. In der Folge kam es jedoch erneut zu Fehlern; insbesondere
+der [PostgreSQL](https://postgresql.org/)-Cluster ließ sich nicht starten.
+
+Eines der Grundprinzipien in Datenbank-Management-Systemen sind nebenläufige
+Transaktionen. Jeder Zugriff auf die Daten einer Datenbank wird in eine so genannte
+*Transaktion* gekapselt. Das Datenbank-Management-System stellt sicher, dass
+das genaue Bild über die Daten innerhalb einer Transaktion konsistent ist.
+Wenn mehrere Clients gleichzeitig zugreifen und Daten verändern, dann darf
+das keinen direkten Einfluss auf andere Clients haben. Dieses und andere Prinzipien
+kann man unter der Abkürzung [ACID](https://de.wikipedia.org/wiki/ACID)
+zusammenfassen.
+
+![Transaktionen in PostgreSQL (vereinfacht)](pg-transaktionen.png)
+
+Nach der Korrektur der Dateisystemfehler auf dem System, auf dem unser
+PostgreSQL-Cluster läuft, fehlten Informationen über bereits vergebene
+Transaktions-Nummern und weitere verwandte Informationen. Notwendigerweise
+entschieden wir uns deshalb, den PostgreSQL-Cluster vollständig aus einem
+Backup wiederherzustellen.
+
+## Restore der PostgreSQL-Datenbanken auf unserem langsamsten Server
+
+Drei gute Nachrichten vorab: Wir hatten ein Backup des PostgreSQL-Clusters,
+es war aktuell und es ließ sich wiederherstellen! Was wir zu diesem
+Zeitpunkt noch nicht wussten, war, dass uns eine dieser drei "guten" Nachrichten
+zum Verhängnis werden würde.
+
+Zunächst mussten wir uns für eine Kompromisslösung entscheiden, wie wir die
+immerhin etwa 350 GiB Daten einigermaßen schnell wiederherstellen
+wollten. Dabei gab es einige Eckpunkte zu beachten:
+
+* Das letzte volle Backup des Clusters war fünf Tage alt. Alle Daten zwischen
+  dem 7. und dem 12. Juli mussten aus dem *Write Ahead Log* wiederhergestellt
+  werden.
+* Der Storage auf dem Datenbankserver war nach der Deaktivierung des Caches nun
+  noch langsamer als vorher
+* Der Backup-Server hat mittelmäßige Storage-Geschwindigkeiten, aber nur eine
+  Single-Core-CPU mit 2,1 GHz
+* Es stand, unabhängig von dem Restore, ein Upgrade von PostgreSQL 13 auf 16 an
+
+Letztendlich haben wir uns entschieden, folgendermaßen vorzugehen:
+
+1. Restore des Backups auf dem Backup-Server
+2. Initialisierung eines neuen PostgreSQL-16-Clusters auf dem
+   Datenbank-Server
+3. Übertragung der Daten als SQL-Dump in den neuen Cluster
+
+Das Restore des Datenbank-Clusters aus dem Write Ahead Log dauerte etwa 1½ Tage.
+Danach startete PostgreSQL erfolgreich und der Zugriff auf alle Datenbanken war
+mit aktuellem Stand möglich.
+
+## Inkonsistenzen im Backup und Reparatur
+
+Nachdem der Zugriff auf den Backup-Cluster hergestellt war, konnten wir mit dem
+Übertragen des SQL-Dumps beginnen. Das funktionierte zunächst erwartungsgemäß gut,
+mit einer erwarteten Dauer von etwa einem halben Tag.
+
+Leider brach der Prozess beim Übertragen der Datenbank von
+[Synapse](https://element-hq.github.io/synapse/latest/) ab, da auch hier
+korrupte Transaktions-Informationen vorlagen. Überraschenderweise
+zeigte sich im Backup ein ähnliches Fehlerbild wie auf dem Produktivsystem.
+
+An dieser Stelle wäre der sichere Weg gewesen, das Restore des Datenbank-Clusters
+zu wiederholen und dabei ein *Point-in-Time-Recovery* zu einem Punkt kurz vor dem
+Auftreten der ersten Dateisystemfehler zu machen. Das hätte die verfügbare Zeit für
+die Wiederherstellung jedoch massiv überschritten, da am Dienstag ein wichtiger
+Entwicklungs-Sprint des [AlekSIS](https://aleksis.org/de/)-Projekts beginnen sollte.
+
+Deshalb haben wir uns stattdessen entschlossen, die betroffenen Tabellen zu identifizieren
+und zu beurteilen, ob die Fehler vernachlässigbar sind. Tatsächlich waren dann auch
+nur zwei Tabellen betroffen – bei beiden handelte es sich um reine Caching-Tabellen,
+die Public Keys anderer Matrix-Server cachen. Diese Tabellen ließen wir dann leer, mit
+dem Wissen, dass Nachrichten von Matrix-Servern, die mittlerweile offline sind, dann
+nicht mehr verifiziert werden können. Diesen minimalen Verlust wollten wir in Kauf nehmen.
+
+Nachdem alle anderen Datenbanken und Tabellen wiederhergestellt waren, stellte sich
+jedoch heraus, dass es weitere Inkonsistenzen gab. Einigen Tabellen fehlten *Primary Keys*.
+Ursache war, dass das Anlegen der entsprechenden *Constraints* beim Einspielen des
+SQL-Dumps fehlgeschlagen war.
+
+Tabellen in relationalen Datenbanken können so genannte *Constraints* besitzen, die
+verschiedene Prüfungen über die Daten in der Tabelle erzwingen. Der wohl bekannteste
+Constraint ist der `UNIQUE`-Constraint, der verhindert, dass Daten doppelt eingefügt
+werden. Ein Spezialfall davon wiederum ist der *Primary Key*, der sicherstellt, dass
+eine Tabellenzeile eindeutig benannt werden kann.
+
+Beim Versuch, die fehlenden Primary Keys selber anzulegen, zeigte sich, dass die betroffenen
+Tabellen tatsächlich einige Daten doppelt enthielten. Betroffen waren dabei die Datenbanken
+von Syanpse und [Mastodon](https://joinmastodon.org/). Glücklicherweise stellten wir fest,
+dass alle betroffenen Tabellen in zwei Kategorien fielen:
+
+* Tabellen, deren Daten durch Föderation erneut befüllt werden können
+* Tabellen, deren Primary Key oder `UNIQUE`-Cosntraint eine global eindeutige ID
+  enthielt (z.B. die Matrix-Room-ID oder eine (Short)-UUID)
+
+Im zweiten Fall war daher klar, dass die doppelten Datensätze bei einem `INSERT OR UPDATE`
+oder einer vergleichbaren Operation entstanden sein mussten, weshalb der neuere Datensatz
+vorzuziehen war. In den Fällen, in denen kein Zeitstempel oder ähnliches vorhanden war,
+haben wir stattdessen die interne Tupel-ID von PostgreSQL (`ctid`) verwendet:
+
+```sql
+-- Zwei beispielhafte Lösch-Operationen
+DELETE FROM
+  receipts_linearized a USING receipts_linearized b
+  WHERE a.ctid < b.ctid
+  AND a.room_id = b.room_id
+  AND a.receipt_type = b.receipt_type
+  AND a.user_id=b.user_id;
+DELETE FROM sessions a USING sessions b WHERE a.ctid < b.ctid AND a.id = b.id;
+```
+
+Nachdem wir die Integrität der Tabellen so wiederhergestellt hatten, konnten wir durch ein
+erneutes Einspielen eines SQL-Dumps mit der `pg_dump`-Option `--schema-only` die zuvor
+fehlenden Contraints, Indexe und Keys anlegen und die Dienste problemlos starten.
+
+## Performance-Probleme nach dem Wiederanlauf
+
+Leider stellte sich insbesondere der Matrix-Server in der Folge als weitestgehend
+unbenutzbar heraus. Ein Blick auf den Datenbankserver zeigte, dass fast alle *Backend*-
+Prozesse für Synapse im `D`-Status waren, d.h. wahrscheinlich auf Datenträger warteten.
+Bei fast allen handelte es sich um `SELECT`-Statements, also um lesende Zugriffe auf die
+Datenbank. Da das System mit ausreichend Arbeitspeicher versehen ist und eigentlich
+weitestgehend aus den `shared_buffers` von PostgreSQL und aus dem VFS-Cache des
+Betriebssystems arbeiten sollte, war das überraschend. Es stellte sich dann heraus.
+
+Was die meisten als Chat-Plattform kennen, ist eigentlich eine große, veteilte *Graph-Datenbank*.
+Matrix-Räume sind eine Abfolge von Events, die jeder beteiligte Server in den Graphen des
+Raumes einfügen kann. Wenn verschiedene Server oder sogar Clients am selben Server
+sozusagen "zeitgleich" ein neues Event an derselben Stelle einfügen, ist der Graph, also
+die Abfolge der Events und Nachrichten, nicht mehr *linear*. Weil aber die meisten Clients,
+eben alle Chat-Anwendungen, eine einfache chronologische Abfolge der Nachrichten erwarten,
+muss der Graph *linearisiert* werden.
+
+![Linearisierung in Matrix](matrix-linearisierung.png)
+
+Diese komplexe Operation erledigt Synapse direkt in der Datenbank. Durch die lange
+Ausfallzeit und die Tatsache, dass einige unserer Benutzer\*innen in vielen, teils sehr
+großen und aktiven, Matrix-Räumen sind, wurden diese Operationen sehr umfangreich und
+mussten mit großen Datenmengen arbeiten.
+
+PostgreSQL stellt jeder Operation einer Abfrage eine vorgegebene Menge an Arbeitsspeicher
+zur Verfügung. Benötigt eine Operation, bspw. ein Sortier- oder ein Hashing-Algorithmus,
+mehr als diesen Speicher, muss er Daten in *temporäre Dateien* auslagern.
+
+Das passierte in unserem Fall nun ständig, was dem ohnehin langsamen Storage nicht zuträglich
+war. Nach entsprechender Auswertung stellten wir fest, dass Synapse für seine Auswertungen
+aktuell etwa 512 MiB Arbeitsspeicher benötigte. Dieser Wert wäre für alle anderen Anwendungen
+extrem hoch und könnte schnell zu Speicherproblemen führen. Praktischerweise kann PostgreSQL
+dieses Limit auch pro Datenbank setzen, so dass wir Clients der Synapse-Datenbank ein höheres
+`work_mem`-Limit zuweisen konnten:
+
+```sql
+ALTER DATABASE synapse SET work_mem TO '512 MB';
+```
+
+Danach war der Matrix-Server problemlos nutzbar under Rückstand schnell abgearbeitet.
+
+## Verlust des Kerberos-Master-Keys
+
+Schon vor langer Zeit haben wir unsere Systeme und Plattformen auf das *Single-Sign-On*-
+System [OpenID Connect](https://openid.net/developers/how-connect-works/) umgestellt.
+Zwei Systeme benutzten jedoch weiterhin LDAP und Kerberos:
+
+* Unser Ticket-Sytem Zammad
+* Der [XMPP](https://xmpp.org/)-Server ejabberd
+
+Außerdem hatte unsere aktuelle SSO-Plattform *TIC-Desk* noch ein Fallback auf das alte
+System fur Benutzer\*innen, die ihr Passwort noch nicht im neuen System gesetzt hatten.
+
+Da diese Übergangslösung eigentlich abgeschafft werden sollte, hatten wir LDAP und
+Kerberos beim Backup schon länger nicht mehr berücksichtigt. Leider bedeutet das, dass
+wir durch die Dateisystemprobleme den *Master Key*, der die Daten in der Kerberos-Datenbank
+verschlüsselt, verloren haben. Damit war kein Login mehr in Jabber und Zammad möglich.
+
+Nach einigen Überlegungen haben wir uns entschlossen, das alte System aus diesem Anlass
+nun endgültig abzuschaffen und mit den daraus folgenden Konsequenzen zu leben:
+
+* Zammad benötigt vorübergehend lokale Passwörter, bis die Entwickler OIDC einführen
+* Der XMPP-Server ist vorübergehend offline und wird bei Gelegenheit zu Prosody migriert
+* Die Benutzer\*innen, die in TIC-Desk noch kein Passwort gesetzt hatten, benötigen
+  einen manuellen Passwort-Reset durch uns
+
+## Ursachenanalyse und Lessons learnt
+
+Ursächlich war letztendlich, dass das Entfernen eines Caching-Tiers aus Ceph nicht
+online möglich ist, wenn man Ceph für Block-Devices (RBD) benutzt.
+Das ist [nicht komplett unbekannt](https://www.mail-archive.com/ceph-users@lists.ceph.com/msg42350.html),
+aber auch nicht offensichtlich dokumentiert. Beim Entfernen des Caches wurden
+kurzzeitig im Zugriff befindliche Blöcke der Dateisysteme mit ungültigen oder
+veralteten Daten ausgeliefert.
+
+Bei dem Backup-Mechanismus, den wir für PostgreSQL verwenden (Streaming-Backup zu
+[Barman](https://pgbarman.org/)) wird das *Write Ahead Log* direkt an den Backup-Server
+übertragen. Dies erfolgt aus den *WAL-Buffern* im Arbeitsspeicher oder aber aus den
+WAL-Dateien auf dem Datenträger, falls die Übertragung länger dauert. Durch die insgesamt
+hohe Schreiblast auf unseren Datenbanken wurden WAL-Daten vom Datenträger ins Backup
+übertragen, wodurch auch korrupte Daten übetragen wurden.
+
+Die duplizierten Daten resultierten daraus, dass durch korrupte Transaktions-Daten nun
+eigentlich gelöschte Daten wieder sichtbar wurden (anhand des obigen, vereinfachten
+Bildes kann man sich gut vorstellen, wie eine Tabelle aussieht, wenn die beiden
+Transaktionen A und B übereinandergelegt werden statt in eine kohärente Reihenfolge
+gebracht zu werden).
+
+Durch den Ausfall und die Behebung haben wir viele Dinge gelernt, nicht zuletzt
+auch über die Struktur und Interna der von uns betriebenen Anwendungen.
+
+Insbesondere seien aber folgende Punkte hervorzuheben:
+
+* Das *Cache-Tiering* in Ceph ist instabil. Da es auch nur in seltenen Fällen wirklich
+  Performance-Vorteile bringt, sollte es vermieden werden. Eine gute Alternative, um
+  Storage aus mechanischen Festplatten zu beschleunigen, ist es, das WAL der *Bluestore*-
+  Datenbank auf SSDs auszulagern.
+* Im Falle auftretender Dateisystem-Korruptionen sollten die Grundsätze der IT-Forensik
+  angewendet werden und sofort in einen Read-Only-Modus gewechselt werden. Auch Backup-
+  Prozesse sollten sofort angehalten werden.
+* *ext4* ist kein robustes Dateisystem, was Datenintegrität angeht. Auch `fsck` findet
+  eklatante Probleme nicht und kann ein de facto vollständig unbrauchbares Dateisystem
+  als sauber betrachten. Mittlerweile sollten moderne Dateisyteme wie *btrfs*, deren
+  Architektur bereits Datenintegrität im Kern enthält, eine ernsthafte Alternative sein
+* Beim Recovery von PostgreSQL aus WAL-Archiven sollte direkt beachtet werden, korrupte
+  Segmente, die nach einem Katastrophenfall angefallen sind, nicht mit zu recovern
+* Es sollte einen dokumentierten Mechanismus geben, um Kernkomponenten wie das SSO unabhängig
+  von anderen Diensten zu starten
+
+Zum Vorgehen unserer Datenbank-Restoration möchten wir außerdem anmerken, dass die von
+uns ausgeführten manuellen Reparaturarbeiten eine gute Kenntnis der entsprechenden Anwendung
+erfordern. Die Gefahr von weiterem Datenverlust ist hoch.
+
+Einige Entscheidungen, die wir gezielt für unsere Infrastruktur getroffen hatten, haben
+sich aber auch als sehr hilfreich und weitsichtig herausgestellt:
+
+* Alle Anwendungen haben ihre Nutzdaten ausschließlich im PostgreSQL-Cluster sowie
+  entweder in einem *CephFS*-Volume oder im *S3-Object-Storage*. Dadurch waren keine
+  Nutzdaten auerhalb von PostgreSQL betroffen.
+* Backups werden zwar (noch) im selben Rack, jedoch auf vollständig getrennte Hardware
+  und auf einfachen Storage gemacht. So stellen Komplexitäten wie die von Ceph keine
+  Risiken für das Backup dar.
+
+## Weitere Tätigkeiten und Aussicht nach dem Ausfall
+
+Nachdem der Ausfall weitestgehend behoben war, konnten wir den Ausbau des Storages
+erfolgreich fortführen. Mittlerweile sind alle Festplatten durch SSDs ersetzt und
+das Ceph gelangt nahe an die Grenze der *SATA-Link-Saturation*, also die Auslastung
+des SATA-Buses, an dem die Datenträger selber angeschlossen sind.
+
+Desweiteren haben wir die Gelgenheit genutzt, weitere Optimierungen vorzunehmen:
+
+* Deinstallation von `rsyslog` auf allen Debian-VMs, so dass nur noch ein Logging-
+  System (`systemd-journald`) Logs schreibt
+* Überprüfung der PostgreSQL-Konfiguration und Anpassung einiger Parameter an neue
+  Messungen und Erfahrungswerte
+* Aktivirung eines regelmäßigen `fstrim` auf den VMs, so dass Ceph nachhalten kann,
+  welche Blöcke (Objekte) unbenutzt sind und diese bei Maintenance-Operationen nicht
+  berücksichtigen muss
+
+Als nächstes stehen noch einige Tätigkeiten aus:
+
+* Verbesserung der Verteilung von Datenträgern und OSDs auf die Server
+* ~~Migration von ejabberd zu Prosody und Reaktivierung des XMPP-Servers~~
+* Aktives Anschreiben der vom Passwort-Reset betroffenen Benutzer\*innen
+
+**Update:** Mit Hilfe eines von uns entwickelten
+[extauth-Skripts für ejabberd](https://codeberg.org/Natureshadow/ejabberd-extauth-oidc-password)
+konnten wir ejabberd nun zum OIDC-Login migrieren.