Here I'm republishing an old blog post of mine originally from March 2017. The article has been slightly improved.
This is the first part of a followup to the 4.11 four part mini-series of posts that I published here on my blog. Those posts covered installing an old FreeBSD 4.11 system and using pkgsrc to update some parts of the system from versions released in the last millennium (!) to those of today (or rather from December 2016).
Updating FreeBSD 4.11 (1/4) - Blast from the past
Updating FreeBSD 4.11 (2/4) - Digging up old graves
Updating FreeBSD 4.11 (3/4) - Neophyte's notorious necromancy
Updating FreeBSD 4.11 (4/4) - Reflecting radical resurrection
Now we're going one step further: We'll migrate a 4.11 system into a jail on a fresh FreeBSD 11.0 host system! This will be dealt with in the next post. In this part I'll introduce the jail concept for people who are not familiar with it, discuss some jail management frameworks and do a bit of preparation work.
Why to send that old system to a jail? We've already done a bit of work on a 4.11 system. But that next step tightens security much more since we have a recent kernel, can make use of a state-of-the-art firewall, etc. This is not actually my main concern however. Those remaining machines are running internal processes, so security is nice but not critical. What _is_ critical and really frightens me, is the age of the hard drives that they use... When you do a _df_ and see that the total capacity of a drive is way below 100 GB, you can guess that drives like that have not been sold for... quite some years now! And knowing that drives are pretty perfidious little things, I'd rather get rid of those as soon as possible.
What makes things worse: This is FreeBSD 4.11. There's no _GEOM_ available and thus no _gmirror_ or anything. Yes, there are backups. But I'd rather not have to mess with something like that just to restore a system that should have been decommissioned years ago!
If you're new to FreeBSD, you may have heard about _jails_ without knowing what they actually are. If you've got a Solaris background, think _zones_. If you're a Linux user, think _containers_. FreeBSD people usually cannot understand today's container hype for the very simple reason that this OS has had jails for ages now (they were first available on development versions at the very end of the 20th century!). You are probably familiar with docker, Linux's cgroups and all those facilities. FreeBSD basically does the same thing: Provide much enhanced but still very light-weight chroot environment.
The system in that jail is isolated from the actual host operating system so that escaping it isn't trivial and requires special (insecure) settings. In general jails are meant to be secure after all, aren't they? You can also give jails their own virtual network stack, you can cap their resource usage, and so on. It's a mature, stable and secure way to do containerization of applications - or whole operating system installations.
Since FreeBSD is pretty good at maintaining compatibility with old releases (for the next major release they are discussing whether to keep compatibility shims that allow executing binaries from commercial UNIX releases of the 80's!!), it's very much possible to stuff a 4.11 userland into a jail running on a recent version of the operating system. And that's what we're going to look at after getting some of the basics out of the way.
Jails in FreeBSD can be created and managed manually. We're talking *nix here, after all! However there are several jail management frameworks available that promise to make things even easier - or at least more convenient. If you want to get started with jails, I suggest that you pick a framework that sounds good to you feature-wise and simply begin playing with it. The whole thing is not that complicated actually.
If you're just getting started, don't bother with _sysutils/warden_. It was a popular jail manager created for PC-BSD but it is considered obsolete now.
One true classic among the jail frameworks is _sysutils/ezjail_. It still does the job and a lot of people continue to use it simply because they are already familiar with it. It allows for things like thin-provisioned jails that use a "base jail" which holds a complete FreeBSD userland, and uses nullmount to make that accessible in other jails. This makes updating very quick and convenient. It also leaves the base system read-only which may be another nice security feature at the cost of decreased flexibility. On the plus side, ezjail is independent on filesystems and thus works on UFS, too.
Then there was _sysutils/iocage_, a modern approach that made use of ZFS properties to store certain values. For that reason it demands at least one zpool on the system to be usable. It had been implemented in shell code which made it easy to read for admins who don't have a lot of coding experience. It has however been rewritten and the old shell version is declared obsolete. If you like the idea of having it written in shell, take a look at _sysutils/iocell_, which is a fork of the last shell version and is actively maintained.
The new version of _iocage_ is implemented in Python (initially it was announced to be rewritten in Go but that decision was revoked). Another warning: _sysutils/py-iocage_ is the wrong version, too! Do not use it. The rewrite initially supported Python 2.7 - which is what this port is all about - but newer versions dropped support for that and now require Python 3.6. So the actual port you should use is _sysutils/py3-iocage_! That version requirement makes sense but unfortunately it leads to iocage not being available from packages (as FreeBSD's default version of Python 3 is still 3.3 currently). So you probably need to build it from ports.
There's one more framework that I want to mention: _sysutils/cbsd_. It is an advanced system that not only does jails but also allows to manage bhyve (FreeBSD's modern hypervisor). If you're looking for something more comprehensive you may well give it a try.
When I first wanted to get into jails, I tried out ezjail. It worked well for me and I'd still use it on a system with no ZFS available. When I have ZFS, though, I liked the iocage approach. Cbsd looks quite good but I didn't do too much with it because I require things to be scriptable (like using the framework through SaltStack states - there's even a Salt Formula for iocage, but that's for the old implementation) and that doesn't seem to be what they focus on. So when the shell based iocage was deprecated, I moved to iocell and then I was torn to stick with that or to return to the new iocage. In the end I opted for at least giving the rewrite a chance. Since it does its thing quite nicely, I've adopted that and will use it here.
You can of course use any other framework if you prefer a different one. Or you could setup your jail by hand - if you're thinking about that, definitely take a look at this article by M. W. Lucas whom I actually have to thank not only for his post but kind of for this one as well.
M. W. Lucas on jailing FreeBSD 4
The thought of jailing the old systems crossed my mind once or twice, but if he hadn't written about it in the past, I don't think I'd ever have given it a try (no, I read his post back in the day when he published it; yes, I wanted to try this for over three years now before I finally found some time to give it a shot!).
Let's install _iocage_ first. Like stated before, we will have to build it from ports. Assuming a system that does not have a ports tree installed, this is how you can do it (there are better (cleaner) ways to build packages from ports, I planned to do a post about that topic since December!) but this old method still works:
# portsnap fetch extract
# cd /usr/ports/sysutils/py3-iocage
# make config-recursive
# make install clean
The new iocage needs a _UTF-8_ locale set on the system or it won't run. Unfortunately this is not the standard in FreeBSD (this is something that I really hope for in FreeBSD 12!) [Didn't happen - but it looks like 13.0 finally did it!]. There are multiple ways to do this, my preferred one to set it in _/etc/login.conf_:
Look for _default:\_ - it is followed by a block of indented lines, the last one being _:umask=022:_. Add another backslash at the end to make the block continue and add two more lines to it:
:charset=UTF-8:\
:lang=en_US.UTF-8:
Login configuration is one of the few things where the actual values are in fact stored in a database. The changes that you made to the text file won't take effect even if you log out and back in. First run another command to update the DB according to the changes in the text file:
# cap_mkdb /etc/login.conf
Now log out and back in. Try echoing $LANG - that should print the UTF locale's name. If it does, you are set.
The next post will demonstrate how to use iocage to manage jails and show how to jail a FreeBSD 4.11 system so it runs on a FreeBSD 11 host.