|
NAMEezjail —
Jail administration framework.
SYNOPSIS
OVERVIEWThe ezjail commands provide a simple way to create multiple jails using FreeBSD's jail system. It simplifies jail administration effort and minimizes jail system resource usage.If you are not familiar with the FreeBSD jail concept, please
refer to
jail(8)
before continuing. For additional design information, see the ezjail site at
DESCRIPTIONThe ezjail system enables the system administrator to create multiple OS-level virtualization containers called jails. Services like web servers, mail servers, FTP servers, are typically under frequent attack from the public Internet and are exposed to possible compromise. The typical usage of jails is to run a single service in each jail and if that service becomes compromised the rest of the jails and the host system are protected from also being compromised.The major shortcoming of jails is that each jail has its own copy of the world. This eats disk space, inodes, and more importantly, prevents the sharing of binaries images between jails, thus increasing the memory pressure on the host system. In addition, this causes a major administration headache when comes the time to update the host system, as each jail needs to be updated independently. Ezjail addresses these problems by creating a single basejail (a read-only nullfs(4) mounted directory) populated with the same binaries as the host system which is then shared across all the other service jails created by ezjail. Is is possible to update the base jail (and thus all the jails) in a single ezjail command. Typical usage of jails include separation of services, creating test environments, consolidation of different services on a single physical host, and more. EZJAIL SYSTEMThe administrative interface to the ezjail system is the ezjail-admin(8) command. It is used to install the ezjail environment, create new jails, archive, restore, delete and update jails, open a jail console, and list the status of all the jails. See below for example usage, and refer to its man page for complete usage details.Ezjail reads its configuration from its ezjail.conf(5). Normally it will not be necessary to edit this file, as some sane defaults are provided. A sample configuration is installed as /usr/local/etc/ezjail.conf.sample. A script is also installed as ezjail in
the rc.d system to allow jails under ezjails control to be started at boot
time, given ezjail is enabled by setting the
rc.conf(5)
variable “ WHAT'S IN A JAILThe life of an ezjail installationThe base jail is first created by runningezjail-admin command
arguments... update or
ezjail-admin command arguments...
install . Example usage of this command is section
EXAMPLES. This will create the base jail,
setup a template jail used to setting up new jails, install an example flavour
(see below) and configure miscellaneous things.
This step is necessary before using the ezjail system. In particular, it is not possible to create new jails without initializing the base jail in advance. Once the base jail has been created, new jails may be created with
After their creation, jails may be archived to a pax(1) archive, restored, and eventually deleted. When a new version of FreeBSD is released, or when an errata is published, only the base jail need to be updated. Both source upgrades and binary upgrades (using freebsd-update(8)) are supported. The ports(7) collection may also be updated by ezjail, but individual ports need to be upgraded individually by the administrator. Anatomy of a JailIn the ezjail system, a jail is defined by a root directory and a couple of configuration values, mainly a name and IP addresses. The root directory of the jail contains only the jail-specific files: configuration files, data files, and ports installed by the administrator. The base system is shared amongst all jails, using a nullfs(4) mount. This saves space and inodes (especially when the ports collection in made available to the jails), and also memory, as the kernel is now able to share copies of running programs between the jails.Unless the variable
“ There are also file-based jails, in which the storage space for the jail is kept in a file mounted with mdconfig(8). There are two advantages to image jails. The amount of disk space allocated to the jail is limited, while normal jails have no bound on the amount of disk space they use. On the other hand, the space dedicated to the jail is no longer available to the host, even if the jail doesn't use all its allocated space. Image jails may also be encrypted using bde(4) or geli(8), depending on the options given at creation time. Using ZFSTo give more precise control over the resources consumed by a jail, ezjail allows putting each jail in its own zfs(8) filesystem. See Jail Creation Examples for details.Also, ezjail can be configured to install its basejail and the
accompanying template for all new jails into its own filesystem. Set the
“ To use any zfs feature in ezjail, you first need to configure the
destination ZFS filesystem using the
“ You can use ZFS jails without installing the basejail into its own
ZFS filesystem and vice versa. In order to create ZFS jails by default, set
the “ Per-Jail optionsAs we saw earlier, a jail is described by a file in /usr/local/etc/ezjail/. This file has the same name as the jail it configures. It is a set of variables interpreted by sh(1), much like rc.conf(5) is. This file is created at the same time as the jail, and usually doesn't require tweaking from the administrator.In addition to the variables described below, any variable used by the init script /etc/rc.d/jail may be added manually by the administrator. The following variables are handled by ezjail, replacing JAILNAME with the actual name of the jail:
In addition to these sh(1)-style variables, the administrator may add comment lines starting with “PROVIDE:”, “REQUIRE:” and “BEFORE:”. These comments are used by rcorder(8) to determine the order in which the jails are started. The default is to keep “REQUIRE” and “BEFORE” empty, meaning the jails are started in no particular order. FlavoursWhen a jail is created, it is not configured; in particular you likely want to edit files such as /etc/resolv.conf, /etc/localtime and others. You may also want to create some system users, maybe enable sshd(8). Ezjail solves this problem by using the concept of “flavours”. When a flavour is selected at jail creation time, the flavour directory tree is merged into the new jail's directory tree. In addition, the jail is configured so that on its first boot, the file ezjail.flavour is executed.As part of the install sub-command, the flavour base directory was
created as /usr/jails/flavours and populated with an
single flavour named Updating the Base JailWe already mentioned how easy it is to update jails, since only one copy needs to be updated. Ezjail only handles updating the base system; updating the ports is left to the administrator (but see “ports-mgmt/jailaudit ” for a way to get
notified of ports in need of an update). Updates are handled with the
ezjail-admin command arguments...
update command. It is possible to update the base jail
from source or from binary packages. If a base jail already exists, the
update command installs the world in a temporary
directory before moving it to the basejail, thus leaving intact all installed
libraries. After making sure all software running in the jails is linked with
the new libraries, you may want to remove the old library versions. It is
often a good idea to update the jails when a new kernel is installed in the
host, using the same sources.
Starting JailsLike all rc(8) scripts, the ezjail script /usr/local/etc/rc.d/ezjail accepts parametersstart ,
restart and
stop, running, restarting and
stopping all (non-blocking) jails under ezjail's control by default.
When passed an additional list of jails, only these jails are acted upon.
The order in which jails are started is determined by the rcorder(8) tool, using cues from the jail configurations in ezjails /usr/local/etc/ezjail control directory. The script examines its config, attaches and mounts images, and sets variables for each jail in the list before passing its command on to the /etc/rc.d/jail script. To interactively start all crypto image jails (or those depending
on them), that were not automatically started during booting, use the
Note that jails configured to be in the norun
state (using As a convenient shortcut, the Even if ezjail is not enabled in the
rc.conf(5),
rc.d/ezjail can be used to start and stop jails by prepending
Snapshots and retention policiesJails residing in their own zfs and their corresponding zfs data sets can be automatically snapshot by theezjail-admin snapshot
subcommand. Taking snapshots of all jails before a major update is considered
best practise. However, when taking snapshots regularly, the amount of disc
space used can be considerable.
Therefore ezjail allows you to set retention policies that describe how many of your snapshots you want to keep for one or all jails or a particular zfs. See the description of the snapshot command in ezjail-admin(5) for details. A retention policy consists of one or multiple windows for which ezjail guarantees to keep at least one and at most two snapshots. A simple example: $ezjail_default_retention_policy="1d 2w
1y"
will ensure ONE snapshot for the last day, for the last two weeks before that
day and then for one snapshot in the year before the two-week window. Valid
multipliers are (m)inutes, (h)ours, (d)ays, (w)eeks and (y)ears.
Windows can be repeated by prepending them with a number and the letter x: $ezjail_test_com_retention_policy="24x1h 6x1d
3x1w 11x4w KEEP"
will set the retention policy for jail test.com to keep hourly snapshots for one
day, then daily snapshots for the rest of the week, weekly snapshots for the
rest of the month, monthly snapshots for the rest of the year.
The magic keyword KEEP at the end of the list will make ezjail not delete snapshots older than the oldest window. It is your responsibility to keep the list in an order that makes keeping snapshots possible, i.e. not placing one-hour-windows after one-year-windows. Remarks & TipsJails can be either accessed from the network, for instance by using ssh(1), or from the host system by using theconsole command,
which gives you an interactive shell inside the jail. It is also possible to
edit the files of a running jail, and the modifications will appear
immediately inside the jail environment. When dealing image-based, the
config -i attach command allows one to access the disk
of a file-based jail without starting it.
Raw sockets are disallowed by default for all jails. This is not a ezjail restriction, but a design default of the jail command. This means the ping(8) command will get “Operation not permitted.” error when used from inside of a jail. There are sysctl(3) knobs for allowing a jail to access raw sockets, see the jail(8) man page for details. Once your jail has network access, then all your normal application install functions are available, right from the jails console. In particular, if the ports collection was installed, it can be used as if from the host system. A modified make.conf file is installed by the example flavour, that enable the ports collection to work even with a read-only /usr/ports. It is possible to change the IP address of a jail by editing its configuration file in /usr/local/etc/ezjail and restarting the jail. The jails use the same network stack as the host system. In particular, that means that if a firewall is needed, it must be configured in the host system. The ezjail system (and the jails it controls) depends on the
“ The ezjail system may be reset to a pristine state by removing all its files, that is:
EXAMPLESThe examples below are only that, examples. The reader is encouraged to read the ezjail-admin(8) man page for definitive documentation of all the options.Initial Binary InstallationThe ezjail system may be bootstrapped either from binary packages, or by building from source. Theinstall command allow to
bootstrap from binary packages, while the update deals
with installations (and updates) from source.
From Source Installation and UpdateTheupdate is used to both install or update from source
the base jail, and for updating the base jail from binary packages.
Jail Creation Examples
FILES/usr/local/bin/ezjail-admin/usr/local/etc/rc.d/ezjail /usr/local/etc/ezjail.conf /usr/local/share/examples/ezjail/ /usr/local/etc/ezjail/* /usr/etc/fstab.* SEE ALSOezjail-admin(8), ezjail.conf(5), jail(8), nullfs(4), zfs(8).Interesting additional tools include:
“ AUTHORDirk Engling ⟨erdgeist@erdgeist.org⟩.The man page is based on a draft by JoeB ⟨joeb1@a1poweruser.com⟩ and was rewritten by Frederic Perrin ⟨frederic.perrin@resel.fr⟩.
Visit the GSP FreeBSD Man Page Interface. |