Von Puppet zu OpenVox, von Bookworm zu Trixie
Warum die Flotte erst auf Debian 13 konnte, als Foreman 5.0 da war, wie der Wechsel von Puppet zu OpenVox lief und was beim Upgrade der ganzen Flotte an den Puppet-Modulen hing.
Die gesamte Umgebung entsteht aus Code: ein Control-Repo mit r10k, die Daten in Hiera, rund zwei Dutzend eigene Module, Foreman als Verzeichnis der Maschinen. Angefangen hat das am 3. Oktober 2025 mit dem Basismodul für alle Hosts. Ein Jahr später laufen Agent und Server auf OpenVox, Foreman auf 5.0 und die ganze Flotte auf Debian 13.
Warum Debian 13 warten musste
Debian 13 Trixie erschien im August 2025. Für die meisten Dienste wäre ein Upgrade früh möglich gewesen — nur nicht für den Kern: Foreman lieferte Pakete für Trixie erst mit Version 5.0. Die 3er-Reihe gab es nur für Debian 12. Solange Foreman und sein Proxy auf Bookworm bleiben mussten, war ein Upgrade der übrigen Maschinen eine halbe Sache.
Der Weg dorthin war deshalb eine Kette von Foreman-Updates, alle über den eigenen Paketspiegel:
| Datum | Stand |
|---|---|
| Oktober 2025 | Foreman 3.15 |
| 17.02.2026 | 3.17 |
| 12.03.2026 | 3.18 |
| 31.08.2026 | 3.19 |
| 09.10.2026 | 5.0 |
Die alten Versionen bleiben im Spiegel liegen — als Rückweg, nicht als Einladung.
Puppet wird OpenVox
Nachdem Perforce die Puppet-Pakete nicht mehr frei bereitstellt, führt die Community die Entwicklung als OpenVox weiter. Am 31. August habe ich die Flotte umgestellt:
- Die Quelle zuerst. Eine neue Paketquelle für OpenVox, gespiegelt wie alle anderen.
- Den Server von Hand. Erst
puppet00, ohne Puppet — und prüfen, ob Spiegel, Signatur und Pakete stimmen. Ein Server, der sich selbst kaputt verwaltet, ist schwer zu reparieren. - Dann die Agents über Puppet. Das Basismodul installiert
openvox-agentstattpuppet-agent. Das neue Paket ersetzt das alte über Conflicts/Replaces von selbst; ein ausdrückliches Entfernen braucht es nicht. Nur das alte Release-Paket wird gezielt gelöscht. - Aufräumen getrennt. Die Entfernung der alten Quellen blieb ein eigener, zunächst nicht übernommener Schritt — als Rückweg, falls etwas klemmt.
Der Dienst heißt weiter puppet, und danach lieferten alle Hosts wieder ihre Reports an den neuen Server. Eine Falle gab es doch: r10k musste nach dem Tausch neu installiert werden, weil das neue Paket sein Ruby an anderer Stelle mitbringt.
Debian 13 in den Modulen
Vorbereitet war das Upgrade seit dem 1. September. Jedes eigene Modul bekam getrennte Vorlagen für Debian 12 und 13 und eine eigene Hiera-Ebene für Trixie. Die Ebene ist nicht Zierde: Fehlt sie, fällt Hiera still auf die nächstallgemeine Ebene zurück, und ein Host bekommt die Einstellungen für die falsche Debian-Version — ohne Fehlermeldung.
Am 9. Oktober, direkt nach Foreman 5.0, folgten die Maschinen. An Puppet hing dabei mehr, als der Wechsel einer Paketquelle vermuten lässt:
- PostgreSQL 15 → 17 auf dem Puppet-Datenbankserver und dem Bareos-Katalog. Der Name der systemd-Einheit enthält die Version — jede Prüfung, die
postgresql@15-mainbeobachtete, musste mit. - PHP 8.2 → 8.4 auch für die Weboberfläche von Bareos. Nach dem Upgrade zeigte Apache noch auf den Socket von PHP 8.2, der nicht mehr existierte.
- BIND auf dem primären Nameserver: eigene Vorlagen für Trixie.
named-checkconfliegt dort unter/usr/binstatt/usr/sbin— ein fester Pfad im Modul scheiterte daran schon im September. - GitLab und Docker kommen aus Quellen, die je Debian-Version getrennt gespiegelt werden. Der Pfad in der Paketquelle wechselte mit.
- Der Spiegel selbst bekam neue Namen für die Quellen, die es jetzt in zwei Fassungen gibt.
Der Proxmox-Host lief schon seit dem 2. September auf Proxmox VE 9, das selbst auf Trixie aufsetzt.
Was vorher passiert ist
Ein Upgrade dieser Art geht nur ruhig, wenn die Module vorher aufgeräumt sind. Ein paar Beispiele aus den Wochen davor:
- PHP-FPM wurde am 14. September von reload auf restart umgestellt. Ein Reload liest die Konfiguration neu, legt den Socket aber nicht neu an — geänderte Zugriffsrechte am Socket blieben damit wirkungslos.
- Alle Webspaces auf PHP 8.4, die Pools für 8.2 und 8.3 abgebaut — vorher geprüft, dass nichts mehr daran hing.
- Scanner-Anfragen auf bekannte Angriffspfade beantwortet Apache seit dem 15. September mit 403, bevor PHP überhaupt startet. Anlass: Auf einer der gehosteten Seiten liefen an einem Tag gut drei Viertel aller Anfragen ins Leere, fast alle von einer Handvoll Cloud-Adressen.
- Das Mail-Relay hatte einen Schalter für TLS, der nichts schaltete — die Vorlage setzte den Wert fest. Seit dem 12. Oktober wirkt er.
Was ich daraus mitnehme
- Die Abhängigkeit, die alles aufhält, früh benennen. Hier war es Foreman. Alles andere ließ sich vorbereiten, während darauf gewartet wurde.
- Zwei Vorlagen statt Bedingungen in einer. Getrennte Dateien je Debian-Version sind mehr Text, aber man sieht auf einen Blick, was wo gilt — und kann die alte Fassung eines Tages einfach löschen.
- Erst
--noop, dann der echte Lauf. Viele Funde stehen so zuerst in einem Testlauf und nicht in einem Ausfall.