systemd-sysext(8)

.SH "NAME" systemd-sysext, systemd-sysext.service, systemd-sysext-initrd.service, systemd-sysext-sysroot.service, systemd-confext, systemd-confext.service, systemd-confext-initrd.service, systemd-confext-sysroot.service - Activates System Extension Images

.SH "SYNOPSIS"

.HP 360u

systemd-sysext
[OPTIONS...]
COMMAND

.PP systemd-sysext.service

.HP 384u

systemd-confext
[OPTIONS...]
COMMAND

.PP systemd-confext.service

.SH "DESCRIPTION"

.PP 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.

.PP 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.

.PP 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.

.PP 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 and the Mutable= option in the configuration file; see "Mutability" below for more information.

.PP Various command options can be configured globally via configuration files. See sysext.conf(5) for details.

.PP 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.

.PP System extension images may be provided in the following formats:

.PP 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.

.PP 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.

.PP During boot, system and configuration extension images are activated automatically if the systemd-sysext.service and systemd-confext.service services are enabled. Note that these services run only after the underlying file systems where system and configuration extensions may be located have been mounted. To make it possible to ship resources that are processed by subsystems running in the earliest boot stages (for example, system services or systemd-sysusers(8) definitions), the systemd-sysext-sysroot.service and systemd-confext-sysroot.service initrd services are provided. Currently, these services cannot be used to merge system extensions from /sysroot/var/lib/extensions/ and configuration extensions from /sysroot/var/lib/confexts/ when the /var/ partition is split off. These extensions are later merged by the systemd-sysext.service and systemd-confext.service services during the main OS boot process.

.PP Also, 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 differences in isolation between these two mechanisms: while system extensions directly extend the underlying OS image with additional files that appear 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. Binaries shipped in system extensions can only link against libraries from the host if the extension is bound to the version of the host OS (see further below) or otherwise have to use static linking. Portable services, however, are fully decoupled from the host as they ship their own library dependencies.

.PP The systemd-sysext.service and systemd-confext.service services are guaranteed to finish start-up before basic.target is reached; i.e., by the time regular services initialize (those which do not use DefaultDependencies=no), the files and directories provided by system and configuration extensions are available in /usr/, /opt/, and /etc/ and may be accessed.

.PP System and configuration extensions can also be used to extend the initrd, and the systemd-sysext-initrd.service and systemd-confext-initrd.service initrd services are provided. Note that some limitations apply: resources that are used in the earliest boot stages of the initrd (e.g. system services) cannot be updated.

.PP 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. It is also possible to disable automatic merging altogether using the rd.systemd.sysext=, rd.systemd.confext=, systemd.sysext=, and systemd.confext= kernel command line options. Note that systemd-sysext-sysroot.service and systemd-confext-sysroot.service are controlled by the systemd.sysext= and systemd.confext= options, as these services merge system and configuration extensions for the main system, not for the initrd.

.PP 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. EXTENSION_RESTART_UNITS= and EXTENSION_RELOAD_OR_RESTART_UNITS= can be set to a whitespace-separated list of unit names (e.g. EXTENSION_RESTART_UNITS="my.service other.service") that systemd-sysext/systemd-confext should restart resp. reload (or restart, if the unit does not support reloading) after merging or refreshing the extension, and after unmerging it. Use EXTENSION_RESTART_UNITS= for units whose binary the extension replaces (a reload would not pick up the new binary), and EXTENSION_RELOAD_OR_RESTART_UNITS= for units the extension extends with configuration drop-ins only (so reload-capable services are not needlessly interrupted). If a unit has disappeared, e.g., on unmerge because it was part of the extension, it is stopped instead. If the same unit is listed in both fields, EXTENSION_RESTART_UNITS= takes precedence. Listing any unit in either field implies EXTENSION_RELOAD_MANAGER=1, as the service manager would otherwise not yet (or no longer) see the unit files shipped by the extension. Note that these settings do not take effect when the extension is merged for the system already from the initrd and extensions should still ship a .wants/ or .upholds/ symlink from the unit's install target to ensure the unit starts at boot. 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.

.PP The systemd-confext concept follows the same principle as the systemd-sysext(8) 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.

.PP 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.

.PP 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.

.PP 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.

.SH "USES"

.PP 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.

.PP 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 of whether the underlying host /usr/ is managed as immutable disk image or is a traditional package manager controlled (i.e. writable) tree.

.PP 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.

.SH "MUTABILITY"

.PP 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.

.PP The following modes are supported:

See "Options" below on specifying modes using the --mutable= command line option.

.PP With exception of the ephemeral mode, the mutable mode routes writes to subdirectories in /var/lib/extensions.mutable/.

.PP 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

.PP 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.

.PP Added in version 256.

.SH "COMMANDS"

.PP The following commands are understood by both the sysext and confext concepts:

.PP status