A private BSD laboratory

Some days has passed since I first tried the Jail partitioning system, moving my first steps in the field of “FreeBSD virtualization”. As soon as I built my first jailed machine, I felt the importance to flash in the mind the path I walked to reach the goal, thus (after some tests and nightly hours spent on this) I’m able to write down my first “how-to” blueprint, containing all the best practices I’ve experienced so far about creating a jailed system.

Obviously it cannot be considered a good guide to manage a jailed environment, mainly because of both experience and knowledge that I’m still missing. Actually, there are a lot (and surely they are the most) of things I don’t know about BSD system administration, and you should consider this short guide as the first work of a novice that want to understand how the process of jailing a FreeBSD system can be accomplished nicely with the least administrative effort… of course, as it should be today and with my current knowledge!

I’ve sorted all the operations I made in five sections:

• host system setup;

• host configuration;

• guest system build and configuration;

• guest image creation and deployment;

• guest image maintenance.

I know it looks like a MOF checklist! Please be patient: give me the time I need to get in confidence with BSD… after all, I’m still a MCT! 😉

Host system setup

I’m not the right person to tell you what is the best method to install a BSD server… I can only remind not to install anything that is not strongly needed by your server’s mission: I found that installing the “minimal” distribution set can give you a good start point if you are a novice like me. At this step, you might find useful reading the article “Building a Unix Server” by Dru Lavigne.

Host configuration

After our physical machine is up and running, we must modify the file /etc/rc.conf by inserting all IP aliases we would be able to assign to guest machines. The syntax to be used is showed by the following example:

ifconfig_xl0_alias0=”inet 192.168.1.2 netmask 255.255.255.0″ ifconfig_xl0_alias1=”inet 192.168.1.3 netmask 255.255.255.0″

After this, we have to change the behavior of some system services on the host, mainly in order to avoid conflicts that some network services running in the guests would cause by trying to listen concurrently on the same TCP/UDP ports, first in the rc.conf:

syslogd_flags=”-b bsdhost“    # where “bsdhost” is the host machine’s name

then, in the /etc/ssh/sshd_config:

ListenAddress 192.168.1.1    # the IP address of the physical machine.

Guest system build and configuration

Now it’s the time to build the first jailed system by issuing the “make world” statement. I don’t have the arrogance to write down this procedure by my own, since it is excellently described in the paragraph 15.4 of the FreeBSD Handbook: “Creating and Controlling Jails“. You’ll also find there the changes which need to be applied to the rc.conf file on the host system.

Obviously, we need to configure the jailed system as we are used to do for a physical FreeBSD machine, so we should spend a few minutes by setting up the DNS resolver, the startup daemons, and any other thing we need to have before starting the jail. In addition to these configurations, there are a couple of things to remember when customizing a jailed machine. For a generic approach, you can read another good explanation of the process of creating and configuring a jail under FreeBSD 6 in this article. Personally, I’ve found useful to write this in my rc.conf:

defaultrouter=”x.x.x.x“    # the only network parameter needed by the jail sshd_enable=”YES”        # if you wish to control the jail from remote sendmail_enable=”NONE”    # add this if you do not want a MTA syslogd_flags=”-ss”    # disable network access for syslogd.

Obviously, this is only my personal preference, and you may feel better with other options.

Guest image creation and deployment

Once you have your first jail up and running, you realize that if you would even add another jailed system you’ll have to step into the same procedure you’ve just completed. Probably it isn’t what you want, especially if you began playing with jails to be able to deploy new systems with the least administrative effort. To achieve this, we can easily make a “snapshot” of the jailed directory tree by using the tar command, immediately after the build process:

cd /usr/jail            # the directory containing all jails
tar jcvf snapshot.tar.bz2 www    # where “www” is the source jail name.

By this way we’ve saved a compressed image of the directory tree of a clean FreeBSD jail, which will turn to be useful whenever we’ll want to deploy a new jailed system: we’ll only have to untar the archive:

cd /usr/jail            # the directory containing all jails tar xvf snapshot.tar.bz2    # be careful not to overwrite the source jail.

Remember to set timezone and root password before start the jail with the /etc/rc.d/jail script, by issuing the following commands in the host’s shell:

jail [path] [hostname] [ipaddress] /bin/sh
tzsetup
passwd
exit

As we wanted, the process of deploying new systems has become a matter of few minutes (the most time is needed by the extraction process). Obviously there are some considerations we must take care of before put it in a production environment; we’ll see some of these in the next section.

Guest image maintenance

Not all systems are equal, and probably we’ll have to deploy a lot of jails to accomplish different server tasks, each needing different system configurations and packages. The best way I’ve found since now is to decompress the snapshot to be modified, apply all changes in the jail’s directory and then create a new compressed image by using the method I wrote in the previous paragraph. Be careful not to include any machine-specific setting (such as hostname, SSH key pair, etc.) before creating the image, to avoid potential problems when we’ll start a jail using the new snapshot.

This little guide come from my personal experience in working with the FreeBSD jail system and it cannot be referenced as a technical guide to build and maintain jails in a production environment. I’ll be glad if anyone more experienced and skilled than me on this theme will suggest how to make it more technically valuable and useful to FreeBSD systems administrators.

Yesterday I got the time to build a partitioned FreeBSD installation into a sandbox that we call “Jail”. This logical partition in which a BSD system can run quite independently from other instances on the same physical host seems what Sun Microsystems calls “Solaris Containers”: all processes running in the jail are not allowed to interact with the programs of the outside world, neither access the file system of the host or the others jailed machines. With this type of operating system-level virtualization all guests rely on the kernel of the host OS to run at the physical machine speed. Obviously we cannot gain the same isolation that a fully virtualized guest can achieve with Virtual Server, Xen or VMWare, but the performance of the guest are amazing and if the jail’s level of isolation is enough for you, this solution is one of the most exciting in the world of BSD operating systems: once I’ve “build the world” for the first jailed system and I’ve made a compressed tarball of its file system (about 52 Mb), I became able to set up any number of new BSD servers in about 3 minutes for each!!

A good start point to learn about the Jail system is obviously in the Handbook, but you can find other useful information all around the Net (I’ll post new links as soon as I’ll find some interesting ones):

• Architecture Handbook – The Jail Subsystem
• Sys Admin – Securing FreeBSD Using Jail
• The FreeBSD Diary – Jails under FreeBSD 6
• ONLamp.com – Virtualization with FreeBSD Jails

I’ve found some interesting articles by searching on the Windows Live Search engine.
You can also find some useful tools to manage jails in the sysutils section of the Ports Collection.