1
0
mirror of https://github.com/systemd/systemd.git synced 2024-12-22 17:35:35 +03:00
systemd/man/systemd-sysext.xml
2024-04-15 10:40:11 +02:00

483 lines
29 KiB
XML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version='1.0'?> <!--*-nxml-*-->
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
<refentry id="systemd-sysext" conditional='ENABLE_SYSEXT'
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>systemd-sysext</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>systemd-sysext</refentrytitle>
<manvolnum>8</manvolnum>
</refmeta>
<refnamediv>
<refname>systemd-sysext</refname>
<refname>systemd-sysext.service</refname>
<refname>systemd-confext</refname>
<refname>systemd-confext.service</refname>
<refpurpose>Activates System Extension Images</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>systemd-sysext</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
<arg choice="plain">COMMAND</arg>
</cmdsynopsis>
<para><filename>systemd-sysext.service</filename></para>
<cmdsynopsis>
<command>systemd-confext</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
<arg choice="plain">COMMAND</arg>
</cmdsynopsis>
<para><filename>systemd-confext.service</filename></para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><command>systemd-sysext</command> activates/deactivates system extension images. System extension
images may dynamically at runtime — extend the <filename>/usr/</filename> and
<filename>/opt/</filename> directory hierarchies with additional files. This is particularly useful on
immutable system images where a <filename>/usr/</filename> and/or <filename>/opt/</filename> hierarchy
residing on a read-only file system shall be extended temporarily at runtime without making any
persistent modifications.</para>
<para>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
<filename>/usr/</filename> and <filename>/opt/</filename> hierarchies are combined via
<literal>overlayfs</literal> with the same hierarchies of the host OS, and the host
<filename>/usr/</filename> and <filename>/opt/</filename> 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
<filename>/usr/</filename> and <filename>/opt/</filename> 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.</para>
<para>Files and directories contained in the extension images outside of the <filename>/usr/</filename>
and <filename>/opt/</filename> hierarchies are <emphasis>not</emphasis> merged, and hence have no effect
when included in a system extension image. In particular, files in the <filename>/etc/</filename> and
<filename>/var/</filename> included in a system extension image will <emphasis>not</emphasis> appear in
the respective hierarchies after activation.</para>
<para>System extension images are strictly read-only by default. On mutable host file systems,
<filename>/usr/</filename> and <filename>/opt/</filename> hierarchies become read-only while extensions
are merged, unless mutability is enabled. Mutability may be enabled via the <option>--mutable=</option>
option; see "Mutability" below for more information.</para>
<para>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.</para>
<para>System extension images may be provided in the following formats:</para>
<orderedlist>
<listitem><para>Plain directories or btrfs subvolumes containing the OS tree</para></listitem>
<listitem><para>Disk images with a GPT disk label, following the <ulink
url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink></para></listitem>
<listitem><para>Disk images lacking a partition table, with a naked Linux file system (e.g. erofs,
squashfs or ext4)</para></listitem>
</orderedlist>
<para>These image formats are the same ones that
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
supports via its <option>--directory=</option>/<option>--image=</option> switches and those that the
service manager supports via <option>RootDirectory=</option>/<option>RootImage=</option>. Similar to
them they may optionally carry Verity authentication information.</para>
<para>System extensions are searched for in the directories
<filename>/etc/extensions/</filename>, <filename>/run/extensions/</filename> and
<filename>/var/lib/extensions/</filename>. 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 <filename>/var/lib/extensions/</filename>. Any directories found in
these search directories are considered directory based extension images; any files with the
<filename>.raw</filename> suffix are considered disk image based extension images. When invoked in the
initrd, the additional directory <filename>/.extra/sysext/</filename> 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
<citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> with
extension images found in the system's EFI System Partition.</para>
<para>During boot OS extension images are activated automatically, if the
<filename>systemd-sysext.service</filename> 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
<citerefentry><refentrytitle>systemd-sysusers</refentrytitle><manvolnum>8</manvolnum></citerefentry>
definitions. See the <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> 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 <filename>systemd-sysext.service</filename> service is
guaranteed to finish start-up before <filename>basic.target</filename> is reached; i.e. at the time
regular services initialize (those which do not use <varname>DefaultDependencies=no</varname>), the files
and directories system extensions provide are available in <filename>/usr/</filename> and
<filename>/opt/</filename> and may be accessed.</para>
<para>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 <filename>.raw</filename>) in <filename>/etc/extensions/</filename> to "mask"
an extension with the same name in a system folder with lower precedence.</para>
<para>A simple mechanism for version compatibility is enforced: a system extension image must carry a
<filename>/usr/lib/extension-release.d/extension-release.<replaceable>NAME</replaceable></filename>
file, which must match its image name, that is compared with the host <filename>os-release</filename>
file: the contained <varname>ID=</varname> fields have to match unless <literal>_any</literal> is set
for the extension. If the extension <varname>ID=</varname> is not <literal>_any</literal>, the
<varname>SYSEXT_LEVEL=</varname> field (if defined) has to match. If the latter is not defined, the
<varname>VERSION_ID=</varname> field has to match instead. If the extension defines the
<varname>ARCHITECTURE=</varname> field and the value is not <literal>_any</literal> it has to match the kernel's
architecture reported by <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
but the used architecture identifiers are the same as for <varname>ConditionArchitecture=</varname>
described in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
<varname>EXTENSION_RELOAD_MANAGER=</varname> 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:
<ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> remain
the recommended way to ship system services.
System extensions should not ship a <filename>/usr/lib/os-release</filename> file (as that would be merged
into the host <filename>/usr/</filename> tree, overriding the host OS version data, which is not desirable).
The <filename>extension-release</filename> file follows the same format and semantics, and carries the same
content, as the <filename>os-release</filename> file of the OS, but it describes the resources carried
in the extension image.</para>
<para>The <command>systemd-confext</command> concept follows the same principle as the
<citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>1</manvolnum></citerefentry>
functionality but instead of working on <filename>/usr</filename> and <filename>/opt</filename>,
<command>confext</command> will extend only <filename>/etc</filename>. Files and directories contained
in the confext images outside of the <filename>/etc/</filename> hierarchy are <emphasis>not</emphasis>
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 <literal>nosuid</literal> and
(if not disabled via <option>--noexec=false</option>) <literal>noexec</literal>.</para>
<para>Just like sysexts, confexts are strictly read-only by default. Merging confexts on mutable host
file systems will result in <filename>/etc/</filename> becoming read-only. As with sysexts, mutability
can be enabled via the <option>--mutable=</option> option. Refer to "Mutability" below for more
information.</para>
<para>Confexts are looked for in the directories <filename>/run/confexts/</filename>,
<filename>/var/lib/confexts/</filename>, <filename>/usr/lib/confexts/</filename> and
<filename>/usr/local/lib/confexts/</filename>. 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 <filename>/var/lib/confexts/</filename>. Any directories found
in these search directories are considered directory based confext images; any files with the
<filename>.raw</filename> suffix are considered disk image based confext images.</para>
<para>Again, just like sysext images, the confext images will contain a
<filename>/etc/extension-release.d/extension-release.<replaceable>NAME</replaceable></filename>
file, which must match the image name (with the usual escape hatch of
the <varname>user.extension-release.strict</varname>
<citerefentry project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
and again with content being one or more of <varname>ID=</varname>, <varname>VERSION_ID=</varname>, and
<varname>CONFEXT_LEVEL</varname>. Confext images will then be checked and matched against the base OS
layer.</para>
</refsect1>
<refsect1>
<title>Uses</title>
<para>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.
<citerefentry project='man-pages'><refentrytitle>strace</refentrytitle><manvolnum>1</manvolnum></citerefentry>
and
<citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>
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.</para>
<para>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 <command>DESTDIR=/var/lib/extensions/mytest
make install &amp;&amp; systemd-sysext refresh</command>, making it available in
<filename>/usr/</filename> as if it was installed in the OS image itself.) This case works regardless if
the underlying host <filename>/usr/</filename> is managed as immutable disk image or is a traditional
package manager controlled (i.e. writable) tree.</para>
<para>For the confext case, the OSConfig project aims to 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.</para></refsect1>
<refsect1>
<title>Mutability</title>
<para>By default, merging system extensions on mutable host file systems will render <filename>/usr/</filename>
and <filename>/opt/</filename> hierarchies read-only. Merging configuration extensions will have the same
effect on <filename>/etc/</filename>. Mutable mode allows writes to these locations when extensions are
merged.</para>
<para>The following modes are supported:
<orderedlist>
<listitem><para><option>disabled</option>: Force immutable mode even if write routing directories exist
below <filename>/var/lib/extensions.mutable/</filename>. This is the default.</para></listitem>
<listitem><para><option>auto</option>: Automatic mode. Mutability is disabled by default and only
enabled if a corresponding write routing directory exists below
<filename>/var/lib/extensions.mutable/</filename>.</para></listitem>
<listitem><para><option>enabled</option>: Force mutable mode and automatically create write routing
directories below <filename>/var/lib/extensions.mutable/</filename> when required.</para></listitem>
<listitem><para><option>import</option>: Force immutable mode like <option>disabled</option> above, but
merge the contents of directories below <filename>/var/lib/extensions.mutable/</filename> into the host
file system.</para></listitem>
<listitem><para><option>ephemeral</option>: Force mutable mode like <option>enabled</option> above, but
instead of using write routing directory below <filename>/var/lib/extensions.mutable/</filename>,
<command>systemd-sysext</command> will use empty ephemeral directories. This means that the
modifications made in the merged hierarchies will be gone when the hierarchies are
unmerged.</para></listitem>
<listitem><para><option>ephemeral-import</option>: Force mutable mode like <option>ephemeral</option>
above, but instead of ignoring the contents of write routing directories under
<filename>/var/lib/extensions.mutable/</filename>, merge them into the host file system, like
<option>import</option> does.</para></listitem>
</orderedlist>
See "Options" below on specifying modes using the <option>--mutable=</option> command line option.</para>
<para>With exception of the ephemeral mode, the mutable mode routes writes to subdirectories in
<filename>/var/lib/extensions.mutable/</filename>.
<simplelist type="horiz">
<member>Writes to <filename>/usr/</filename> are directed to <filename>/var/lib/extensions.mutable/usr/</filename></member>,
<member>writes to <filename>/opt/</filename> are directed to <filename>/var/lib/extensions.mutable/opt/</filename>, and</member>
<member>writes to <filename>/etc/</filename> land in <filename>/var/lib/extensions.mutable/etc/</filename>.</member>
</simplelist></para>
<para>If <filename>usr/</filename>, <filename>opt/</filename>, or <filename>etc/</filename>
in <filename>/var/lib/extensions.mutable/</filename> are symlinks, then writes are directed to the
symlinks' targets.
Consequently, to retain mutability of a host file system, create symlinks
<simplelist type="horiz">
<member><filename>/var/lib/extensions.mutable/etc/</filename><filename>/etc/</filename></member>
<member><filename>/var/lib/extensions.mutable/usr/</filename><filename>/usr/</filename></member>
<member><filename>/var/lib/extensions.mutable/opt/</filename><filename>/opt/</filename></member>
</simplelist>
to route writes back to the original base directory hierarchy.</para>
<para>Alternatively, a temporary file system may be mounted to
<filename>/var/lib/extensions.mutable/</filename>, or symlinks in
<filename>/var/lib/extensions.mutable/</filename> may point to sub-directories on a temporary file system
(e.g. below <filename>/tmp/</filename>) 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.</para>
<xi:include href="version-info.xml" xpointer="v256"/>
</refsect1>
<refsect1>
<title>Commands</title>
<para>The following commands are understood by both the sysext and confext concepts:</para>
<variablelist>
<varlistentry>
<term><option>status</option></term>
<listitem><para>When invoked without any command verb, or when <option>status</option> is specified
the current merge status is shown, separately (for both <filename>/usr/</filename> and
<filename>/opt/</filename> of sysext and for <filename>/etc/</filename> of confext).</para>
<xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<varlistentry>
<term><option>merge</option></term>
<listitem><para>Merges all currently installed system extension images into
<filename>/usr/</filename> and <filename>/opt/</filename>, by overmounting these hierarchies with an
<literal>overlayfs</literal> 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 <filename>/etc/</filename> directory instead.</para>
<xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<varlistentry>
<term><option>unmerge</option></term>
<listitem><para>Unmerges all currently installed system extension images from
<filename>/usr/</filename> and <filename>/opt/</filename> for sysext and <filename>/etc/</filename>,
for confext, by unmounting the <literal>overlayfs</literal> file systems created by <option>merge</option>
prior.</para>
<xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<varlistentry>
<term><option>refresh</option></term>
<listitem><para>A combination of <option>unmerge</option> and <option>merge</option>: if already
mounted the existing <literal>overlayfs</literal> 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 <literal>overlayfs</literal> file system accordingly. If no system extensions
are installed when this command is executed, the equivalent of <option>unmerge</option> is executed,
without establishing any new <literal>overlayfs</literal> instance.
Note that currently there's a brief moment where neither the old nor the new <literal>overlayfs</literal>
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.</para>
<xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<varlistentry>
<term><option>list</option></term>
<listitem><para>A brief list of installed extension images is shown.</para>
<xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<xi:include href="standard-options.xml" xpointer="help" />
<xi:include href="standard-options.xml" xpointer="version" />
</variablelist>
</refsect1>
<refsect1>
<title>Options</title>
<variablelist>
<varlistentry>
<term><option>--root=</option></term>
<listitem><para>Operate relative to the specified root directory, i.e. establish the
<literal>overlayfs</literal> mount not on the top-level host <filename>/usr/</filename> and
<filename>/opt/</filename> hierarchies for sysext or <filename>/etc/</filename> for confext,
but below some specified root directory.</para>
<xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<varlistentry>
<term><option>--force</option></term>
<listitem><para>When merging system extensions into <filename>/usr/</filename> and
<filename>/opt/</filename> for sysext and <filename>/etc/</filename> for confext,
ignore version incompatibilities, i.e. force merging regardless of
whether the version information included in the images matches the host or not.</para>
<xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<varlistentry>
<term><option>--image-policy=<replaceable>policy</replaceable></option></term>
<listitem><para>Takes an image policy string as argument, as per
<citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
policy is enforced when operating on system extension disk images. If not specified defaults to
<literal>root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent</literal>
for system extensions, i.e. only the root and <filename>/usr/</filename> file systems in the image
are used. For configuration extensions defaults to
<literal>root=verity+signed+encrypted+unprotected+absent</literal>. When run in the initrd and
operating on a system extension image stored in the <filename>/.extra/sysext/</filename> directory a
slightly stricter policy is used by default: <literal>root=signed+absent:usr=signed+absent</literal>,
see above for details.</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
<varlistentry>
<term><option>--mutable=<replaceable>BOOL</replaceable>|<replaceable>auto</replaceable>|<replaceable>import</replaceable></option></term>
<listitem><para>Set mutable mode.</para>
<variablelist>
<varlistentry>
<term><option>no</option></term>
<listitem><para>force immutable mode even with write routing directories present.
This is the default.</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
<varlistentry>
<term><option>auto</option></term>
<listitem><para>enable mutable mode individually for <filename>/usr/</filename>,
<filename>/opt/</filename>, and <filename>/etc/</filename> if write routing sub-directories
or symlinks are present in <filename>/var/lib/extensions.mutable/</filename>; disable otherwise.
See "Mutability" above for more information on write routing.</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
<varlistentry>
<term><option>yes</option></term>
<listitem><para>force mutable mode. Write routing directories will be created in
<filename>/var/lib/extensions.mutable/</filename> if not present.</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
<varlistentry>
<term><option>import</option></term>
<listitem><para>immutable mode, but with contents of write routing directories in
<filename>/var/lib/extensions.mutable/</filename> also merged into the host file system.</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
<varlistentry>
<term><option>ephemeral</option></term>
<listitem><para>force mutable mode, but with contents of write routing directories in
<filename>/var/lib/extensions.mutable/</filename> being ignored, and modifications of the host
file system being discarded after unmerge.</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
<varlistentry>
<term><option>ephemeral-import</option></term>
<listitem><para>force mutable mode, with contents of write routing directories in
<filename>/var/lib/extensions.mutable/</filename> being merged into the host file system, but
with the modifications made to the host file system being discarded after unmerge.</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
</variablelist>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
<varlistentry>
<term><option>--noexec=<replaceable>BOOL</replaceable></option></term>
<listitem><para>When merging configuration extensions into <filename>/etc/</filename> the
<literal>MS_NOEXEC</literal> mount flag is used by default. This option can be used to disable
it.</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
<varlistentry>
<term><option>--no-reload</option></term>
<listitem>
<para>When used with <command>merge</command>,
<command>unmerge</command> or <command>refresh</command>, do not reload daemon
after executing the changes even if an extension that is applied requires a reload via the
<varname>EXTENSION_RELOAD_MANAGER=</varname> set to 1.</para>
<xi:include href="version-info.xml" xpointer="v255"/>
</listitem>
</varlistentry>
<xi:include href="standard-options.xml" xpointer="no-pager" />
<xi:include href="standard-options.xml" xpointer="no-legend" />
<xi:include href="standard-options.xml" xpointer="json" />
</variablelist>
</refsect1>
<refsect1>
<title>Exit status</title>
<para>On success, 0 is returned.</para>
</refsect1>
<refsect1>
<title>See Also</title>
<para><simplelist type="inline">
<member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
<member><citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
<member><citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
<member><citerefentry><refentrytitle>importctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
</simplelist></para>
</refsect1>
</refentry>