Letztes Wochenende habe ich auf einem System Knot Resolver ausgerollt. Meine Absicht war es, einen dnsmasq zu ersetzen, um DNS over TLS (DoT) zu implementieren. dnsmasq hatte in meinem Setup mehrere Funktionen: dnsmasq überschieb bestimmte Adressen, blockierte Werbung und leitete bestimmte Zonen an andere DNS-Server weiter. Knot Resolver sollte all diese Aufgaben übernehmen.
Wenn man an nixpkgs arbeitet oder einen Pull Request testet, möchte man oft nicht einfach auf den Master-Branch wechseln, nur um die Änderungen aus diesem PR zu testen. Stattdessen ist es oft sinnvoller, die notwendigen Commits direkt in die eigene Version von nixpkgs zu übernehmen. So kann man spezifische Änderungen testen, ohne die gesamte Umgebung auf den neuesten Stand zu bringen. Besonders praktisch ist das, wenn man mit einer stabilen Version von nixpkgs arbeitet, etwa einem Release-Branch, und nur gezielt bestimmte Commits aus einem PR übernehmen möchte.
Mein Weg zu NixOS war keine spontane Entscheidung, sondern das Ergebnis jahrelanger Erfahrungen mit verschiedenen Linux-Distributionen. Ich habe früh angefangen, alternative Betriebssysteme auszuprobieren, und hatte immer den Anspruch, mein System möglichst effizient, stabil und flexibel zu gestalten. Doch erst mit NixOS habe ich eine Lösung gefunden, die meine Anforderungen wirklich erfüllt.
Dieser Artikel entstand, weil ein Bekannter mich bat, ihm zu zeigen, wie man eine Software
für Nix paketiert und in github.com/nixos/nixpkgs integriert.
Konkret ging es um das Paket alertmanager-gotify-bridge, das eine Brücke zwischen dem Prometheus
Alertmanager und Gotify bildet. Ziel war es, nicht nur das Paket zu erstellen, sondern auch den
gesamten Prozess zu verstehen, um es später selbstständig in das offizielle nixpkgs-Repository
einzubringen. Um diesen Ablauf für andere nachvollziehbar zu machen, entschied ich mich, ihn
umfassend zu dokumentieren.