table of contents
| OVERLAY-BOOT(8) | OVERLAY-BOOT(8) |
NAME¶
overlay-boot - Start a subhost with overlay root filesystem.
SYNOPSIS¶
overlay-boot conf
DESCRIPTION¶
overlay-boot is the main script in a small collection of administration scripts for containerizing services with minimal ado. The script starts a "subhost" whose root filesystem is an overlay on the main host filesystem, and with separate mount, network and pid namespaces. In effect the default use case is merely an administrative sandboxing that is pre-populated with a copy of the overlaid filesystem.
Each subhost is defined by means of a configuration file, conf, that is a simple text file with small collection of "variables" telling how the subhost is set up. overlay-boot spawns a subprocess that performs the boot-up of the "subhost" as an init script that ends with a pid 1 reaper that simply "reaps" any terminated child processes.
An administrator may "enter" the subhost execution environment to perform adminstrative tasks by means of overlay-go, which uses chroot to start an interactive shell within the subhost namespaces. Such a shell however is not a child of the subhost pid 1 and it would normally only be used initially for configuring the subhost’s network, and set up network based services, such as sshd, for subsequent access.
Subhost execution is stopped with overlay-stop.
OPTIONS¶
An overlay-boot subhost is defined in a configuration file that is a plain text file with a number of variable assignments. Each assignment is written with the varable name flush left and immediately followed by an equal sign, The rest of that line (ignoring leading and trailing spaces) is its value. But if that value startes with an exclamation mark, then the line is a command to run during start-up so as to generate the value. See examples below.
NAME
BASE
A typical subhost setup is defined by a dedicated directory that contains the configuration file and the three mount points "root", "work" and "live".
CABLES
INIT
LIVE
LOG
LOWER
POSTMOUNT
PREMOUNT
RAM_SIZE
START
Note that if no services are started, then overlay-init starts a dummy_service so as to keep /.reaper from running out of child processes, as it otherwise will exit and thereby terminate overlay-boot.
UPPER
If UPPER is different from LOWER, then the root file system is set up as an overlay mount. In that case WORK (below) must be defined as a directory outside of but on the same mount as UPPER.
If UPPER is the same as LOWER, then the subhost root filesystem is not setup as an overlay. Rather, if UPPER is different from LIVE, the root filesystem is set up as a bind mount, and if UPPER and LIVE are also the same, then LIVE is used as root filesystem without additional mounting.
WORK
SHARE
NETWORKING¶
overlay-boot sets up a nework namespace named by the subhost $NAME, and uses the CABLES variable to set up veth type virtual cables. The host end of such cables are named by $NAME followed by a number from 0 and up while the subhost end are named by eth followed by the same number.
As mentioned above, CABLES is a space separated list of cable specifiers, each consisting of an optional bridge interface name, an optional MAC adddress or VLAN tag and with a required equal sign ("=") between them.
The bridge interface name, when given, will be given control of the host end cable interface. When the bridge interface name is omitted (empty) then the host end interface attracts an ifup $IF attempt instead.
The MAC address, if given, is used for the subhost end cable interface, which otherise gets its MAC address from the kernel, possibly a different one upon each start.
A VLAN tag has the format ".N" where N is a number between 1 and 4095. This modifies the cable function to set up a VLAN host interface on the prior host interface, and skip subhost side setup. E.g. if the prior host interface is example1 and the tag is .302 then the VLAN interface would be example1.302. The host side setup uses ifup $IF and thus, the host needs to have a supporting configuration entry in /etc/network/interfaces for the VLAN interface.
Note that it may be a good practice to keep a local interfaces file as sibling to the subhost configuration file on the host and use a source statement to include this into the system networking configuration.
EXAMPLES¶
Smallest possible¶
# mkdir -p /opt/subhost/copy/{root,work,live}
# cat << EOF > /opt/subhost/copy/copy.conf
BASE=.
EOF
This setup has a minimal configuration for a subhost that overlays the root filesystem but is without networking. The subhost must be entered with overlay-go, although the default start might have started sshd listening on a loopback interface in the subhost’s network namespaces.
Note that overlay-go runs a shell within the namespaces, but not as a child of the "subhost init" (aka .reaper).
/opt/subhost/tiny/tiny.conf¶
BASE=. CABLES= = START= none LOWER= base
The tiny subhost would be for overlaying a separate debootstrap root filesystem, without any services (since START is "none"). This gets started with a dummy_service to hold the overlay for access via overlay-go. The dummy_service sets up and listens on a pipe at /run/dummy_service, and exits when anything is written to that.
/opt/subhost/mta/mta.conf¶
BASE=. CABLES= = START= rsyslog networking ssh saslauthd postfix dovecot
The above example assumes a directory /opt/subhost/mta that contains the configuration file mta.conf and directories root, work and live. overlay-boot will set up an overlay mount on live with root as UPPER, work as WORK and / as LOWER, i.e. an overlay of the main host filesystem. Further, the running subhost will feature a virtual cable to the main host, where the subhost end is named eth0 and the main host end is named mta0, and upon start, an ifup mta0 is attempted at the host end while the subhost end is handled via its neworking service.
SEE ALSO¶
overlay-stop, overlay-go
| 2025-04-15 |