Ein weiteres Update - 1,5 Monate später

Seit dem letzten Artikel Cells for NetBSD: Der aktuelle Ist-Stand im Frühjahr 2026 ist erneut einiges passiert. Das Projekt bleibt zwar klar im experimentellen Bereich, aber die Richtung wird technischer und konsistenter.

Der wichtigste Punkt in diesem Update ist die neue dritte Generation der Control Plane: cellman ersetzt cellmgr als neue technische Basis.

Architektur: vom Kernel bis zur Control Plane

Bevor wir in die Details gehen, hier der Gesamtblick auf den aktuellen Stack:

Im Diagramm sind die zentralen Bausteine der dritten Generation zu sehen:

• secmodel_cell: Kernel-Komponente für Isolation, Autorisierung und Telemetrie-Zähler.
• cellctl: Runtime-nahe Primitive für create/destroy/exec und die Supervision laufender Dienste.
• libcellman: gemeinsamer Control-Plane-Kern mit typisierten Datenmodellen und Apply-Logik.
• cellman: CLI auf Basis von libcellman für deklarative Steuerung, Reconcile und Backup/Restore.
• cellui: TUI auf derselben Library-Basis; kein textbasiertes IPC zur CLI mehr, sondern direkter Library-Zugriff.
• Zustandsdomänen: gewünschter Zustand als Specs unter /etc/cellman/*.lua, materialisierter Laufzeitzustand unter /var/cellman/*, konsistente Read-Views über cellman.

Die Zustandsdefinitionen in /etc/cellman/*.lua sind damit die fachlichen Specs: Sie beschreiben den Soll-Zustand, gegen den cellman Drift prüft und auf den das System konvergiert.

Gerade cellctl hat im Betrieb eine wichtige Doppelrolle: Es startet nicht nur Cells, sondern übernimmt auch die Supervision der Workloads (typisch als eigene Instanz pro Cell). Die Service-Logs werden in den Host-Syslog abgeführt und können dadurch im zentralen syslogd des Systems gesammelt, gefiltert und weiterverarbeitet werden.

Zusätzlich kann cellctl Prometheus-kompatible Metriken für Cells exportieren. Über cellctl stats -P -h lässt sich ein HTTP-kompatibler Metrik-Output bereitstellen, der z. B. über inetd als schlanker Endpoint veröffentlicht werden kann.

Der strukturelle Wechsel ist dabei klar: cellman ersetzt cellmgr als Control-Plane-Implementierung.

cellman ersetzt cellmgr

Der bisherige cellmgr (Shell-Skript) wird durch cellman ersetzt.

cellman ist keine kleine Evolution, sondern eine komplette Neuimplementierung in C. Das ist ein tiefer Schnitt in der Architektur - und genau deshalb ein so wichtiges Update.

Warum C und nicht Go oder Rust? Der Hauptgrund ist Portabilität im NetBSD-Kontext:

• C ist im NetBSD-Basissystem vorhanden
• C-Toolchain und Laufzeit sind für alle von NetBSD unterstützten Architekturen verfügbar
• Go und Rust funktionieren in der Praxis nur auf einer Teilmenge der Plattformen

Cells soll vom kleinsten SoC bis zum leistungsstarken Cluster gleichartig funktionieren. Die Wahl von C reduziert hier systemische Reibung und hält den operativen Unterbau auf allen Zielplattformen konsistent.

Durch den Umbau auf cellman ergeben sich mehrere direkte Vorteile:

• Mehr Performance: weniger Shell-Overhead, direktere Ausführung
• Mehr Typensicherheit: weniger implizite String-Logik, weniger Fehlerklassen
• Geteilte Bibliothek: eine gemeinsame Codebasis für CLI und TUI
• Klarere Wartbarkeit: konsistentere Schnittstellen zwischen Komponenten

Lua als DSL statt YAML

Eine der interessantesten Änderungen ist die Konfigurationsseite: cellman setzt auf Lua als Domain-Specific Language (DSL).

Das fühlt sich in vielen Bereichen ähnlich angenehm an wie HCL - vor allem, wenn Konfiguration nicht nur “Daten” ist, sondern auch klar strukturiert und lesbar bleiben soll.

Im Betrieb ist das ein Plus: weniger YAML-Sonderfälle, dafür eine konzeptionell klarere und oft besser nachvollziehbare Schreibweise.

Warum Lua? Neben den praktischen Vorteilen gegenüber YAML war ein Infrastrukturpunkt entscheidend: Die Lua-Bibliothek ist bereits im NetBSD-Basissystem vorhanden. Es kommen also keine neuen Build- oder Runtime-Abhängigkeiten hinzu, und das Gesamtsystem bleibt schlank und sauber.

Konkret funktioniert das im Alltag so:

• Gewünschter Zustand liegt als Lua-Dateien unter /etc/cellman/*.lua
• Laufzeitzustand wird unter /var/cellman/* materialisiert
• cellman apply --dry-run --all zeigt Drift vor der Änderung
• cellman apply --all konvergiert Volumes, Cells und Apply-Aktionen

Ein funktionierendes Beispiel aus dem aktuellen Workflow:

/etc/cellman/01-volume-demo-data.lua

volume("demo-data", {
  mode = "0755",
})

/etc/cellman/02-cell-demo-web.lua

cell("demo-web", {
  autostart = true,
  create = {
    profile = "medium",
    reserved_ports = "8080",
  },
  supervise = {
    cmd = "/usr/libexec/httpd -I 8080 -X -f -s /var/www/demo-web",
  },
  mounts = {
    volume("demo-data", { target = "/var/www/demo-web", mode = "rw" }),
  },
  healthcheck = "test -f /var/www/demo-web/index.html",
})

/etc/cellman/03-apply-demo-web.lua

apply("demo-web", {
  dir("/var/www/demo-web", { mode = "0755" }),
  file("/var/www/demo-web/index.html", "<html><body>Hello from Cells</body></html>\n", {
    mode = "0644",
  }),
})

Was Cells for NetBSD weiterhin adressiert

Die Grundrichtung bleibt unverändert: kein Docker-Klon, sondern ein pragmatischer, NetBSD-nativer Isolationsansatz.

Konkret schließt das Projekt weiterhin genau die Lücke, die NetBSD-Nutzer lange hatten:

• Kernel-nahe Prozessisolation über ein Security-Modul
• grundlegende Ressourcensteuerung via rlimits (ohne cgroups-Nachbau)
• Monitoring und zentrale Protokollierung
• Lifecycle-Management inklusive Backoff-Strategien
• native Orchestrierungslogik im NetBSD-Kontext

Warum es NeoBSD als Build-Pfad gibt

Cells for NetBSD ist weiterhin ein hochgradig experimentelles Projekt. Kurzfristig ist eine Aufnahme in den offiziellen NetBSD-Baum nicht realistisch, und der Zeitpunkt für einen formalen Vorschlag ist aus meiner Sicht noch nicht erreicht.

Für Entwicklung und Tests brauchte ich trotzdem einen stabilen, reproduzierbaren Weg, regelmäßig installierbare Images mit Cells-Integration zu bauen - sowohl für meine eigenen Regressionstests als auch für Leute, die den Stand selbst ausprobieren möchten.

Darauf basiert NeoBSD:

• ein kleines CI/CD-Skriptframework
• vollständig nachvollziehbare Builds aus einer Patch-Sammlung
• feste Commit-Stände des NetBSD-Git-Mirrors als Basis
• reproduzierbare Release-Artefakte für Tests und Evaluation

Technische Basis und Build-Repository:

https://github.com/MatthiasPetermann/neobsd

Der Name NeoBSD steht für genau diese Rolle: auf dem soliden NetBSD-Fundament aufbauen und experimentelle Konzepte transparent und reproduzierbar erproben.

Fazit

Dieses Update ist mehr als nur ein Versionssprung: Mit cellman wird die Betriebsseite von Cells for NetBSD strukturell neu aufgestellt.

Die Umstellung von Shell auf C, die gemeinsame Bibliothek für CLI/TUI und die Lua-DSL zeigen, dass der Fokus nicht nur auf “Isolation funktioniert”, sondern zunehmend auf robustem, nachvollziehbarem Betrieb liegt.

Wenn dich NetBSD interessiert, dir aber bislang ein praktikabler Isolations- und Orchestrierungsansatz gefehlt hat, ist jetzt ein sehr guter Zeitpunkt für einen neuen Blick.