mastodon 4.7.3Three ways to look at the same machine - at the same time: a BIOS VGA console, a 256-color xterm, and a responsive web UI - all connected to the same cell and backup management backend.Which one would you pick?
https://netbsd-cells.petermann-digital.de
#netbsd #modernretrocomputing #freebsd #openbsd #dragonflybsd
Small fix, big impact 🔧
Initial situation: The network card in my parents’ mini server (NUC5PHY, RealTek 8168/8111) wasn’t properly entering Wake-on-LAN mode during shutdown. The server powers down automatically after inactivity and is woken up on demand via cron (every 1 min) from their laptops. Without WoL, it just stays off → manual power-on required.
Solution: A patch for the NetBSD PCI network driver to hook it into the power management framework. On shutdown, the NIC is now correctly configured for WoL.
First tests: works as expected ✅
#NetBSD #WoL #homelab #lowtech #pragmatic
Commit: https://github.com/MatthiasPetermann/netbsd-src/commit/4e3ee0370c3a9811f841e826ebf332639404209e
Since the last article, the secmodel_jail / jailctl / jailmgr stack has moved closer to a coherent whole. The original guardrails remain unchanged: no modifications to existing kernel paths, no UVM hooks, no NPF integration, no hidden coupling. The scope stays explicit and the risk bounded.
Progress has focused on operations. Logging, lightweight supervision, and basic metrics are in place, shifting the question from "can this work?" to "can this be run?". Networking remains intentionally simple and host-based; for hard isolation, Xen is still the right boundary. Jails provide an operational frame inside the host, not a replacement for virtualization.
Resource budgeting is being prototyped again via the secmodel evaluation interface, touching allocation paths and scheduler run queues in a minimally invasive way, but it needs careful review.
There is now also a small landing page to make the ideas visible, including an experimental amd64 ISO based on NetBSD 10.1 for testing. If it sparks upstream interest or discussion around lightweight, explicit isolation on NetBSD, that is already a win.
New checkpoint of the NetBSD jails prototype. Clean rebase on NetBSD 11 with no changes to existing upstream code except a bugfix. Also a new evaluation ISO based on NetBSD 11 RC1 (2026-03-05). Next experiments will explore non-user rlimits in the jail context and additional kauth gates (e.g. maxproc at fork).
Pushing Cells for NetBSD even further... cellmgr becoming a scriptable reconcilation engine with full lifecycle management including backup/restore, with cellui as the go-to TUI for midnight commander enthusiasts. And why stop there, when you could have a PAM authenticated web UI with feature-parity as well?
Today, NetBSD 11 RC3 has been released. To mark the occasion, I’ve updated my sources and published two ready-made images that include my Cells patch, bringing container/jail-like isolation to NetBSD.
You can try them here: https://netbsd-cells.petermann-digital.de/
A small update on NetBSD Cells 🙂
I’ve spent some time recently polishing things up and have updated the project page. I also built a new evaluation DVD image so it’s easier to try the current state of the project.
It now includes a few of the things I’ve been working on lately, like the reconcile engine in cellmgr, some early volume and backup management, and cellui for interactive administration.
If you’re curious about where the project currently stands, I wrote a short status report here:
https://www.petermann-digital.de/en/blog/netbsd-cells-status-report-2026q1/
Project page and download:
https://netbsd-cells.petermann-digital.de/
Feedback, thoughts, and questions are always very welcome.
Cells for NetBSD... Lightning Talk without the Talk ;-)
"Can you show what Cells for NetBSD actually does?"
Sure.
Fresh NetBSD install, deploy a Luanti server from a manifest, backup, restore, inspect processes inside the cell, then nuke everything again.
My personal record is <4 minutes.
The video is slower because OBS + VM + music nearly killed my laptop.
The third gen of Cells for NetBSD comes with a pretty major control plane redesign - enough to rename it: Cellman replaces the old cellmgr, now rewritten in C instead of shell. That brings better performance, real type safety, a shared lib for CLI/TUI, and a Lua-based config (honestly, much nicer than YAML, a bit HCL-ish). Still niche, sure - but if you like small, portable systems or bounced off NetBSD before because isolation was missing, this might be interesting. Cells tries to fill that gap with a pragmatic, native approach: kernel-level isolation, rlimit-based resource control, logging/monitoring, lifecycle handling, simple orchestration. Not “Docker for NetBSD”, more like “what fits NetBSD best?”. There are ready-to-use images (amd64/armv7) if you want to poke at it — curious if others were looking for something similar.
I’ve been following the discussions about the name of my NetBSD project ("Jails for NetBSD") across a few platforms over the past days and really appreciate the thoughtful feedback.
The short version: the current prototype is probably closer to a cell or a cage than a strict jail, so the name might indeed not be perfect. The project originally started as an experiment inspired by FreeBSD jails, but while exploring NetBSD internals it evolved into something slightly different: controlled process isolation built around the secmodel framework, a different approach for the tool chain and configuration, and without resource limits and network virtualization.
Because of that, I’m open to renaming the project at this stage.
I’ve attached a small poll with a few candidate names — please vote if you like.
And if the right name isn’t listed yet, feel free to drop suggestions in the comments 🙂
Project site: https://netbsd-jails.petermann-digital.de/
🚀 Cells for NetBSD ALPHA6 available!
Getting started is now even easier:
👉 Prebuilt amd64 images available as DVD and USB images.
Trying to automate my NetBSD release builds with style ;-)
It’s becoming real... When you build clean interfaces from the ground up, the next GUI is not magic. It is a concrete architectural vision, solid technical design, and a few prompts away...
What about a nice Midnight Commander-style TUI to manage cells interactively? 🤔
Thanks everyone for the constructive discussion and participation in the naming poll over the past days. It was really helpful.
The former "Jails for NetBSD" project will move forward under the name "Cells for NetBSD".
New project page:
https://netbsd-cells.petermann-digital.de
Next steps will focus on stabilizing the current prototype, testing it with real-world workloads, and exploring further ideas around a NetBSD-native container technology.
What comes to mind when you think about config files? YAML, JSON, INI — or HCL?
I’ve always liked HCL: structured (👀 INI), readable, supports comments (👀 JSON), and no whitespace sensitivity (👀 YAML).
It comes from HashiCorp and is used in tools like Nomad.
But in my “Cells for NetBSD” rewrite, it wasn’t an option → no Go in the base system.
So I went a different route:
👉 Lua as a config/DSL layer (already part of NetBSD)
Works surprisingly well — feels a lot like HCL, just without extra dependencies.
Side note:
cellman is now in C, logic lives in libcellman, shared by CLI + TUI → no IPC glue near the control plane 👍
👉 Curious:
Have you ever considered Lua as a config parser?
RE: https://mastodon.bsd.cafe/@mpeterma/116180607527845598
Quick follow-up on the naming discussion around my NetBSD project (currently “Jails for NetBSD”):
I’m planning to close the poll tonight at midnight (2026-03-07 EST). That should give me the rest of the weekend to refactor the codebase for the new name and then continue with stabilization, review and new features.
If you haven’t voted yet, please do 🙂 Your input is very helpful.
@Mentalisk@mastodon.social Thanks for the question...
To be honest, I’m not entirely sure what the exact path toward upstream integration would look like yet. I originally started this project mainly out of my own operational needs, although I did have the idea in the back of my mind that it might eventually become something that could live inside the official NetBSD tree or distribution.
That said, I think that point is still quite far away - and I don’t mean that in a negative way at all. NetBSD has a long tradition of stability and careful engineering. Experimental subsystems are not integrated ad-hoc, and I think that’s a very good thing.
For now I would actually prefer to give the project some more time to mature in its current off-tree state.
At the same time I’m already thinking about ways to make the feature more accessible and trustworthy for a broader audience without immediately requiring a merge into the official sources. For example, one idea would be to provide well-targeted patch sets for an upcoming NetBSD 11 release - either as source diffs for people who want to build their own kernels, or possibly as binary patch tarballs that could be applied to an existing system.
Most components are already modular enough to support that approach. The only exceptions are one or two small security-related patches in the main kernel that were necessary to restrict the visibility of certain system information.
Another important aspect is code review. From the beginning I’ve been transparent that I’m developing this project with AI assistance. That allowed me to implement my original concept and design much faster than I otherwise could have. I’m learning a lot along the way and improving my kernel development skills every day, but I’m definitely not an experienced kernel developer yet.
For something to enter the official tree, proper review by experienced NetBSD developers would obviously be essential - both technically and from a project governance perspective.
That said, I’m very open to discussion, feedback, and ideas. Where there’s interest and collaboration, I’m sure a path forward can eventually be found.