I've continued to putter about with cdist and gotten far enough along that I was imagining being able to use cdist to spin up & tear down jails with some degree of alacrity, in the fullness of time. I'm imagining dynamic Just In Time instantiation of jails w/ the slimmest of userlands for the task, expiring on a schedule. Like pods only without the whole kubernetes overhead. Using, instead, a veritable trove of POSIX scripts.

But as it turns out, I found a bug! I only noticed because I'd misread the documentation. When my eyes fell upon jail_freebsd10 I immediately started trying to use it. I had noticed but not thought a lot about there being a type for older FreeBSD systems, jail_freebsd9. All my attempts failed so I finally resorted to reading more documentation. Therein I discovered there's a higher level type, jail and __jail wraps the more specific jail types before passing through the parameters in the manifest. That must be my problem; I don't know enough to call it directly, I probably just need to go through the top level type & let the magic happen.

Obviously that didn't do it. But the way in which it didn't do it surprised me. Rather than fail identically to the way it did when I used __jail_freebsd10, it failed in a new reproducible way. Now I got interested because how could calling __jail_freebsd10 from __jail be different from directly calling __jail_freebsd10 in a still wrong way.

Then I tried something out of desperation: actually reading the error messages being spat out & reading source code to follow the flow of failures. The curious thing I observed as that on my FreeBSD 15 system, __jail was consistently, wrongly, trying to apply the __jail_freebsd9 type. When I tried using __jail_freebsd9 directly, it failed in the same way as calling __jail.

-if grep -q '^10\.' "$(cat "$__global/explorer/os_version")" ; then   # Version is 10.x
+if grep -q '^[[:digit:]]\{2,\}\.' "$__global/explorer/os_version" ; then # Version > 9.x
    __jail_freebsd10 "$@"
 else
    __jail_freebsd9 "$@"