Zbigniew Jędrzejewski-Szmek
parent
ab1a8ff57d
commit
211c99c761
|
|
@ -76,7 +76,7 @@
|
|||
<title>Setup environment to allow access to a program installed in
|
||||
<filename index="false">/opt/foo</filename></title>
|
||||
|
||||
<para><filename>/etc/environment.d/60-foo.conf</filename>:
|
||||
<para><filename index="false">/etc/environment.d/60-foo.conf</filename>:
|
||||
</para>
|
||||
<programlisting>
|
||||
FOO_DEBUG=force-software-gl,log-verbose
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@
|
|||
|
||||
<listitem><para>Takes a path to the resume device. Both
|
||||
persistent block device paths like
|
||||
<filename>/dev/disk/by-foo/bar</filename> and
|
||||
<filename index="false">/dev/disk/by-foo/bar</filename> and
|
||||
<citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>-style
|
||||
specifiers like <literal>FOO=bar</literal> are
|
||||
supported.</para></listitem>
|
||||
|
|
|
|||
|
|
@ -86,9 +86,9 @@
|
|||
<para>In order to migrate a home directory from a host <literal>foobar</literal> to another host
|
||||
<literal>quux</literal> it is hence sufficient to copy
|
||||
<filename>/var/lib/systemd/home/local.public</filename> from the host <literal>foobar</literal> to
|
||||
<literal>quux</literal>, maybe calling the file on the destination
|
||||
<filename>/var/lib/systemd/home/foobar.public</filename>, reflecting the origin of the key. If the user
|
||||
record should be modifiable on <literal>quux</literal> the pair
|
||||
<literal>quux</literal>, maybe calling the file on the destination <filename
|
||||
index="false">/var/lib/systemd/home/foobar.public</filename>, reflecting the origin of the key. If the
|
||||
user record should be modifiable on <literal>quux</literal> the pair
|
||||
<filename>/var/lib/systemd/home/local.public</filename> and
|
||||
<filename>/var/lib/systemd/home/local.private</filename> need to be copied from <literal>foobar</literal>
|
||||
to <literal>quux</literal>, and placed under the identical paths there, as currently only a single
|
||||
|
|
|
|||
|
|
@ -348,16 +348,17 @@
|
|||
terminated. When the mode parameter is specified as <option>no</option> (the default), the whole OS tree is
|
||||
made available writable (unless <option>--read-only</option> is specified, see above).</para>
|
||||
|
||||
<para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system (or
|
||||
<filename>/var/</filename> in case of <option>state</option>), and any other mounts placed in the hierarchy are
|
||||
unaffected — regardless if they are established automatically (e.g. the EFI system partition that might be
|
||||
mounted to <filename>/efi/</filename> or <filename>/boot/</filename>) or explicitly (e.g. through an additional
|
||||
command line option such as <option>--bind=</option>, see below). This means, even if
|
||||
<option>--volatile=overlay</option> is used changes to <filename>/efi/</filename> or
|
||||
<filename>/boot/</filename> are prohibited in case such a partition exists in the container image operated on,
|
||||
and even if <option>--volatile=state</option> is used the hypothetical file <filename>/etc/foobar</filename> is
|
||||
potentially writable if <option>--bind=/etc/foobar</option> if used to mount it from outside the read-only
|
||||
container <filename>/etc</filename> directory.</para>
|
||||
<para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system
|
||||
(or <filename>/var/</filename> in case of <option>state</option>), and any other mounts placed in the
|
||||
hierarchy are unaffected — regardless if they are established automatically (e.g. the EFI system
|
||||
partition that might be mounted to <filename>/efi/</filename> or <filename>/boot/</filename>) or
|
||||
explicitly (e.g. through an additional command line option such as <option>--bind=</option>, see
|
||||
below). This means, even if <option>--volatile=overlay</option> is used changes to
|
||||
<filename>/efi/</filename> or <filename>/boot/</filename> are prohibited in case such a partition
|
||||
exists in the container image operated on, and even if <option>--volatile=state</option> is used the
|
||||
hypothetical file <filename index="false">/etc/foobar</filename> is potentially writable if
|
||||
<option>--bind=/etc/foobar</option> if used to mount it from outside the read-only container
|
||||
<filename>/etc</filename> directory.</para>
|
||||
|
||||
<para>The <option>--ephemeral</option> option is closely related to this setting, and provides similar
|
||||
behaviour by making a temporary, ephemeral copy of the whole OS image and executing that. For further details,
|
||||
|
|
|
|||
|
|
@ -1275,7 +1275,7 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
|
|||
|
||||
<para>Example: if a system service unit has the following,
|
||||
<programlisting>RuntimeDirectory=foo/bar baz</programlisting>
|
||||
the service manager creates <filename>/run/foo</filename> (if it does not exist),
|
||||
the service manager creates <filename index='false'>/run/foo</filename> (if it does not exist),
|
||||
|
||||
<filename index='false'>/run/foo/bar</filename>, and <filename index='false'>/run/baz</filename>. The
|
||||
directories <filename index='false'>/run/foo/bar</filename> and
|
||||
|
|
|
|||
|
|
@ -1307,7 +1307,7 @@ ls</programlisting>
|
|||
<title>Simple service</title>
|
||||
|
||||
<para>The following unit file creates a service that will
|
||||
execute <filename>/usr/sbin/foo-daemon</filename>. Since no
|
||||
execute <filename index="false">/usr/sbin/foo-daemon</filename>. Since no
|
||||
<varname>Type=</varname> is specified, the default
|
||||
<varname>Type=</varname><option>simple</option> will be assumed.
|
||||
systemd will assume the unit to be started immediately after the
|
||||
|
|
|
|||
|
|
@ -862,8 +862,8 @@
|
|||
pulled in via a <option>Wants=</option> dependency of the storage daemon and thus generally not be
|
||||
part of any transaction unless a storage daemon is used. The instance name for instances of this
|
||||
template unit must be a properly escaped block device node path, e.g.
|
||||
<filename>blockdev@dev-mapper-foobar.target</filename> for the storage device
|
||||
<filename>/dev/mapper/foobar</filename>.</para></listitem>
|
||||
<filename index="false">blockdev@dev-mapper-foobar.target</filename> for the storage device
|
||||
<filename index="false">/dev/mapper/foobar</filename>.</para></listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><filename>cryptsetup-pre.target</filename></term>
|
||||
|
|
|
|||
|
|
@ -279,7 +279,7 @@
|
|||
<para>When the input qualifies as absolute file system path, this algorithm is extended slightly: the path to the
|
||||
root directory <literal>/</literal> is encoded as single dash <literal>-</literal>. In addition, any leading,
|
||||
trailing or duplicate <literal>/</literal> characters are removed from the string before transformation. Example:
|
||||
<filename>/foo//bar/baz/</filename> becomes <literal>foo-bar-baz</literal>.</para>
|
||||
<filename index="false">/foo//bar/baz/</filename> becomes <literal>foo-bar-baz</literal>.</para>
|
||||
|
||||
<para>This escaping is fully reversible, as long as it is known whether the escaped string was a path (the
|
||||
unescaping results are different for paths and non-path strings). The
|
||||
|
|
@ -1922,7 +1922,7 @@ ExecStart=/usr/sbin/foo-daemon
|
|||
|
||||
<para>After running <command>systemctl enable</command>, a
|
||||
symlink
|
||||
<filename>/etc/systemd/system/multi-user.target.wants/foo.service</filename>
|
||||
<filename index="false">/etc/systemd/system/multi-user.target.wants/foo.service</filename>
|
||||
linking to the actual unit will be created. It tells systemd to
|
||||
pull in the unit when starting
|
||||
<filename>multi-user.target</filename>. The inverse
|
||||
|
|
|
|||
Loading…
Reference in New Issue