It’s been a couple of months now since I’ve started to work on a daily basis with jails (and more recently with convenience tool ezjail) and it’s time for a wrap-up: are (FreeBSD-)jails worth the hassle?

Short answer: yes. Long answer: yeeeeeeeeeeeees ;-)

In the beginning I was a bit overwhelmed on a practical level by the “red-tape” involved in setting them up (ezjail has effectively taken care of that, though) and on a conceptual level with constantly having to switch context – mentally, as well as ‘physically’: where you used to be just a cd or su away from your next task you now often need to enter a new jail – which one? go the host system, do a jsl, look for the jail you need, take a note of its id then sudo jexec $ID tcsh... now, where was I?

This is an aspect that still needs improvement. Especially the step of finding the current runtime id of a given jailname is a task best left to a machine.

The top three things that bother me when working inside a jail are:

1. that ping doesn’t work: Papa Scott points out in his comment, that "With sysctl, you can set security.jail.allow_raw_sockets=1 and thus enable ping and traceroute to be run in your jails. ", yay!
2. that localhost and 127.0.0.1 don’t work
3. that a jail can have only one IP-Address

Another thing that still could use a little love in this context is the ports collection. In the current setup you either need to install (and maintain!) one ports collection in each jail or you create a dedicated ‘buidljail’ whose ports collection you keep up-to-date and build packages using the make package-recursive which usually¹ creates the ready-to-install binary packages (including all dependencies) in /usr/ports/packages/All/ which is then mounted read-only via nullfs into each jail.

This sucks twice: first of all it’s inconvenient to create the packages and clean them up again and secondly it requires root access to the build jail which is fine, if you’re just one admin but kind of defeats one of the main purposes of virtualisation when providing other users with their own jails.

This, of course, is fixable and it isn’t really too hard. One just has to set a few environment variables (DISTDIR and WRKDIRPREFIX) in each jail to direct the actual make process of a package away from the default ./work (which is read-only from inside the jail) to somewhere else.

Having said all that it’s now time to report on the goodies. Aside from the security aspects that virtualisation and compartmentalisation bring (think of a huge oil tanker with individual sections vs. one without) there is a huge benefit for you as admin of a jail host – which is, however, somewhat hard to describe. But for example, it’s really practical to, say, tinker with apache to set up a webmail interface without having to worry about breaking your subversion setup. Migrating from bind to tinydns? Just create a new jail, set everything up until it works and then just switch over the IPs of the old bind-jail and the new tinydns jail. Working with jails also means fewer installed packages and less chances for conflicting versions. (Anybody who had to update a dozen or so packages for a new version of gettext just because he/she innocently installed wget will appreciate this…) And also, suddenly every single rc.conf file is just a few lines long and meaningful…

I do wonder, though, how many people looking for information on prisons and life as an inmate will end up at tomster.org since I’ve been blogging about this…

[1] some ports such as djbdns cannot be packaged. Also, portupgrade won’t work in this kind of environment