man/systemd-sysext.xml

   1 <?xml version='1.0'?> <!--*-nxml-*-->
   2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   3   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
   4 <!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
   5
   6 <refentry id="systemd-sysext"
   7     xmlns:xi="http://www.w3.org/2001/XInclude">
   8
   9   <refentryinfo>
  10     <title>systemd-sysext</title>
  11     <productname>systemd</productname>
  12   </refentryinfo>
  13
  14   <refmeta>
  15     <refentrytitle>systemd-sysext</refentrytitle>
  16     <manvolnum>8</manvolnum>
  17   </refmeta>
  18
  19   <refnamediv>
  20     <refname>systemd-sysext</refname>
  21     <refname>systemd-sysext.service</refname>
  22     <refname>systemd-confext</refname>
  23     <refname>systemd-confext.service</refname>
  24     <refpurpose>Activates System Extension Images</refpurpose>
  25   </refnamediv>
  26
  27   <refsynopsisdiv>
  28     <cmdsynopsis>
  29       <command>systemd-sysext</command>
  30       <arg choice="opt" rep="repeat">OPTIONS</arg>
  31       <arg choice="plain">COMMAND</arg>
  32     </cmdsynopsis>
  33
  34     <para><literallayout><filename>systemd-sysext.service</filename></literallayout></para>
  35
  36     <cmdsynopsis>
  37       <command>systemd-confext</command>
  38       <arg choice="opt" rep="repeat">OPTIONS</arg>
  39       <arg choice="plain">COMMAND</arg>
  40     </cmdsynopsis>
  41
  42     <para><literallayout><filename>systemd-confext.service</filename></literallayout></para>
  43
  44   </refsynopsisdiv>
  45
  46   <refsect1>
  47     <title>Description</title>
  48
  49     <para><command>systemd-sysext</command> activates/deactivates system extension images. System extension
  50     images may – dynamically at runtime — extend the <filename>/usr/</filename> and
  51     <filename>/opt/</filename> directory hierarchies with additional files. This is particularly useful on
  52     immutable system images where a <filename>/usr/</filename> and/or <filename>/opt/</filename> hierarchy
  53     residing on a read-only file system shall be extended temporarily at runtime without making any
  54     persistent modifications.</para>
  55
  56     <para>System extension images should contain files and directories similar in fashion to regular
  57     operating system tree. When one or more system extension images are activated, their
  58     <filename>/usr/</filename> and <filename>/opt/</filename> hierarchies are combined via
  59     <literal>overlayfs</literal> with the same hierarchies of the host OS, and the host
  60     <filename>/usr/</filename> and <filename>/opt/</filename> overmounted with it ("merging"). When they are
  61     deactivated, the mount point is disassembled — again revealing the unmodified original host version of
  62     the hierarchy ("unmerging"). Merging thus makes the extension's resources suddenly appear below the
  63     <filename>/usr/</filename> and <filename>/opt/</filename> hierarchies as if they were included in the
  64     base OS image itself. Unmerging makes them disappear again, leaving in place only the files that were
  65     shipped with the base OS image itself.</para>
  66
  67     <para>Files and directories contained in the extension images outside of the <filename>/usr/</filename>
  68     and <filename>/opt/</filename> hierarchies are <emphasis>not</emphasis> merged, and hence have no effect
  69     when included in a system extension image. In particular, files in the <filename>/etc/</filename> and
  70     <filename>/var/</filename> included in a system extension image will <emphasis>not</emphasis> appear in
  71     the respective hierarchies after activation.</para>
  72
  73     <para>System extension images are strictly read-only, and the host <filename>/usr/</filename> and
  74     <filename>/opt/</filename> hierarchies become read-only too while they are activated.</para>
  75
  76     <para>System extensions are supposed to be purely additive, i.e. they are supposed to include only files
  77     that do not exist in the underlying basic OS image. However, the underlying mechanism (overlayfs) also
  78     allows overlaying or removing files, but it is recommended not to make use of this.</para>
  79
  80     <para>System extension images may be provided in the following formats:</para>
  81
  82     <orderedlist>
  83       <listitem><para>Plain directories or btrfs subvolumes containing the OS tree</para></listitem>
  84       <listitem><para>Disk images with a GPT disk label, following the <ulink
  85       url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink></para></listitem>
  86       <listitem><para>Disk images lacking a partition table, with a naked Linux file system (e.g. erofs,
  87       squashfs or ext4)</para></listitem>
  88     </orderedlist>
  89
  90     <para>These image formats are the same ones that
  91     <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
  92     supports via its <option>--directory=</option>/<option>--image=</option> switches and those that the
  93     service manager supports via <option>RootDirectory=</option>/<option>RootImage=</option>. Similar to
  94     them they may optionally carry Verity authentication information.</para>
  95
  96     <para>System extensions are searched for in the directories
  97     <filename>/etc/extensions/</filename>, <filename>/run/extensions/</filename> and
  98     <filename>/var/lib/extensions/</filename>. The first two listed directories are not suitable for
  99     carrying large binary images, however are still useful for carrying symlinks to them. The primary place
 100     for installing system extensions is <filename>/var/lib/extensions/</filename>. Any directories found in
 101     these search directories are considered directory based extension images; any files with the
 102     <filename>.raw</filename> suffix are considered disk image based extension images. When invoked in the
 103     initrd, the additional directory <filename>/.extra/sysext/</filename> is included in the directories that
 104     are searched for extension images. Note however, that by default a tighter image policy applies to images
 105     found there, though, see below. This directory is populated by
 106     <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> with
 107     extension images found in the system's EFI System Partition.</para>
 108
 109     <para>During boot OS extension images are activated automatically, if the
 110     <filename>systemd-sysext.service</filename> is enabled. Note that this service runs only after the
 111     underlying file systems where system extensions may be located have been mounted. This means they are not
 112     suitable for shipping resources that are processed by subsystems running in earliest boot. Specifically,
 113     OS extension images are not suitable for shipping system services or
 114     <citerefentry><refentrytitle>systemd-sysusers</refentrytitle><manvolnum>8</manvolnum></citerefentry>
 115     definitions. See the <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>
 116     for a simple mechanism for shipping system services in disk images, in a similar fashion to OS
 117     extensions. Note the different isolation on these two mechanisms: while system extension directly extend
 118     the underlying OS image with additional files that appear in a way very similar to as if they were
 119     shipped in the OS image itself and thus imply no security isolation, portable services imply service
 120     level sandboxing in one way or another. The <filename>systemd-sysext.service</filename> service is
 121     guaranteed to finish start-up before <filename>basic.target</filename> is reached; i.e. at the time
 122     regular services initialize (those which do not use <varname>DefaultDependencies=no</varname>), the files
 123     and directories system extensions provide are available in <filename>/usr/</filename> and
 124     <filename>/opt/</filename> and may be accessed.</para>
 125
 126     <para>Note that there is no concept of enabling/disabling installed system extension images: all
 127     installed extension images are automatically activated at boot. However, you can place an empty directory
 128     named like the extension (no <filename>.raw</filename>) in <filename>/etc/extensions/</filename> to "mask"
 129     an extension with the same name in a system folder with lower precedence.</para>
 130
 131     <para>A simple mechanism for version compatibility is enforced: a system extension image must carry a
 132     <filename>/usr/lib/extension-release.d/extension-release.<replaceable>NAME</replaceable></filename>
 133     file, which must match its image name, that is compared with the host <filename>os-release</filename>
 134     file: the contained <varname>ID=</varname> fields have to match unless <literal>_any</literal> is set
 135     for the extension. If the extension <varname>ID=</varname> is not <literal>_any</literal>, the
 136     <varname>SYSEXT_LEVEL=</varname> field (if defined) has to match. If the latter is not defined, the
 137     <varname>VERSION_ID=</varname> field has to match instead. If the extension defines the
 138     <varname>ARCHITECTURE=</varname> field and the value is not <literal>_any</literal> it has to match the kernel's
 139     architecture reported by <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
 140     but the used architecture identifiers are the same as for <varname>ConditionArchitecture=</varname>
 141     described in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 142     <varname>EXTENSION_RELOAD_MANAGER=</varname> can be set to 1 if the extension requires a service manager reload after application
 143     of the extension. Note that the for the reasons mentioned earlier:
 144     <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> remain
 145     the recommended way to ship system services.
 146
 147     System extensions should not ship a <filename>/usr/lib/os-release</filename> file (as that would be merged
 148     into the host <filename>/usr/</filename> tree, overriding the host OS version data, which is not desirable).
 149     The <filename>extension-release</filename> file follows the same format and semantics, and carries the same
 150     content, as the <filename>os-release</filename> file of the OS, but it describes the resources carried
 151     in the extension image.</para>
 152
 153     <para>The <command>systemd-confext</command> concept follows the same principle as the
 154     <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 155     functionality but instead of working on <filename>/usr</filename> and <filename>/opt</filename>,
 156     <command>confext</command> will extend only <filename>/etc</filename>. Files and directories contained
 157     in the confext images outside of the <filename>/etc/</filename> hierarchy are <emphasis>not</emphasis>
 158     merged, and hence have no effect when included in the image. Formats for these images are of the
 159     same as sysext images. The merged hierarchy will be mounted with <literal>nosuid</literal> and
 160     (if not disabled via <option>--noexec=false</option>) <literal>noexec</literal>.</para>
 161
 162     <para>Confexts are looked for in the directories <filename>/run/confexts/</filename>,
 163     <filename>/var/lib/confexts/</filename>, <filename>/usr/lib/confexts/</filename> and
 164     <filename>/usr/local/lib/confexts/</filename>. The first listed directory is not suitable for
 165     carrying large binary images, however is still useful for carrying symlinks to them. The primary place
 166     for installing configuration extensions is <filename>/var/lib/confexts/</filename>. Any directories found
 167     in these search directories are considered directory based confext images; any files with the
 168     <filename>.raw</filename> suffix are considered disk image based confext images.</para>
 169
 170     <para>Again, just like sysext images, the confext images will contain a
 171     <filename>/etc/extension-release.d/extension-release.<replaceable>NAME</replaceable></filename>
 172     file, which must match the image name (with the usual escape hatch of
 173     the <varname>user.extension-release.strict</varname>
 174     <citerefentry project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
 175     and again with content being one or more of <varname>ID=</varname>, <varname>VERSION_ID=</varname>, and
 176     <varname>CONFEXT_LEVEL</varname>. Confext images will then be checked and matched against the base OS
 177     layer.</para>
 178   </refsect1>
 179
 180   <refsect1>
 181     <title>Uses</title>
 182
 183     <para>The primary use case for system images are immutable environments where debugging and development
 184     tools shall optionally be made available, but not included in the immutable base OS image itself (e.g.
 185     <citerefentry project='man-pages'><refentrytitle>strace</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 186     and
 187     <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 188     shall be an optionally installable addition in order to make debugging/development easier). System
 189     extension images should not be misunderstood as a generic software packaging framework, as no dependency
 190     scheme is available: system extensions should carry all files they need themselves, except for those
 191     already shipped in the underlying host system image. Typically, system extension images are built at the
 192     same time as the base OS image — within the same build system.</para>
 193
 194     <para>Another use case for the system extension concept is temporarily overriding OS supplied resources
 195     with newer ones, for example to install a locally compiled development version of some low-level
 196     component over the immutable OS image without doing a full OS rebuild or modifying the nominally
 197     immutable image. (e.g. "install" a locally built package with <command>DESTDIR=/var/lib/extensions/mytest
 198     make install &amp;&amp; systemd-sysext refresh</command>, making it available in
 199     <filename>/usr/</filename> as if it was installed in the OS image itself.) This case works regardless if
 200     the underlying host <filename>/usr/</filename> is managed as immutable disk image or is a traditional
 201     package manager controlled (i.e. writable) tree.</para>
 202
 203     <para>For the confext case, the OSConfig project aims to perform runtime reconfiguration of OS services.
 204     Sometimes, there is a need to swap certain configuration parameter values or restart only a specific
 205     service without deployment of new code or a complete OS deployment. In other words, we want to be able
 206     to tie the most frequently configured options to runtime updateable flags that can be changed without a
 207     system reboot. This will help reduce servicing times when there is a need for changing the OS configuration.</para></refsect1>
 208
 209   <refsect1>
 210     <title>Commands</title>
 211
 212     <para>The following commands are understood by both the sysext and confext concepts:</para>
 213
 214     <variablelist>
 215       <varlistentry>
 216         <term><option>status</option></term>
 217
 218         <listitem><para>When invoked without any command verb, or when <option>status</option> is specified
 219         the current merge status is shown, separately (for both <filename>/usr/</filename> and
 220         <filename>/opt/</filename> of sysext and for <filename>/etc/</filename> of confext).</para>
 221
 222         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 223       </varlistentry>
 224
 225       <varlistentry>
 226         <term><option>merge</option></term>
 227         <listitem><para>Merges all currently installed system extension images into
 228         <filename>/usr/</filename> and <filename>/opt/</filename>, by overmounting these hierarchies with an
 229         <literal>overlayfs</literal> file system combining the underlying hierarchies with those included in
 230         the extension images. This command will fail if the hierarchies are already merged. For confext, the merge
 231         happens into the <filename>/etc/</filename> directory instead.</para>
 232
 233         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 234       </varlistentry>
 235
 236       <varlistentry>
 237         <term><option>unmerge</option></term>
 238         <listitem><para>Unmerges all currently installed system extension images from
 239         <filename>/usr/</filename> and <filename>/opt/</filename> for sysext and <filename>/etc/</filename>,
 240         for confext, by unmounting the <literal>overlayfs</literal> file systems created by <option>merge</option>
 241         prior.</para>
 242
 243         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 244       </varlistentry>
 245
 246       <varlistentry>
 247         <term><option>refresh</option></term>
 248         <listitem><para>A combination of <option>unmerge</option> and <option>merge</option>: if already
 249         mounted the existing <literal>overlayfs</literal> instance is unmounted temporarily, and then
 250         replaced by a new version. This command is useful after installing/removing system extension images,
 251         in order to update the <literal>overlayfs</literal> file system accordingly. If no system extensions
 252         are installed when this command is executed, the equivalent of <option>unmerge</option> is executed,
 253         without establishing any new <literal>overlayfs</literal> instance.
 254         Note that currently there's a brief moment where neither the old nor the new <literal>overlayfs</literal>
 255         file system is mounted. This implies that all resources supplied by a system extension will briefly
 256         disappear — even if it exists continuously during the refresh operation.</para>
 257
 258         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 259       </varlistentry>
 260
 261       <varlistentry>
 262         <term><option>list</option></term>
 263
 264         <listitem><para>A brief list of installed extension images is shown.</para>
 265
 266         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 267       </varlistentry>
 268
 269       <xi:include href="standard-options.xml" xpointer="help" />
 270       <xi:include href="standard-options.xml" xpointer="version" />
 271     </variablelist>
 272   </refsect1>
 273
 274   <refsect1>
 275     <title>Options</title>
 276
 277     <variablelist>
 278       <varlistentry>
 279         <term><option>--root=</option></term>
 280
 281         <listitem><para>Operate relative to the specified root directory, i.e. establish the
 282         <literal>overlayfs</literal> mount not on the top-level host <filename>/usr/</filename> and
 283         <filename>/opt/</filename> hierarchies for sysext or <filename>/etc/</filename> for confext,
 284         but below some specified root directory.</para>
 285
 286         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 287       </varlistentry>
 288
 289       <varlistentry>
 290         <term><option>--force</option></term>
 291
 292         <listitem><para>When merging system extensions into <filename>/usr/</filename> and
 293         <filename>/opt/</filename> for sysext and <filename>/etc/</filename> for confext,
 294         ignore version incompatibilities, i.e. force merging regardless of
 295         whether the version information included in the images matches the host or not.</para>
 296
 297         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 298       </varlistentry>
 299
 300       <varlistentry>
 301         <term><option>--image-policy=<replaceable>policy</replaceable></option></term>
 302
 303         <listitem><para>Takes an image policy string as argument, as per
 304         <citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
 305         policy is enforced when operating on system extension disk images. If not specified defaults to
 306         <literal>root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent</literal>
 307         for system extensions, i.e. only the root and <filename>/usr/</filename> file systems in the image
 308         are used. For configuration extensions defaults to
 309         <literal>root=verity+signed+encrypted+unprotected+absent</literal>. When run in the initrd and
 310         operating on a system extension image stored in the <filename>/.extra/sysext/</filename> directory a
 311         slightly stricter policy is used by default: <literal>root=signed+absent:usr=signed+absent</literal>,
 312         see above for details.</para>
 313
 314         <xi:include href="version-info.xml" xpointer="v254"/></listitem>
 315       </varlistentry>
 316
 317       <varlistentry>
 318         <term><option>--noexec=</option><replaceable>BOOL</replaceable></term>
 319
 320         <listitem><para>When merging configuration extensions into <filename>/etc/</filename> the
 321         <literal>MS_NOEXEC</literal> mount flag is used by default. This option can be used to disable
 322         it.</para>
 323
 324         <xi:include href="version-info.xml" xpointer="v254"/></listitem>
 325       </varlistentry>
 326
 327       <varlistentry>
 328         <term><option>--no-reload</option></term>
 329
 330         <listitem>
 331           <para>When used with <command>merge</command>,
 332           <command>unmerge</command> or <command>refresh</command>, do not reload daemon
 333           after executing the changes even if an extension that is applied requires a reload via the
 334           <varname>EXTENSION_RELOAD_MANAGER=</varname> set to 1.</para>
 335
 336         <xi:include href="version-info.xml" xpointer="v255"/>
 337         </listitem>
 338       </varlistentry>
 339
 340       <xi:include href="standard-options.xml" xpointer="no-pager" />
 341       <xi:include href="standard-options.xml" xpointer="no-legend" />
 342       <xi:include href="standard-options.xml" xpointer="json" />
 343     </variablelist>
 344   </refsect1>
 345
 346   <refsect1>
 347     <title>Exit status</title>
 348
 349     <para>On success, 0 is returned.</para>
 350   </refsect1>
 351
 352   <refsect1>
 353     <title>See Also</title>
 354     <para>
 355       <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 356       <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 357       <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 358     </para>
 359   </refsect1>
 360
 361 </refentry>