The jail is created according to configuration file generated by cbsd jcreate jconf=path_to_cfg. For create configuration, use a command cbsd jconstruct (question-answer dialog mode), or dialog(1)-based interface: cbsd jconstruct-tui, or via WEB interface. When pkg.conf and repository configured properly, you can preset to new jail some packages mark them through pkglist menu. For safety reason recommended to use the official FreeBSD pkg repo or build your own package repository.

Please note: when repo unavailable, item pkglist in cbsd jconstruct-tui did not show anything.

Please note: multi-repo and and the ability to choose a specific repository from the list at the moment is missing, and will be used repository prescribed in pkg.conf of master host.

If you do not use automation (Puppet, Ansible, own implementation for generation of jconf) to create environments and you have to create a container with different parameters, use the ability to create your own profile to override the default values. You can override any parameter - the proposed template for jail name, version, binding to a specific interface instead of 'auto', etc..

for creating config via dialog:

The same menu is available to create a jail when configuring CBSD via bsdconfig

If jconstruct-tui work correctly, on the exit the question for jail create will be asked. In a case positively answer, jcreate it will be executed on a new configuration automatically. Otherwise, the script will save configuration file (in $workdir/ftmp), on which it is possible to create a jail by hand.

You can override the jailskeldir="$workdir/share/jail-skel", parameters which is stored in $workdir/etc/defaults/jail-freebsd-default.conf to specify an alternate template directory, which will overwrite the files in the original base files when creating jail. To do this, create a file jail-freebsd-XXXXX.conf in $workdir/etc and enter the value.:

See for details: Profiles for jail creation

• profile - profile in which the parameters are set by default. Described above
• pkglist - Select package list for new jail
• jname - Short (one word) name of the jail
• host_hostname - FQDN for the jail environment
• ip4_addr - specify IP addresses (separated by commas if more than one) or 0 for vnet/bhyve environments
• ver - FreeBSD version for the base (10.1, 11.0 for RELEASE or 10, 11 for STABLE)
• baserw - mount copy of base via nullfs in read only (baserw=no) or populate own copy (baserw=yes) with write access
• mount_ports - mount /usr/ports dir from base system to jail (read only). To the environment can build ports (and not interfere with each other vorkdir) - reassigned WRKDIRPREFIX parameters to alternate location. Or, make sure that applytpl params is set to 1 - then CBSD does this automatically via WRKDIRPREFIX=/tmp in /etc/make.conf of the jail
• astart - Automatic start jail on the system boot
• interface - Specify uplink for jail (on what interface create/remove IP) or prohibit.
• applytpl - Automatically adjust the same settings of the jail (create /etc/hosts, change WRKDIRPREFIX, etc..)
• floatresolv - Automatically adjust /etc/resolv.conf from jnameserver IP (settings from initenv/initenv-tui)
• arch - Specify architecture of jail environment
• vnet - Enable or disable VIMAGE feature

If DIALOG-based script jconstruct-tui for some reason did not come for create configuration of the new jails, you can use the script, dialogue like "question and answer" jconstruct

Which specifies the same question as the tui-version. Also, the configuration can avoid the formation without additional interactive utilities, for example building systems that automatically create the necessary jails.

Example of a standard configuration for jcreate might look like:

If you want to create jail with installed some packages from pkg repository, in this configuration must have an pkglist pointing to a file with a list of packages, for example:

The /tmp/newjail.txt file might look like:

cbsd jcreate remove file pointed by pkglist variables after jail create

By default, the directory specified by jailskeldir will be used as source files that will be added (or they will be overwritten with standard files) into a jail automatically when applytpl=1. Accordingly, you can create any configuration templates and content environments that will be copied when creating a new jail.

Descriptions:

Cconfiguration parameters jail

Each CBSD jail stores the settings in SQLite3 database. In addition, $workdir/jails-fstab/ may have fstab files (see below). To change the settings of jail can serve cbsd jconfig command, which is runs the TUI menu to change basic settings:

IP addresses that are bound to the jail sets in ip4_addr parameter. As an IP may serve as IPv4, and the IPv6 address. When starting and stopping jail, working with IP may take place in two modes:

• automatic on-the-fly creation of IP addresses for the jail at the time of launch + automatic removal from the interface IP when stopping
• the use of previously initialized IP addresses.

When for jails assigned to more than one address, they should be listed separated by commas without spaces. IP can include network prefix specified through IP/prefix. By default, aliases created with the prefix /32, that may not be appropriate if the jail uses a separate subnet from the network server — in this case, the correct /prefix is needed.

The parameter that controls this behavior pointed by interface parameter. When interface=0, jstart and jstop will not be called ifconfig alias and ifconfig -alias, respectively. If its value is auto or name of network nics, this command will be executed:

and when jail stop:

Be careful with this option, if you have only one IP for server that is used and this IP is assigned to the same jail, when stopping jail, ip address of the server will be removed automatically that will make the server unavailable. In this case, you need to use:

For example, to run the configuration tool for the jail1, run:

Each jail can have your fstab file, which lists the file systems that are mounted jail is startup. System records (they are managed by CBSD and edit this file inappropriately) are located in the file $workdir/jails-fstab/fstab.name and the same syntax to format the file system /etc/fstab with the exception that as a mount point is the path relative to the root jail, not the master system.

For user entries, you can use the file in the same directory with the extension .local. For example, if you want to make between jail1 and jail2 a shared directory (via nullfs), which physically located in the master node (e.g.: /usr/home/sharefs), the files $workdir/jails-fstab/fstab.jail1.local and $workdir/jails-fstab/fstab.jail2.local should have:

If you want to mount tmpfs to /tmp dir in jail1 (those actually in /usr/jails/jails/jail1/tmp), then the entry in the $workdir/jails-fstab/fstab.jail1.local should have:

both entries perform the same action as commands:

If you want to mount into jail2 a directory from jail1, jail1 path should point to the directory containing the data jail1 (and their mount points ${workdir}/jails/jail1). For example entry $workdir/jails-fstab/fstab.jail2.local:

Make the shared directory /usr/local/www between jail1 and jail2, but it will jail2 in read-only mode

There are flaws when mounting via mount -t /type/ does not work or mounting must be done in a non-standard way. In this case, use the 'external' reserved word, where the 'source' field will point to your external script, the output of which should be a mounted directory.

An example of such an entry in fstab.local:

                /root/ntfs-3g.sh        /usr/home/web/downloads external rw 0 0
                

and an example working script /root/ntfs-3g.sh for this entry: ntfs-3g.sh, which mounts an external USB drive directly into the container.

If you want to attach separate ZFS filesystems in jail (ie, want to be able to perform in jail zfs mount), ZFS dataset must list in $workdir/jails-fstab/fstab.$jname.local file with specifying the keyword zfs in FStype field. For example, if you want to present the file system ZFS: zroot/jail1_webfs for jail jail1 $workdir/jails-fstab/fstab.jail1.local must have:

Note: mount point (/usr/home/web in this example) is not important

Note: jail must have allow_zfs paramaters set to 1, what can be done via cbsd jconfig jname=$jname

In fact, it makes CBSD execute commands:

when jail started and

when stoped.

Another possibility is to change certain parameters of the jail — use the command cbsd jset. Full list of possible arguments can be accessed through --help:

For example, to change ip of jail1:

cbsd jconfig jname=jail2

cbsd jset

You can write your own scripts to be executed within the jail and in the master host on startup and shutdown of the environment. For this, the system directory of jail ( $workdir/jails-system/$jname/ ) have the following directories:

• master_poststart.d - scripts for executing in the master host after jail starts (Be careful, because the scripts are is not jailed)
• master_poststop.d - scripts for executiong in the master host after jail stops (Be careful, because the scripts are is not jailed)
• master_prestart.d - scripts for executing in master host before jail starts (Be careful, because the scripts are is not jailed)
• master_prestop.d - scripts for execution in master host after jail stops (Be careful, because the scripts are is not jailed)
• start.d - scripts for execution within jail when jail is starts. Analog of parameter exec.start from original jail.conf
• stop.d - scripts for execution within jail when jail is starts. Analog of parameter exec.stop from original jail.conf
• remove.d - (since CBSD 11.0.10) scripts for execution on remove command

Write scripts to the master_\* directories can be useful if at the start-stop jail you need to perform some action is not associated with content of environment - for example, create a ZFS snapshot, put rules in IPFW and etc.

In scripts, you can use CBSD variables, such as $jname, $path, $data, $ip4_addr, for example, by placing a script (with execute permission) in /usr/jails/jails-system/jail1/master_poststart.d/notify.sh:

You will receive notification upon startup cells by email: root@example.net

The functionality of execution custom scripts and the availability of variables in environments can play a big role in the integration of CBSD and external applications, such as Consul

As an example of use, see the article Example of using CBSD/bhyve and ISC-DHCPD (Serve IP address in bhyve through pre/post hooks)

As an example of use, see the article Example of using CBSD/jail and Consul (Register/unregister jail's via pre/post hooks, in Consul)

Running jails occurs at startup CBSD/server automatically if parameter astart (auto-start) corresponding jail set to 1. You can change this setting through cbsd jconfig or cbsd jset. When you stop the server or service cbsdd, all running jails will be stopped automatically.

Starting the jail manually by the command:

or

or

(to launch multiple jails by one command)

When ( You can change this behavior in cbsd initenv-tui ) parallel=0 and you try to launch/stoping a few jails, start/stop will be held consecutively. It is not always good, as any error triggered inside jails in the rc-scripts, which leads to a pause, can block start/stop next jails. In the case when parallel have a non-zero value, each next jails will be launched/stopped in N seconds after the previous one, where N — parallel value. After this timeout, no matter whether the previous jail o start fully and next jail will be started.

To stoping jail jstop must be used, with the same syntax and behavior:

or

or

(to stopping multiple jails by one command)

If the argument of the jstart/jstop/jrestart command is missing, will displays the corresponding list of all running or stopped jail for interactive selection

When the jail is started, it creates a lock file, a sign that the jail working via file ${jailsysdir}/${jname}/locked which records the name of the node. This feature is used when this jail presented several nodes, these jail are in the DFS (NFS, glusterfs, etc.) and any node is able to run it. This lock ensures that the presence of the same jail at the second node, it will not be launched.

With a large number of jails (particularly databases, with services such as MySQL, redis, cassandra, etc.), it should be borne in mind that the low value parallel (for example, less than 5 seconds) can generate a very intensive storage I/O load that can increase the amount of start-up time of all jails, than if they were run sequentially or higher timeout.

Additionally, when a shutdown command is running on the server with lots of jails/services that should be taken into consideration low timeout that defaults to perform rc.shutdown sequence. In this regard, the process init(8) can interrupt the rc-scripts on this timeout, resulting in abnormal shutdown jails. In this case, the database can lead to nonconservation or damage data. To avoid this, /etc/rc.conf master system should be adjusted parameter rcshutdown_timeout to a more reasonable value (default: 90 seconds)

In the absence of rcshutdown_timeout in the system /etc/rc.conf, cbsd initenv will put this option in its sole discretion automatically.

Also, keep in mind that when using the zfs features ($workdir/nc.inventory, the parameter zfsfeat=1), and the file system ZFS, at jstop, file system of jails will be unmounted and those catalog $workdir/jails-data/jail1-data will be empty. If in such a case when jail data is requires without running it, by the command zfs list You can see the name appropriate file system and run zfs mount fs.

Please read details on the Jail config

jupgrade command