diff options
Diffstat (limited to 'man')
| -rw-r--r-- | man/systemd-nspawn.xml | 33 | ||||
| -rw-r--r-- | man/systemd.exec.xml | 78 | ||||
| -rw-r--r-- | man/systemd.swap.xml | 8 | ||||
| -rw-r--r-- | man/systemd.unit.xml | 8 |
4 files changed, 80 insertions, 47 deletions
diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml index 5e671d21e8..17c14e9f22 100644 --- a/man/systemd-nspawn.xml +++ b/man/systemd-nspawn.xml @@ -256,10 +256,14 @@ <listitem><para>Takes a data integrity (dm-verity) root hash specified in hexadecimal. This option enables data integrity checks using dm-verity, if the used image contains the appropriate integrity data (see above). The - specified hash must match the root hash of integrity data, and is usually at least 256bits (and hence 64 - hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but a file with - the <filename>.roothash</filename> suffix is found next to the image file, bearing otherwise the same name the - root hash is read from it and automatically used.</para></listitem> + specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64 + formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but + the image file carries the <literal>user.verity.roothash</literal> extended file attribute (see <citerefentry + project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>), then the root + hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or + is not supported by the underlying file system), but a file with the <filename>.roothash</filename> suffix is + found next to the image file, bearing otherwise the same name, the root hash is read from it and automatically + used, also as formatted hexadecimal characters.</para></listitem> </varlistentry> <varlistentry> @@ -346,8 +350,9 @@ in the container's file system namespace.</para> <para>This is for containers which have several bootable directories in them; for example, several - <ulink url="https://ostree.readthedocs.io/en/latest/">OSTree</ulink> deployments. It emulates the behavior of the boot - loader and initial RAM disk which normally select which directory to mount as root and start the container's PID 1 in.</para></listitem> + <ulink url="https://ostree.readthedocs.io/en/latest/">OSTree</ulink> deployments. It emulates the behavior of + the boot loader and initial RAM disk which normally select which directory to mount as the root and start the + container's PID 1 in.</para></listitem> </varlistentry> <varlistentry> @@ -1041,8 +1046,9 @@ <example> <title>Download a Fedora image and start a shell in it</title> - <programlisting># machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/24/CloudImages/x86_64/images/Fedora-Cloud-Base-24-1.2.x86_64.raw.xz -# systemd-nspawn -M Fedora-Cloud-Base-24-1.2.x86_64.raw</programlisting> + <programlisting># machinectl pull-raw --verify=no \ + https://download.fedoraproject.org/pub/fedora/linux/releases/25/CloudImages/x86_64/images/Fedora-Cloud-Base-25-1.3.x86_64.raw.xz +# systemd-nspawn -M Fedora-Cloud-Base-25-1.3.x86_64.raw</programlisting> <para>This downloads an image using <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> @@ -1052,7 +1058,9 @@ <example> <title>Build and boot a minimal Fedora distribution in a container</title> - <programlisting># dnf -y --releasever=23 --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora --enablerepo=updates install systemd passwd dnf fedora-release vim-minimal + <programlisting># dnf -y --releasever=25 --installroot=/srv/mycontainer \ + --disablerepo='*' --enablerepo=fedora --enablerepo=updates install \ + systemd passwd dnf fedora-release vim-minimal # systemd-nspawn -bD /srv/mycontainer</programlisting> <para>This installs a minimal Fedora distribution into the @@ -1095,13 +1103,16 @@ <title>Run a container with SELinux sandbox security contexts</title> <programlisting># chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container -# systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh</programlisting> +# systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 \ + -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh</programlisting> </example> <example> <title>Run a container with an OSTree deployment</title> - <programlisting># systemd-nspawn -b -i ~/image.raw --pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot --bind=+/sysroot/ostree/deploy/$OS/var:/var</programlisting> + <programlisting># systemd-nspawn -b -i ~/image.raw \ + --pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \ + --bind=+/sysroot/ostree/deploy/$OS/var:/var</programlisting> </example> </refsect1> diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index fd47b0a20a..2ce0c7d246 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -86,12 +86,10 @@ <para>A few execution parameters result in additional, automatic dependencies to be added.</para> - <para>Units with <varname>WorkingDirectory=</varname> or - <varname>RootDirectory=</varname> set automatically gain - dependencies of type <varname>Requires=</varname> and - <varname>After=</varname> on all mount units required to access - the specified paths. This is equivalent to having them listed - explicitly in <varname>RequiresMountsFor=</varname>.</para> + <para>Units with <varname>WorkingDirectory=</varname>, <varname>RootDirectory=</varname> or + <varname>RootImage=</varname> set automatically gain dependencies of type <varname>Requires=</varname> and + <varname>After=</varname> on all mount units required to access the specified paths. This is equivalent to having + them listed explicitly in <varname>RequiresMountsFor=</varname>.</para> <para>Similar, units with <varname>PrivateTmp=</varname> enabled automatically get mount unit dependencies for all mounts required to access <filename>/tmp</filename> and <filename>/var/tmp</filename>. They will also gain an @@ -117,9 +115,10 @@ <varname>User=</varname> is used. If not set, defaults to the root directory when systemd is running as a system instance and the respective user's home directory if run as user. If the setting is prefixed with the <literal>-</literal> character, a missing working directory is not considered fatal. If - <varname>RootDirectory=</varname> is not set, then <varname>WorkingDirectory=</varname> is relative to the root - of the system running the service manager. Note that setting this parameter might result in additional - dependencies to be added to the unit (see above).</para></listitem> + <varname>RootDirectory=</varname>/<varname>RootImage=</varname> is not set, then + <varname>WorkingDirectory=</varname> is relative to the root of the system running the service manager. Note + that setting this parameter might result in additional dependencies to be added to the unit (see + above).</para></listitem> </varlistentry> <varlistentry> @@ -132,8 +131,33 @@ the <function>chroot()</function> jail. Note that setting this parameter might result in additional dependencies to be added to the unit (see above).</para> - <para>The <varname>PrivateUsers=</varname> setting is particularly useful in conjunction with - <varname>RootDirectory=</varname>. For details, see below.</para></listitem> + <para>The <varname>MountAPIVFS=</varname> and <varname>PrivateUsers=</varname> settings are particularly useful + in conjunction with <varname>RootDirectory=</varname>. For details, see below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RootImage=</varname></term> + <listitem><para>Takes a path to a block device node or regular file as argument. This call is similar to + <varname>RootDirectory=</varname> however mounts a file system hierarchy from a block device node or loopack + file instead of a directory. The device node or file system image file needs to contain a file system without a + partition table, or a file system within an MBR/MS-DOS or GPT partition table with only a single + Linux-compatible partition, or a set of file systems within a GPT partition table that follows the <ulink + url="http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/">Discoverable Partitions + Specification</ulink>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MountAPIVFS=</varname></term> + + <listitem><para>Takes a boolean argument. If on, a private mount namespace for the unit's processes is created + and the API file systems <filename>/proc</filename>, <filename>/sys</filename>, and <filename>/dev</filename> + are mounted inside of it, unless they are already mounted. Note that this option has no effect unless used in + conjunction with <varname>RootDirectory=</varname>/<varname>RootImage=</varname> as these three mounts are + generally mounted in the host anyway, and unless the root directory is changed, the private mount namespace + will be a 1:1 copy of the host's, and include these three mounts. Note that the <filename>/dev</filename> file + system of the host is bind mounted if this option is used without <varname>PrivateDevices=</varname>. To run + the service with a private, minimal version of <filename>/dev/</filename>, combine this option with + <varname>PrivateDevices=</varname>.</para></listitem> </varlistentry> <varlistentry> @@ -938,7 +962,7 @@ access a process might have to the file system hierarchy. Each setting takes a space-separated list of paths relative to the host's root directory (i.e. the system running the service manager). Note that if paths contain symlinks, they are resolved relative to the root directory set with - <varname>RootDirectory=</varname>.</para> + <varname>RootDirectory=</varname>/<varname>RootImage=</varname>.</para> <para>Paths listed in <varname>ReadWritePaths=</varname> are accessible from within the namespace with the same access modes as from outside of it. Paths listed in <varname>ReadOnlyPaths=</varname> are accessible for @@ -957,9 +981,10 @@ <para>Paths in <varname>ReadWritePaths=</varname>, <varname>ReadOnlyPaths=</varname> and <varname>InaccessiblePaths=</varname> may be prefixed with <literal>-</literal>, in which case they will be ignored when they do not exist. If prefixed with <literal>+</literal> the paths are taken relative to the root - directory of the unit, as configured with <varname>RootDirectory=</varname>, instead of relative to the root - directory of the host (see above). When combining <literal>-</literal> and <literal>+</literal> on the same - path make sure to specify <literal>-</literal> first, and <literal>+</literal> second.</para> + directory of the unit, as configured with <varname>RootDirectory=</varname>/<varname>RootImage=</varname>, + instead of relative to the root directory of the host (see above). When combining <literal>-</literal> and + <literal>+</literal> on the same path make sure to specify <literal>-</literal> first, and <literal>+</literal> + second.</para> <para>Note that using this setting will disconnect propagation of mounts from the service to the host (propagation in the opposite direction continues to work). This means that this setting may not be used for @@ -990,9 +1015,9 @@ that in this case both read-only and regular bind mounts are reset, regardless which of the two settings is used.</para> - <para>This option is particularly useful when <varname>RootDirectory=</varname> is used. In this case the - source path refers to a path on the host file system, while the destination path refers to a path below the - root directory of the unit.</para></listitem> + <para>This option is particularly useful when <varname>RootDirectory=</varname>/<varname>RootImage=</varname> + is used. In this case the source path refers to a path on the host file system, while the destination path + refers to a path below the root directory of the unit.</para></listitem> </varlistentry> <varlistentry> @@ -1080,10 +1105,10 @@ such as <varname>CapabilityBoundingSet=</varname> will affect only the latter, and there's no way to acquire additional capabilities in the host's user namespace. Defaults to off.</para> - <para>This setting is particularly useful in conjunction with <varname>RootDirectory=</varname>, as the need to - synchronize the user and group databases in the root directory and on the host is reduced, as the only users - and groups who need to be matched are <literal>root</literal>, <literal>nobody</literal> and the unit's own - user and group.</para></listitem> + <para>This setting is particularly useful in conjunction with + <varname>RootDirectory=</varname>/<varname>RootImage=</varname>, as the need to synchronize the user and group + databases in the root directory and on the host is reduced, as the only users and groups who need to be matched + are <literal>root</literal>, <literal>nobody</literal> and the unit's own user and group.</para></listitem> </varlistentry> <varlistentry> @@ -1554,11 +1579,10 @@ <citerefentry><refentrytitle>setns</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls, taking the specified flags parameters into account. Note that — if this option is used — in addition to restricting creation and switching of the specified types of namespaces (or all of them, if true) access to the - <function>setns()</function> system call with a zero flags parameter is prohibited. - If running in user mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> - capability (e.g. setting <varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> - is implied. - </para></listitem> + <function>setns()</function> system call with a zero flags parameter is prohibited. This setting is only + supported on x86, x86-64, s390 and s390x, and enforces no restrictions on other architectures. If running in user + mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting + <varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> is implied. </para></listitem> </varlistentry> <varlistentry> diff --git a/man/systemd.swap.xml b/man/systemd.swap.xml index d2c2027228..184abff260 100644 --- a/man/systemd.swap.xml +++ b/man/systemd.swap.xml @@ -94,10 +94,10 @@ dependencies on the device units or the mount units of the files they are activated from.</para> - <para>Swap units with <varname>DefaultDependencies=</varname> in the <literal>[Unit]</literal> section enabled - implicitly acquire a <varname>Conflicts=</varname> and an <varname>After=</varname> dependency on - <filename>umount.target</filename> so that they are deactivated at shutdown, unless - <varname>DefaultDependencies=no</varname> is specified.</para> + <para>Swap units with <varname>DefaultDependencies=</varname> set to its default <option>yes</option> value in the + <literal>[Unit]</literal> section enabled implicitly acquire a <varname>Conflicts=</varname> and a + <varname>Before=</varname> dependency on <filename>umount.target</filename> so that they are deactivated at + shutdown as well as a <varname>Before=swap.target</varname> dependency.</para> <para>Additional implicit dependencies may be added as result of execution and resource control parameters as documented in diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index eb00a2e88e..417840e6c2 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -631,11 +631,9 @@ all mount units required to access the specified path.</para> <para>Mount points marked with <option>noauto</option> are not - mounted automatically and will be ignored for the purposes of - this option. If such a mount should be a requirement for this - unit, direct dependencies on the mount units may be added - (<varname>Requires=</varname> and <varname>After=</varname> or - some other combination). </para></listitem> + mounted automatically through <filename>local-fs.target</filename>, + but are still honored for the purposes of this option, i.e. they + will be pulled in by this unit.</para></listitem> </varlistentry> <varlistentry> |