mirrors/systemd
0
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-23 10:13:34 +08:00
Code Issues Packages Projects Releases Wiki Activity

man: do not index various /foobar/ paths

Browse Source 
For #17177.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2020-09-29 10:04:12 +02:00
parent ab1a8ff57d
commit 211c99c761
8 changed files with 22 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
man/environment.d.xml
View File

@ -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

2
man/systemd-hibernate-resume-generator.xml
View File

@ -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>

6
man/systemd-homed.service.xml
View File

@ -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

21
man/systemd-nspawn.xml
View File

@ -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,

2
man/systemd.exec.xml
View File

@ -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

2
man/systemd.service.xml
View File

@ -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

4
man/systemd.special.xml
View File

@ -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>

4
man/systemd.unit.xml
View File

@ -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