Provided by: systemd_256.5-2ubuntu4_amd64 
NAME
systemd-sysext, systemd-sysext.service, systemd-confext, systemd-confext.service -
Activates System Extension Images
SYNOPSIS
systemd-sysext [OPTIONS...] COMMAND
systemd-sysext.service
systemd-confext [OPTIONS...] COMMAND
systemd-confext.service
DESCRIPTION
systemd-sysext activates/deactivates system extension images. System extension images may
– dynamically at runtime — extend the /usr/ and /opt/ directory hierarchies with
additional files. This is particularly useful on immutable system images where a /usr/
and/or /opt/ hierarchy residing on a read-only file system shall be extended temporarily
at runtime without making any persistent modifications.
System extension images should contain files and directories similar in fashion to regular
operating system tree. When one or more system extension images are activated, their /usr/
and /opt/ hierarchies are combined via "overlayfs" with the same hierarchies of the host
OS, and the host /usr/ and /opt/ overmounted with it ("merging"). When they are
deactivated, the mount point is disassembled — again revealing the unmodified original
host version of the hierarchy ("unmerging"). Merging thus makes the extension's resources
suddenly appear below the /usr/ and /opt/ hierarchies as if they were included in the base
OS image itself. Unmerging makes them disappear again, leaving in place only the files
that were shipped with the base OS image itself.
Files and directories contained in the extension images outside of the /usr/ and /opt/
hierarchies are not merged, and hence have no effect when included in a system extension
image. In particular, files in the /etc/ and /var/ included in a system extension image
will not appear in the respective hierarchies after activation.
System extension images are strictly read-only by default. On mutable host file systems,
/usr/ and /opt/ hierarchies become read-only while extensions are merged, unless
mutability is enabled. Mutability may be enabled via the --mutable= option; see
"Mutability" below for more information.
System extensions are supposed to be purely additive, i.e. they are supposed to include
only files that do not exist in the underlying basic OS image. However, the underlying
mechanism (overlayfs) also allows overlaying or removing files, but it is recommended not
to make use of this.
System extension images may be provided in the following formats:
1. Plain directories or btrfs subvolumes containing the OS tree
2. Disk images with a GPT disk label, following the Discoverable Partitions
Specification[1]
3. Disk images lacking a partition table, with a naked Linux file system (e.g. erofs,
squashfs or ext4)
These image formats are the same ones that systemd-nspawn(1) supports via its
--directory=/--image= switches and those that the service manager supports via
RootDirectory=/RootImage=. Similar to them they may optionally carry Verity authentication
information.
System extensions are searched for in the directories /etc/extensions/, /run/extensions/
and /var/lib/extensions/. The first two listed directories are not suitable for carrying
large binary images, however are still useful for carrying symlinks to them. The primary
place for installing system extensions is /var/lib/extensions/. Any directories found in
these search directories are considered directory based extension images; any files with
the .raw suffix are considered disk image based extension images. When invoked in the
initrd, the additional directory /.extra/sysext/ is included in the directories that are
searched for extension images. Note however, that by default a tighter image policy
applies to images found there, though, see below. This directory is populated by systemd-
stub(7) with extension images found in the system's EFI System Partition.
During boot OS extension images are activated automatically, if the systemd-sysext.service
is enabled. Note that this service runs only after the underlying file systems where
system extensions may be located have been mounted. This means they are not suitable for
shipping resources that are processed by subsystems running in earliest boot.
Specifically, OS extension images are not suitable for shipping system services or
systemd-sysusers(8) definitions. See the Portable Services[2] page for a simple mechanism
for shipping system services in disk images, in a similar fashion to OS extensions. Note
the different isolation on these two mechanisms: while system extension directly extend
the underlying OS image with additional files that appear in a way very similar to as if
they were shipped in the OS image itself and thus imply no security isolation, portable
services imply service level sandboxing in one way or another. The systemd-sysext.service
service is guaranteed to finish start-up before basic.target is reached; i.e. at the time
regular services initialize (those which do not use DefaultDependencies=no), the files and
directories system extensions provide are available in /usr/ and /opt/ and may be
accessed.
Note that there is no concept of enabling/disabling installed system extension images: all
installed extension images are automatically activated at boot. However, you can place an
empty directory named like the extension (no .raw) in /etc/extensions/ to "mask" an
extension with the same name in a system folder with lower precedence.
A simple mechanism for version compatibility is enforced: a system extension image must
carry a /usr/lib/extension-release.d/extension-release.NAME file, which must match its
image name, that is compared with the host os-release file: the contained ID= fields have
to match unless "_any" is set for the extension. If the extension ID= is not "_any", the
SYSEXT_LEVEL= field (if defined) has to match. If the latter is not defined, the
VERSION_ID= field has to match instead. If the extension defines the ARCHITECTURE= field
and the value is not "_any" it has to match the kernel's architecture reported by uname(2)
but the used architecture identifiers are the same as for ConditionArchitecture= described
in systemd.unit(5). EXTENSION_RELOAD_MANAGER= can be set to 1 if the extension requires a
service manager reload after application of the extension. Note that for the reasons
mentioned earlier: Portable Services[2] remain the recommended way to ship system
services. System extensions should not ship a /usr/lib/os-release file (as that would be
merged into the host /usr/ tree, overriding the host OS version data, which is not
desirable). The extension-release file follows the same format and semantics, and carries
the same content, as the os-release file of the OS, but it describes the resources carried
in the extension image.
The systemd-confext concept follows the same principle as the systemd-sysext(1)
functionality but instead of working on /usr and /opt, confext will extend only /etc.
Files and directories contained in the confext images outside of the /etc/ hierarchy are
not merged, and hence have no effect when included in the image. Formats for these images
are of the same as sysext images. The merged hierarchy will be mounted with "nosuid" and
(if not disabled via --noexec=false) "noexec".
Just like sysexts, confexts are strictly read-only by default. Merging confexts on mutable
host file systems will result in /etc/ becoming read-only. As with sysexts, mutability can
be enabled via the --mutable= option. Refer to "Mutability" below for more information.
Confexts are looked for in the directories /run/confexts/, /var/lib/confexts/,
/usr/lib/confexts/ and /usr/local/lib/confexts/. The first listed directory is not
suitable for carrying large binary images, however is still useful for carrying symlinks
to them. The primary place for installing configuration extensions is /var/lib/confexts/.
Any directories found in these search directories are considered directory based confext
images; any files with the .raw suffix are considered disk image based confext images.
Again, just like sysext images, the confext images will contain a
/etc/extension-release.d/extension-release.NAME file, which must match the image name
(with the usual escape hatch of the user.extension-release.strict xattr(7)), and again
with content being one or more of ID=, VERSION_ID=, and CONFEXT_LEVEL. Confext images will
then be checked and matched against the base OS layer.
USES
The primary use case for system images are immutable environments where debugging and
development tools shall optionally be made available, but not included in the immutable
base OS image itself (e.g. strace(1) and gdb(1) shall be an optionally installable
addition in order to make debugging/development easier). System extension images should
not be misunderstood as a generic software packaging framework, as no dependency scheme is
available: system extensions should carry all files they need themselves, except for those
already shipped in the underlying host system image. Typically, system extension images
are built at the same time as the base OS image — within the same build system.
Another use case for the system extension concept is temporarily overriding OS supplied
resources with newer ones, for example to install a locally compiled development version
of some low-level component over the immutable OS image without doing a full OS rebuild or
modifying the nominally immutable image. (e.g. "install" a locally built package with
DESTDIR=/var/lib/extensions/mytest make install && systemd-sysext refresh, making it
available in /usr/ as if it was installed in the OS image itself.) This case works
regardless if the underlying host /usr/ is managed as immutable disk image or is a
traditional package manager controlled (i.e. writable) tree.
With systemd-confext one can perform runtime reconfiguration of OS services. Sometimes,
there is a need to swap certain configuration parameter values or restart only a specific
service without deployment of new code or a complete OS deployment. In other words, we
want to be able to tie the most frequently configured options to runtime updateable flags
that can be changed without a system reboot. This will help reduce servicing times when
there is a need for changing the OS configuration. It also provides a reliable tool for
managing configuration because all old configuration files disappear when the
systemd-confext image is removed.
MUTABILITY
By default, merging system extensions on mutable host file systems will render /usr/ and
/opt/ hierarchies read-only. Merging configuration extensions will have the same effect on
/etc/. Mutable mode allows writes to these locations when extensions are merged.
The following modes are supported:
1. disabled: Force immutable mode even if write routing directories exist below
/var/lib/extensions.mutable/. This is the default.
2. auto: Automatic mode. Mutability is disabled by default and only enabled if a
corresponding write routing directory exists below /var/lib/extensions.mutable/.
3. enabled: Force mutable mode and automatically create write routing directories below
/var/lib/extensions.mutable/ when required.
4. import: Force immutable mode like disabled above, but merge the contents of
directories below /var/lib/extensions.mutable/ into the host file system.
5. ephemeral: Force mutable mode like enabled above, but instead of using write routing
directory below /var/lib/extensions.mutable/, systemd-sysext will use empty ephemeral
directories. This means that the modifications made in the merged hierarchies will be
gone when the hierarchies are unmerged.
6. ephemeral-import: Force mutable mode like ephemeral above, but instead of ignoring the
contents of write routing directories under /var/lib/extensions.mutable/, merge them
into the host file system, like import does.
See "Options" below on specifying modes using the --mutable= command line option.
With exception of the ephemeral mode, the mutable mode routes writes to subdirectories in
/var/lib/extensions.mutable/.
Writes to /usr/ are directed to /var/lib/extensions.mutable/usr/
writes to /opt/ are directed to /var/lib/extensions.mutable/opt/, and
writes to /etc/ land in /var/lib/extensions.mutable/etc/.
If usr/, opt/, or etc/ in /var/lib/extensions.mutable/ are symlinks, then writes are
directed to the symlinks' targets. Consequently, to retain mutability of a host file
system, create symlinks
/var/lib/extensions.mutable/etc/ → /etc/
/var/lib/extensions.mutable/usr/ → /usr/
/var/lib/extensions.mutable/opt/ → /opt/
to route writes back to the original base directory hierarchy.
Alternatively, a temporary file system may be mounted to /var/lib/extensions.mutable/, or
symlinks in /var/lib/extensions.mutable/ may point to sub-directories on a temporary file
system (e.g. below /tmp/) to only allow ephemeral changes. Note that this is not the same
as ephemeral mode, because the temporary file system will still exist after unmerging.
Added in version 256.
COMMANDS
The following commands are understood by both the sysext and confext concepts:
status
When invoked without any command verb, or when status is specified the current merge
status is shown, separately (for both /usr/ and /opt/ of sysext and for /etc/ of
confext).
Added in version 248.
merge
Merges all currently installed system extension images into /usr/ and /opt/, by
overmounting these hierarchies with an "overlayfs" file system combining the
underlying hierarchies with those included in the extension images. This command will
fail if the hierarchies are already merged. For confext, the merge happens into the
/etc/ directory instead.
Added in version 248.
unmerge
Unmerges all currently installed system extension images from /usr/ and /opt/ for
sysext and /etc/, for confext, by unmounting the "overlayfs" file systems created by
merge prior.
Added in version 248.
refresh
A combination of unmerge and merge: if already mounted the existing "overlayfs"
instance is unmounted temporarily, and then replaced by a new version. This command is
useful after installing/removing system extension images, in order to update the
"overlayfs" file system accordingly. If no system extensions are installed when this
command is executed, the equivalent of unmerge is executed, without establishing any
new "overlayfs" instance. Note that currently there's a brief moment where neither the
old nor the new "overlayfs" file system is mounted. This implies that all resources
supplied by a system extension will briefly disappear — even if it exists continuously
during the refresh operation.
Added in version 248.
list
A brief list of installed extension images is shown.
Added in version 248.
-h, --help
Print a short help text and exit.
--version
Print a short version string and exit.
OPTIONS
--root=
Operate relative to the specified root directory, i.e. establish the "overlayfs" mount
not on the top-level host /usr/ and /opt/ hierarchies for sysext or /etc/ for confext,
but below some specified root directory.
Added in version 248.
--force
When merging system extensions into /usr/ and /opt/ for sysext and /etc/ for confext,
ignore version incompatibilities, i.e. force merging regardless of whether the version
information included in the images matches the host or not.
Added in version 248.
--image-policy=policy
Takes an image policy string as argument, as per systemd.image-policy(7). The policy
is enforced when operating on system extension disk images. If not specified defaults
to
"root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent"
for system extensions, i.e. only the root and /usr/ file systems in the image are
used. For configuration extensions defaults to
"root=verity+signed+encrypted+unprotected+absent". When run in the initrd and
operating on a system extension image stored in the /.extra/sysext/ directory a
slightly stricter policy is used by default: "root=signed+absent:usr=signed+absent",
see above for details.
Added in version 254.
--mutable=BOOL|auto|import
Set mutable mode.
no
force immutable mode even with write routing directories present. This is the
default.
Added in version 256.
auto
enable mutable mode individually for /usr/, /opt/, and /etc/ if write routing
sub-directories or symlinks are present in /var/lib/extensions.mutable/; disable
otherwise. See "Mutability" above for more information on write routing.
Added in version 256.
yes
force mutable mode. Write routing directories will be created in
/var/lib/extensions.mutable/ if not present.
Added in version 256.
import
immutable mode, but with contents of write routing directories in
/var/lib/extensions.mutable/ also merged into the host file system.
Added in version 256.
ephemeral
force mutable mode, but with contents of write routing directories in
/var/lib/extensions.mutable/ being ignored, and modifications of the host file
system being discarded after unmerge.
Added in version 256.
ephemeral-import
force mutable mode, with contents of write routing directories in
/var/lib/extensions.mutable/ being merged into the host file system, but with the
modifications made to the host file system being discarded after unmerge.
Added in version 256.
Added in version 256.
--noexec=BOOL
When merging configuration extensions into /etc/ the "MS_NOEXEC" mount flag is used by
default. This option can be used to disable it.
Added in version 254.
--no-reload
When used with merge, unmerge or refresh, do not reload daemon after executing the
changes even if an extension that is applied requires a reload via the
EXTENSION_RELOAD_MANAGER= set to 1.
Added in version 255.
--no-pager
Do not pipe output into a pager.
--no-legend
Do not print the legend, i.e. column headers and the footer with hints.
--json=MODE
Shows output formatted as JSON. Expects one of "short" (for the shortest possible
output without any redundant whitespace or line breaks), "pretty" (for a pretty
version of the same, with indentation and line breaks) or "off" (to turn off JSON
output, the default).
EXIT STATUS
On success, 0 is returned.
SEE ALSO
systemd(1), systemd-nspawn(1), systemd-stub(7), importctl(1)
NOTES
1. Discoverable Partitions Specification
https://uapi-group.org/specifications/specs/discoverable_partitions_specification
2. Portable Services
https://systemd.io/PORTABLE_SERVICES