rostr

Problem

Server-Wissen lebt an drei Orten gleichzeitig: in der SSH-Config, im Ansible-Inventory und im Kopf. Jede der drei Kopien verrottet in ihrem eigenen Tempo. Nach dem dritten Server stimmt keine mehr mit den anderen überein — und die Frage „was läuft eigentlich wo?“ hat keine verlässliche Antwort mehr.

Ansatz

rostr dreht das um: eine hosts.yaml ist die einzige Quelle der Wahrheit, alles andere wird generiert. SSH-Config, Ansible-Inventories, ein Fuzzy-Host-Targeting (rostr ssh web findet den richtigen Host) und parallele OS-Audits über alle Maschinen. Dazu kommen die Playbooks, mit denen die eigene Infrastruktur provisioniert wird — der komplette Rebuild des Dedicated Servers im Juni 2026 lief aus genau diesem Repo.

Entscheidungen

• Jede Schicht bleibt ohne rostr benutzbar. Die generierten Artefakte sind Standard-Dateien: die SSH-Config funktioniert ohne das Tool, die Inventories sind normales Ansible. Fällt rostr weg, fällt nichts aus.
• Fork statt Neubau, ehrlich gelabelt. rostr ist ein stark erweiterter Fork eines bestehenden Projekts — 71 von 89 Commits stammen von mir. Aufgesetzt statt neu erfunden, und genau so ausgewiesen.
• Secrets nie im Klartext. Verschlüsselte Secrets im Repo, Schlüssel im Agenten — nicht in Dateien.

Status & Learnings

v1.0.0, MIT, im täglichen Einsatz als privates Infrastruktur-Kontroll-Repo. Das eigentliche Learning: Inventar-Drift ist kein Disziplinproblem, sondern ein Architekturproblem. Eine Quelle der Wahrheit, aus der generiert wird, schlägt jede noch so gute Absicht, drei Kopien synchron zu halten.