watermelon# service jail start gitea
Starting jails: cannot start jail  "gitea":
ifconfig: interface epair14 already exists
jail: gitea: ifconfig epair14 create up: failed
.
watermelon# service jail stop gitea
Stopping jails:.

What perplexed me about this issue is that I would run ifconfig epair14a after the failure to start the jail, and the interface would be there. “Surely this must be a FreeBSD bug!”

The “eureka!” happened earlier today, not while I was sleeping, but rather while I was solving other problems. “I bet there’s something fishy in the configuration, I should just rewrite it” I thought to myself. Most esoteric bugs are not bugs with the compiler, libraries, or operating systems. Usually they’re the user doing something slightly stupid and not realizing it.

My jail configuration (/etc/jail.conf) resembled the following:

gitea {
        $id = "14";
        $ip_addr = "10.10.10.${id}";

        vnet.interface = "epair${id}b";

        exec.prestart = "ifconfig epair${id} create up";
        exec.prestart += "ifconfig epair${id}a up descr vnet-${name}";
        exec.prestart += "ifconfig $public_bridge addm epair${id}a up";

        exec.start = "/sbin/ifconfig epair${id}b ${ip_addr}";
        exec.start += "/sbin/route add default ${public_gw}";
        exec.start += "/bin/sh /etc/rc";

        exec.prestop = "ifconfig epair${id}b -vnet ${name}";
        exec.poststop = "ifconfig ${public_bridge} deletem epair${id}a";
        exec.poststop += "ifconfig epair${id}a destroy";
}

Looking at the block and comparing it to other functional jails, I saw something missing: a vnet; declaration:

--- jail.conf   2023-11-12 20:09:03.028010000 -0800
+++ /etc/jail.conf      2023-11-12 19:59:02.867271000 -0800
@@ -230,6 +230,7 @@
        $id = "14";
        $ip_addr = "10.10.10.${id}";

+       vnet;
        vnet.interface = "epair${id}b";

        exec.prestart = "ifconfig epair${id} create up";

Sometimes you have to just walk away from a problem for a bit, but yeesh was that a silly one!

I have attempted to consolidate the home lab before, but not with this level of success. There was the time I tried deploying a single-node Kubernetes cluster, which worked for a time until some upgrade caused the software-defined networking to break in a way I wasn’t interested in debugging in my free time. Following that I tried to go “old school” and started spinning up libvirt-based virtual machines which worked well for a long time. The major downside of that approach is that I simply wasn’t able to get much density because of the significant overhead for each virtual machine. At some point you run out of memory to commit to each VM.

Converting virtual machines to FreeBSD Jails took a few hours over a weekend, and since then the quantity of what is running has jumped dramatically. Originally I was running:

• Nextcloud (Apache)
• MySQl
• Gopher server
• Tor relay
• Gitea

I now also run:

• Elasticsearch
• Graylog
• Icinga
• Icecast
• MongoDB
• Nginx
• Peertube
• PostgreSQL, which replaced MySQL for Nextcloud and is now running for multiple services.
• Redis
• Plus some personal web apps

To accomplish this, I use ZFS and Jails heavily. All the jails run on a striped and mirrored ZFS disk array which allows for better performance and redundancy than my previous incantation. These services are low-utilization which allows them to cooperate effectively within this machine’s 4 cores and 16GB of RAM.

Benefits

The higher utilization of this single machine, which is always-on, has a better power consumption profile than running multiple machines. More power efficiency wasn’t my original motivation however, I was much more interested in some of the system administration benefits of bringing these services “under one roof.”

Backups are much easier than before. I’m using some ZFS scripts to perform automatic snapshots on daily/weekly/monthly basis. Separately from those, I regularly push backups off-site and that’s trivial because at the “host” machine level, not the jail level, I can access all the filesystems at once.

Security is much easier as well since Jails are obviously providing a level of isolation. On top of that, I am using the vnet functionality in FreeBSD to provide additional network segmentation, something I never did with physical or virtual machines.

Management is pretty straightforward with all these services running in Jails. I typically do all my administration from the host rather than the jail level. As such I can pretty easily shuffle configuration files around. Unfortunately to date I haven’t found a good configuration management tool, including my own tinkering that provides a Jails-aware set of tools for more automation.

Downsides

The most notable downside to this approach is that a hardware failure could take me offline for a bit. These services are all dependent on a single power supply (PSU) and CPU. As such a failure of either would require me to keep all these services offline until that part could be replaced. For a home lab setup, I’m not expecting to support a specific SLA, so I’m quite comfortable with this risk.

I can imagine some security arguments that could be made, but frankly I think this Jails approach is much better secured than my previous home lab setups.

At present this machine has just under 10GB of RAM in use and a load average that floats between 1.0 and 2.0. Despite all the services that are running, it still uses less than my workstation with a few browsers open. To deploy your own “home lab” set up in this way you absolutely do not need a high powered machine. I would argue that a ZFS-based disk array is likely more important, after all most home lab tasks, that aren’t video-encoding, tend to be more disk I/O heavy rather than memory/CPU heavy.

This path isn’t quite entry-level simple, but if you have some systems administration experience, I think FreeBSD with ZFS and Jails is worth considering for your home or office lab.

2021-02-14 update with more tips below

Note: if you’re already familiar with how great FreeBSD jails are, you can skip ahead

Without trying to start a flamewar, I think FreeBSD jails are basically what Linux containers aspired to be when they grew up. In short:

The jail mechanism is an implementation of FreeBSD’s OS-level virtualisation that allows system administrators to partition a FreeBSD-derived computer system into several independent mini-systems called jails, all sharing the same kernel, with very little overhead

From Wikipedia

Since FreeBSD 12, FreeBSD jails can “natively” do something which I haven’t seen done seriously in other container or virtualization stacks: provide full network isolation. VNET allows attaching an entire virtualized network stack to a jail, which allows you to delegate an actual hardware interface to a jail, after which the host no longer sees the interface at all!

VNET is the name of a technique to virtualize the network stack. The basic idea is to change global resources most notably variables into per network stack resources and have functions, sysctls, eventhandlers, etc. access and handle them in the context of the correct instance. Each (virtual) network stack is attached to a prison, with vnet0 being the unrestricted default network stack of the base system.

From vnet(9)

Using this capability you can set up entirely software-defined virtualized networks inside of FreeBSD jails for everything from network software testing (e.g. VPNs), to pre-flighting firewall changes in a simulated environment. If this sounds compelling to you, I recommend bouncing over to this blog post to learn more.

FreeBSD has also supported ZFS natively, including as the boot / partition for a number of major releases. It should therefore be no surprise that jails integrate very well with ZFS. In my setup each jail is its own file system in the main ZFS pool (zroot), which allows me to snapshot each jail independently for backup purposes.

“Excuse me, I believe I was promised some pkg(1) related content?”

Yes yes, getting to that. Since FreeBSD jails are not well appreciated by the broader systems engineering world, I wanted to take a moment to highlight some of what we’ve been missing out the past couple years while we’ve been screwing around with container orchestration engines.

pkg(1) is a binary package management tool akin to apt or yum. On modern FreeBSD installations compiling ports is no longer required, which is an incredibly welcome change to FreeBSD in recent years. Like its Linux relatives, pkg retrieves package metadata and tarballs from a remote repository by default, from the “offline jail” perspective this is a problem.

Jails however, are just running off slices of my host filesystem, e.g. /jails/postgresql which allows me to commands from the host in that file tree, for example:

freebsd# ls /jails/postgressql
.cshrc          bin             entropy         libexec         net             root            tmp
.profile        boot            etc             media           proc            sbin            usr
COPYRIGHT       dev             lib             mnt             rescue          sys             var
freebsd#

You should note that this looks surprisingly identical to what a default base install of FreeBSD, and that’s because it is!

Installing packages

The pkg(1) utility has a very useful flag -c which I can use for these jails:

-c <chroot path>, --chroot <chroot path>
    pkg will chroot in the <chroot path> environment.

From the jail host’s perspective, I can poke around the jail’s filesystem with ease, which makes installing packages trivial from the host’s perspective. For example:

freebsd# pkg -c /jails/postgresql install postgresql13-server

The above command will install the PostgreSQL v13 package and all its dependencies within the jail’s filesystem path:

# postgres --version
postgres (PostgreSQL) 13.1
#

“Try this one weird trick and your jails will never have to know anything about packages ever again!”

Caveats:

• My host distribution is identical to the distribution installed in the jail, e.g. 12.2-RELEASE. If there were drift I’m sure there would be problems with using pkg(1) in this way.
• This approach can feel goofy with configuration management, since the jail host is where all the configuration and package management happens.

Nonetheless, I was incredibly excited to discover this feature which made setting up and managing my heavily isolated vnet-based jails much easier!

2021-02-14 update: Here’s a tip passed along from a reader:

you might be interested in a tip for your jail post.

pkg -o ABI=... \
--chroot /path/to/jail \
--config /some/package/repo/FreeBSD.conf \
install -y ...

where ABI could be FreeBSD:14:aarch64 (FreeBSD current on armv8/aarch64) or a more prosaic FreeBSD:12:amd64 (amd64 architecture, FreeBSD 12).

the config file is similar to /etc/pkg/FreeBSD.conf and is acquired by pkg(8) before dropping into the chroot.

NB I usually need to mount_devfs inside the jail before & after pkg, as it now requires /dev/null - see #1763

This allows us to install packages into a directory that is not for the same FreeBSD version (and possibly even architecture!), such as a FreeBSD 13.0 armv8 nfs mount, running on a FreeBSD 14.0-current amd64 server.

There’s also pkg –rootdir … which is similar to chroot, but IIRC handles pre/post/user/group scripts differently.

In the future I hope to write more about the home lab FreeBSD set up that I have been working on over the past couple weeks. FreeBSD 12.x is by far the most exciting FreeBSD release I have used since the transition to full SMP in the 4.x -> 6.x timeframe. If you haven’t looked at FreeBSD lately, I highly recommend giving it a spin!