Warum dieses Follow-up jetzt fällig ist

Wer die bisherigen Artikel zu NetBSD Jails und später NetBSD Cells gelesen hat, kennt die Geschichte: Der Kernansatz stand früh, die echte Arbeit begann aber danach - in den Details von Betrieb, Reproduzierbarkeit und robuster Alltagstauglichkeit.

Ich schreibe diesen Bericht bewusst in einer journalistischen Perspektive auf das eigene Projekt: nicht als Werbetext, sondern als Lagebild. Gleichzeitig ist er das Follow-up zu allen bisherigen Artikeln rund um NetBSD Jails und NetBSD Cells. Was ist inzwischen tragfähig? Wo sind die Grenzen? Und was hat sich gegenüber den früheren Updates substanziell verändert?

Vom Prototyp zur durchgängigen Betriebslogik

Der größte Unterschied zum frühen Stand ist nicht ein einzelnes Feature, sondern die klare Systemlogik über alle Ebenen hinweg:

• secmodel_cell im Kernel erzwingt Identität, Isolation und Policy-Durchsetzung.
• cellctl bleibt die direkte Runtime-nahe Schicht für create/destroy/exec plus Snapshot-Metriken.
• cellmgr ist heute die einheitliche Control Plane für gewünschten Zustand, Runtime-Zustand, Reconcile (apply) sowie Backup/Restore.

Damit hat das Projekt eine Form erreicht, die ich intern als den eigentlichen Wendepunkt sehe: nicht mehr nur “Isolation funktioniert”, sondern “Isolation ist nachvollziehbar betreibbar”.

Was heute belastbar funktioniert

Aktuell ist Cells for NetBSD als frühe, aber klar strukturierte Pre-Release-Plattform nutzbar.

Technisch relevant sind dabei vor allem diese Punkte:

• Einheitliches Zustandsmodell: desired, runtime und both sind durchgängig als Scope im Tooling verankert.
• Reconcile statt Handarbeit: cellmgr apply bringt Hosts reproduzierbar in den gewünschten Zustand, inklusive Healthchecks und Drift-Erkennung.
• Storage als First-Class-Thema: Volumes und Overlay-Zustände können getrennt gesichert und wiederhergestellt werden.
• Stabile Read-Verträge: TSV-Ausgaben mit festen Feldnamen und klarer Schema-Validierung machen Automatisierung realistischer.
• Host-zentrierter Betrieb: kein zweiter virtueller Netzwerk-Stack, keine zusätzliche Runtime-Schicht, keine versteckten Daemons zwischen Operator und Prozess.

Das ist genau die Richtung, die ich von Anfang an wollte: eine NetBSD-native Isolation, die nicht wie ein importiertes Ökosystem wirkt, sondern wie ein logisch integrierter Teil des Systems.

Was weiterhin bewusst offen bleibt

So klar muss der Realitätscheck ebenfalls sein: Das Projekt bleibt experimentell und ist nicht sicherheitsauditiert.

Auch wenn die Architektur inzwischen deutlich konsistenter ist, gilt weiterhin:

• keine offizielle NetBSD-Release-Komponente
• kein formales Upstream-Review der gesamten Implementierung
• laufende Schärfung von Schnittstellen und Betriebsverhalten

Ich halte diese Offenheit für zentral. Gerade bei Kernel-naher Isolation gewinnt man Vertrauen nicht durch große Claims, sondern durch saubere Grenzen, reproduzierbare Ergebnisse und transparente Dokumentation.

Dokumentation: im Aufbau, mit klarer Einordnung

Parallel zur technischen Entwicklung entsteht inzwischen auch eine eigene Doku unter:

https://netbsd-cells.petermann-digital.de/docs/

Wichtig ist mir dabei die ehrliche Einordnung: Ein großer Teil der Inhalte ist aktuell aus meiner Cell-Spec generiertes KI-Material. Das hilft, schnell Struktur und Breite aufzubauen, ersetzt aber noch keinen finalen redaktionellen Qualitätsanspruch in allen Teilen.

Die Ausnahme sind die Manpages - dort liegt der Anspruch bereits deutlich höher, weil sie direkt im operativen Alltag verwendet werden.

Eine kleine Kostprobe:

Praxistauglichkeit: reale Ziel-Stacks mit Alltagsbezug

Für die Praxistauglichkeit setze ich bewusst auf konkrete Stacks, die nicht nur als Showcase taugen, sondern im Alltag als echte Testbasis laufen.

Zwei Szenarien sind inzwischen recht ausgereift und werden kontinuierlich verwendet:

• MantisBT-Stack: PostgreSQL-Datenbank, php_fpm und nginx als Reverse Proxy.
• Luanti-Server: dieses Setup hat einen sehr persönlichen Ursprung - mein Sohn hat sich einen eigenen Luanti-Server gewünscht. Genau deshalb ist es ein guter Realitätscheck: Wenn es im Familienalltag stabil laufen soll, müssen Bedienung und Betrieb wirklich passen.

Und wichtig: Auf der DVD liegen nicht nur MantisBT-Beispiele. Unter

/usr/share/examples/cellmgr

finden sich die Manifeste für MantisBT und Luanti sowie weitere Beispielkonfigurationen zum direkten Ausprobieren.

Begleitende Rezepte in der Doku:

• https://netbsd-cells.petermann-digital.de/docs/end-to-end-recipes/mantisbt-end-to-end-example/index.html
• https://netbsd-cells.petermann-digital.de/docs/end-to-end-recipes/luanti-gameserver-end-to-end-example/index.html

cellui: die neue operative TUI-Ebene

Ein Punkt, der in Gesprächen zuletzt immer wieder positiv aufkam: Mit cellui gibt es jetzt eine echte interaktive TUI auf dem cellmgr-Datenmodell.

Praktisch bedeutet das:

• schneller Überblick über Cells, Storage, Backups und Laufzeitstatus
• weniger Routine-Tippen für Standardaktionen
• weiter volle Transparenz, weil die UI auf denselben klaren CLI-Verträgen basiert
• und ja: eine kuratierte Theme-Sammlung, die den NetBSD-Alltag auf Wunsch auch visuell Richtung 80er drehen kann

Die folgenden Screenshots zeigen genau diesen Stand:

Fazit

Wenn ich den Ist-Stand heute in einem Satz zusammenfassen soll, dann so: Cells for NetBSD hat die Prototyp-Phase technisch noch nicht vollständig verlassen, aber die Architektur hat die Bastelphase klar hinter sich.

Der Stack ist inzwischen end-to-end erkennbar: Kernel-Enforcement, reproduzierbare Operator-Workflows, deklarative Konvergenz und mit cellui eine Bedienebene, die das Projekt auch für längere Betriebsszenarien deutlich zugänglicher macht.

Die nächste Etappe bleibt dieselbe wie bisher - weiter härten, weiter messen, weiter dokumentieren. Aber diesmal auf einem deutlich stabileren Fundament als noch in den ersten Jail-Updates.