mirror of
https://github.com/systemd/systemd
synced 2024-10-04 15:21:01 +00:00
man: fix assorted issues reported by the manpage-l10n project
Fixes #20297.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek
parent
d1ae38d85a
commit
be0d27ee0c
|
|
@ -240,8 +240,8 @@
|
|||
<varlistentry>
|
||||
<term><option>--make-machine-id-directory=yes|no|auto</option></term>
|
||||
<listitem><para>Control creation and deletion of the top-level machine ID directory on the file
|
||||
system containing boot loader entries (i.e. beneath the file system returned by
|
||||
<option>--print-boot-path</option> above) during <option>install</option> and
|
||||
system containing boot loader entries (i.e. beneath the file system returned by the
|
||||
<option>--print-boot-path</option> option, see above) during <option>install</option> and
|
||||
<option>remove</option>, respectively. <literal>auto</literal> is equivalent to
|
||||
<literal>yes</literal> if <filename>/etc/machine-id</filename> resides on a filesystem other than
|
||||
tmpfs and <literal>no</literal> otherwise (in the latter case the machine ID is likely transient and
|
||||
|
|
|
|||
|
|
@ -83,12 +83,9 @@
|
|||
<varlistentry>
|
||||
<term><varname>ProcessSizeMax=</varname></term>
|
||||
|
||||
<listitem><para>The maximum size in bytes of a core
|
||||
which will be processed. Core dumps exceeding this size
|
||||
may be stored, but the backtrace will not be generated.
|
||||
Like other sizes in this same config file, the usual
|
||||
suffixes to the base of 1024 are allowed (B, K, M,
|
||||
G, T, P, and E.)</para>
|
||||
<listitem><para>The maximum size in bytes of a core which will be processed. Core dumps exceeding
|
||||
this size may be stored, but the backtrace will not be generated. Like other sizes in this same
|
||||
config file, the usual suffixes to the base of 1024 are allowed (B, K, M, G, T, P, and E).</para>
|
||||
|
||||
<para>Setting <varname>Storage=none</varname> and <varname>ProcessSizeMax=0</varname>
|
||||
disables all coredump handling except for a log entry.</para>
|
||||
|
|
@ -99,9 +96,8 @@
|
|||
<term><varname>ExternalSizeMax=</varname></term>
|
||||
<term><varname>JournalSizeMax=</varname></term>
|
||||
|
||||
<listitem><para>The maximum (compressed or uncompressed) size in bytes of a
|
||||
core to be saved. Unit suffixes are allowed just as in
|
||||
<option>ProcessSizeMax=</option></para></listitem>.
|
||||
<listitem><para>The maximum (compressed or uncompressed) size in bytes of a core to be saved. Unit
|
||||
suffixes are allowed just as in <option>ProcessSizeMax=</option>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
@ -120,9 +116,8 @@
|
|||
by core dumps might temporarily exceed these limits while
|
||||
core dumps are processed. Note that old core dumps are also
|
||||
removed based on time via
|
||||
<citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Set
|
||||
either value to 0 to turn off size-based
|
||||
clean-up.</para></listitem>
|
||||
<citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
|
||||
Set either value to 0 to turn off size-based cleanup.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@
|
|||
<term><option>-1</option></term>
|
||||
|
||||
<listitem><para>Show information of the most recent core dump only, instead of listing all known core
|
||||
dumps. (Equivalent to <option>--reverse -n 1</option></para></listitem>
|
||||
dumps. Equivalent to <option>--reverse -n 1</option>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
|
|||
|
|
@ -373,7 +373,7 @@
|
|||
|
||||
<listitem><para>A lower-case string (mostly numeric, no spaces or other characters outside of 0–9,
|
||||
a–z, ".", "_" and "-") identifying the operating system extensions support level, to indicate which
|
||||
extension images are supported. See:
|
||||
extension images are supported. See
|
||||
<citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>)
|
||||
for more information.</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -452,8 +452,8 @@
|
|||
<para>If the special value <literal>auto</literal> is specified, the source to copy from is
|
||||
automatically picked up from the running system (or the image specified with
|
||||
<option>--image=</option> — if used). A partition that matches both the configured partition type (as
|
||||
declared with <varname>Type=</varname> above), and the currently mounted directory appropriate for
|
||||
that partition type is determined. For example, if the partition type is set to
|
||||
declared with <varname>Type=</varname> described above), and the currently mounted directory
|
||||
appropriate for that partition type is determined. For example, if the partition type is set to
|
||||
<literal>root</literal> the partition backing the root directory (<filename>/</filename>) is used as
|
||||
source to copy from — if its partition type is set to <literal>root</literal> as well. If the
|
||||
declared type is <literal>usr</literal> the partition backing <filename>/usr/</filename> is used as
|
||||
|
|
@ -529,7 +529,7 @@
|
|||
<varlistentry>
|
||||
<term><varname>MakeDirectories=</varname></term>
|
||||
|
||||
<listitem><para>akes one or more absolute paths, separated by whitespace, each declaring a directory
|
||||
<listitem><para>Takes one or more absolute paths, separated by whitespace, each declaring a directory
|
||||
to create within the new file system. Behaviour is similar to <varname>CopyFiles=</varname>, but
|
||||
instead of copying in a set of files this just creates the specified directories with the default
|
||||
mode of 0755 owned by the root user and group, plus all their parent directories (with the same
|
||||
|
|
@ -564,10 +564,10 @@
|
|||
are copied in or the file system configured with <varname>Format=</varname> is created.</para>
|
||||
|
||||
<para>The LUKS2 UUID is automatically derived from the partition UUID in a stable fashion. If
|
||||
<literal>key-file</literal> or <literal>key-file+tpm2</literal> is used a key is added to the LUKS2
|
||||
superblock, configurable with the <option>--key-file=</option> switch to
|
||||
<literal>key-file</literal> or <literal>key-file+tpm2</literal> is used, a key is added to the LUKS2
|
||||
superblock, configurable with the <option>--key-file=</option> option to
|
||||
<command>systemd-repart</command>. If <literal>tpm2</literal> or <literal>key-file+tpm2</literal> is
|
||||
used a key is added to the LUKS2 superblock that is enrolled to the local TPM2 chip, as configured
|
||||
used, a key is added to the LUKS2 superblock that is enrolled to the local TPM2 chip, as configured
|
||||
with the <option>--tpm2-device=</option> and <option>--tpm2-pcrs=</option> options to
|
||||
<command>systemd-repart</command>.</para>
|
||||
|
||||
|
|
@ -623,7 +623,7 @@
|
|||
has no effect on explicit mounts, such as those done via <citerefentry
|
||||
project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> or
|
||||
<citerefentry
|
||||
project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry></para>
|
||||
project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
||||
|
||||
<para>If both bit 50 and 59 are set for a partition (i.e. the partition is marked both read-only and
|
||||
marked for file system growing) the latter is typically without effect: the read-only flag takes
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@
|
|||
<term><option>--pkcs11-token-uri=</option><replaceable>URI</replaceable></term>
|
||||
|
||||
<listitem><para>Enroll a PKCS#11 security token or smartcard (e.g. a YubiKey). Expects a PKCS#11
|
||||
smart card URI referring to the token. Alternatively the special value <literal>auto</literal> may
|
||||
smartcard URI referring to the token. Alternatively the special value <literal>auto</literal> may
|
||||
be specified, in order to automatically determine the URI of a currently plugged in security token
|
||||
(of which there must be exactly one). The special value <literal>list</literal> may be used to
|
||||
enumerate all suitable PKCS#11 tokens currently plugged in. The security token must contain an RSA
|
||||
|
|
|
|||
|
|
@ -307,7 +307,7 @@
|
|||
<varlistentry>
|
||||
<term><literal>passwd.shell.root</literal></term>
|
||||
|
||||
<listitem><para>Specifies the shell binary to use for the specified account when creating it.
|
||||
<listitem><para>Specifies the shell binary to use for the specified account.
|
||||
Equivalent to the credential of the same name defined for the
|
||||
<citerefentry><refentrytitle>systemd-sysusers.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
service.</para></listitem>
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@
|
|||
|
||||
<varlistentry>
|
||||
<term><option>--image=<replaceable>path</replaceable></option></term>
|
||||
<listitem><para>Takes a path to a device node or refular file as argument. This is similar to
|
||||
<listitem><para>Takes a path to a device node or regular file as argument. This is similar to
|
||||
<option>--root=</option> as described above, but operates on a disk image instead of a directory
|
||||
tree.</para></listitem>
|
||||
</varlistentry>
|
||||
|
|
|
|||
|
|
@ -1375,12 +1375,12 @@ After=sys-subsystem-net-devices-ens1.device</programlisting>
|
|||
</orderedlist>
|
||||
|
||||
<para>The combination of the three operations above ensures that it is possible to log into the
|
||||
host's user account inside the container as if it was local to the container. The user is only mapped
|
||||
transiently, while the container is running and the mapping itself does not result in persistent
|
||||
changes to the container (except maybe for generated log messages at login time, and similar). Note
|
||||
that in particular the UID/GID assignment in the container is not made persistently. If the user is
|
||||
mapped transiently, it is best to not allow the user to make persistent changes to the container. If
|
||||
the user leaves files or directories owned by the user, and those UIDs/GIDs are recycled during later
|
||||
container using the same account information as on the host. The user is only mapped transiently,
|
||||
while the container is running, and the mapping itself does not result in persistent changes to the
|
||||
container (except maybe for log messages generated at login time, and similar). Note that in
|
||||
particular the UID/GID assignment in the container is not made persistently. If the user is mapped
|
||||
transiently, it is best to not allow the user to make persistent changes to the container. If the
|
||||
user leaves files or directories owned by the user, and those UIDs/GIDs are reused during later
|
||||
container invocations (possibly with a different <option>--bind-user=</option> mapping), those files
|
||||
and directories will be accessible to the "new" user.</para>
|
||||
|
||||
|
|
@ -1581,9 +1581,9 @@ After=sys-subsystem-net-devices-ens1.device</programlisting>
|
|||
-b</programlisting>
|
||||
|
||||
<para>The above command line will invoke the specified image file <filename>image.raw</filename> in
|
||||
volatile mode, i.e with an empty <filename>/etc/</filename> and <filename>/var/</filename>, so that
|
||||
the container's payload recognizes this as first boot condition, and will invoke
|
||||
<filename>systemd-firstboot.service</filename>, which then read the two passed credentials to
|
||||
volatile mode, i.e. with empty <filename>/etc/</filename> and <filename>/var/</filename>. The
|
||||
container payload will recognize this as a first boot, and will invoke
|
||||
<filename>systemd-firstboot.service</filename>, which then reads the two passed credentials to
|
||||
configure the system's initial locale and root password.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
|
|||
|
|
@ -275,7 +275,7 @@ search foobar.com barbar.com
|
|||
fragility in both directions: a valid global name could be obscured by a local name, and resolution of
|
||||
a relative local name could suddenly break when a new top-level domain is created, or when a new
|
||||
subdomain of a top-level domain in registered. Resolving any given name as either relative or absolute
|
||||
avoids this ambiguity.)</para></footnote></para></listitem>
|
||||
avoids this ambiguity.</para></footnote></para></listitem>
|
||||
|
||||
<listitem><para>This resolver has a notion of the special <literal>.local</literal> domain used for
|
||||
MulticastDNS, and will not route queries with that suffix to unicast DNS servers unless explicitly
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@
|
|||
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
|
||||
<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
|
||||
|
|
@ -127,13 +127,15 @@
|
|||
<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. <filename>strace</filename> and <filename>gdb</filename> 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>
|
||||
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
|
||||
|
|
|
|||
|
|
@ -262,7 +262,7 @@
|
|||
names in status messages (e.g. <literal>systemd-journald.service</literal>), instead of the longer
|
||||
and more informative descriptions set with <varname>Description=</varname> (e.g. <literal>Journal
|
||||
Logging Service</literal>). If <option>combined</option>, the system manager will use both unit names
|
||||
and descriptions in status messages (e.g. <literal>systemdmd-jouranld.service - Journal Logging
|
||||
and descriptions in status messages (e.g. <literal>systemd-journald.service - Journal Logging
|
||||
Service</literal>).</para>
|
||||
|
||||
<para>See
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@
|
|||
JSON user/group records from classic UNIX/glibc NSS user/group records in order to provide full backwards
|
||||
compatibility. It may also pick up statically defined JSON user/group records from drop-in files in
|
||||
<filename>/etc/userdb/</filename>, <filename>/run/userdb/</filename>,
|
||||
<filename>/run/host/userdb/</filename> and <filename>/use/lib/userdb/</filename>.</para>
|
||||
<filename>/run/host/userdb/</filename> and <filename>/usr/lib/userdb/</filename>.</para>
|
||||
|
||||
<para>Most of <command>systemd-userdbd</command>'s functionality is accessible through the
|
||||
<citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
|
|
|
|||
|
|
@ -402,14 +402,15 @@
|
|||
<term><varname>ExtensionImages=</varname></term>
|
||||
|
||||
<listitem><para>This setting is similar to <varname>MountImages=</varname> in that it mounts a file
|
||||
system hierarchy from a block device node or loopback file, but instead of providing a destination path,
|
||||
an overlay will be set up. This option expects a whitespace separated list of mount definitions. Each
|
||||
definition consists of a source path, optionally followed by a colon and a list of mount options.</para>
|
||||
system hierarchy from a block device node or loopback file, but instead of providing a destination
|
||||
path, an overlay will be set up. This option expects a whitespace separated list of mount
|
||||
definitions. Each definition consists of a source path, optionally followed by a colon and a list of
|
||||
mount options.</para>
|
||||
|
||||
<para>A read-only OverlayFS will be set up on top of <filename>/usr/</filename> and
|
||||
<filename>/opt/</filename> hierarchies from the root. The order in which the images are listed
|
||||
will determine the order in which the overlay is laid down: images specified first to last will result
|
||||
in overlayfs layers bottom to top.</para>
|
||||
<filename>/opt/</filename> hierarchies. The order in which the images are listed will determine the
|
||||
order in which the overlay is laid down: images specified first to last will result in overlayfs
|
||||
layers bottom to top.</para>
|
||||
|
||||
<para>Mount options may be defined as a single comma-separated list of options, in which case they
|
||||
will be implicitly applied to the root partition on the image, or a series of colon-separated tuples
|
||||
|
|
@ -2304,7 +2305,7 @@ SystemCallErrorNumber=EPERM</programlisting>
|
|||
|
||||
<listitem><para>Sets environment variables for executed processes. Each line is unquoted using the
|
||||
rules described in "Quoting" section in
|
||||
<citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
<citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
and becomes a list of variable assignments. If you need to assign a value containing spaces or the
|
||||
equals sign to a variable, put quotes around the whole assignment. Variable expansion is not
|
||||
performed inside the strings and the <literal>$</literal> character has no special meaning. Specifier
|
||||
|
|
|
|||
|
|
@ -457,7 +457,7 @@
|
|||
<term><varname>MTUBytes=</varname></term>
|
||||
<listitem>
|
||||
<para>The maximum transmission unit in bytes to set for the
|
||||
device. The usual suffixes K, M, G, are supported and are
|
||||
device. The usual suffixes K, M, G are supported and are
|
||||
understood to the base of 1024.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -465,7 +465,7 @@
|
|||
<term><varname>BitsPerSecond=</varname></term>
|
||||
<listitem>
|
||||
<para>The speed to set for the device, the value is rounded
|
||||
down to the nearest Mbps. The usual suffixes K, M, G, are
|
||||
down to the nearest Mbps. The usual suffixes K, M, G are
|
||||
supported and are understood to the base of 1000.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -788,7 +788,7 @@
|
|||
<term><varname>GenericSegmentOffloadMaxBytes=</varname></term>
|
||||
<listitem>
|
||||
<para>Specifies the maximum size of a Generic Segment Offload (GSO) packet the
|
||||
device should accept. The usual suffixes K, M, G, are supported and are
|
||||
device should accept. The usual suffixes K, M, G are supported and are
|
||||
understood to the base of 1024. An unsigned integer in the range 1…65536.
|
||||
Defaults to unset.</para>
|
||||
</listitem>
|
||||
|
|
@ -796,8 +796,8 @@
|
|||
<varlistentry>
|
||||
<term><varname>GenericSegmentOffloadMaxSegments=</varname></term>
|
||||
<listitem>
|
||||
<para>Specifies the maximum number of a Generic Segment Offload (GSO) segments the device should
|
||||
accept. An unsigned integer in the range 1…65535. Defaults to unset.</para>
|
||||
<para>Specifies the maximum number of Generic Segment Offload (GSO) segments the device should
|
||||
accept. An unsigned integer in the range 1…65535. Defaults to unset.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
|
|||
|
|
@ -390,7 +390,7 @@
|
|||
<term><varname>DefaultPVID=</varname></term>
|
||||
<listitem>
|
||||
<para>This specifies the default port VLAN ID of a newly attached bridge port.
|
||||
Set this to an integer in the range 1–4094 or <literal>none</literal> to disable the PVID.</para>
|
||||
Set this to an integer in the range 1…4094 or <literal>none</literal> to disable the PVID.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
|
@ -460,7 +460,7 @@
|
|||
<varlistentry>
|
||||
<term><varname>Id=</varname></term>
|
||||
<listitem>
|
||||
<para>The VLAN ID to use. An integer in the range 0–4094.
|
||||
<para>The VLAN ID to use. An integer in the range 0…4094.
|
||||
This setting is compulsory.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -654,7 +654,7 @@
|
|||
<term><varname>TTL=</varname></term>
|
||||
<listitem>
|
||||
<para>A fixed Time To Live N on Virtual eXtensible Local Area Network packets.
|
||||
Takes <literal>inherit</literal> or a number in the range 0–255. 0 is a special
|
||||
Takes <literal>inherit</literal> or a number in the range 0…255. 0 is a special
|
||||
value meaning inherit the inner protocol's TTL value. <literal>inherit</literal>
|
||||
means that it will inherit the outer protocol's TTL value.</para>
|
||||
</listitem>
|
||||
|
|
@ -913,7 +913,7 @@
|
|||
<varlistentry>
|
||||
<term><varname>TunnelId=</varname></term>
|
||||
<listitem>
|
||||
<para>Specifies the tunnel identifier. Takes an number in the range 1–4294967295. The value used
|
||||
<para>Specifies the tunnel identifier. Takes an number in the range 1…4294967295. The value used
|
||||
must match the <literal>PeerTunnelId=</literal> value being used at the peer. This setting is
|
||||
compulsory.</para>
|
||||
</listitem>
|
||||
|
|
@ -1002,7 +1002,7 @@
|
|||
<varlistentry>
|
||||
<term><varname>SessionId=</varname></term>
|
||||
<listitem>
|
||||
<para>Specifies the session identifier. Takes an number in the range 1–4294967295. The value used
|
||||
<para>Specifies the session identifier. Takes an number in the range 1…4294967295. The value used
|
||||
must match the <literal>SessionId=</literal> value being used at the peer. This setting is
|
||||
compulsory.</para>
|
||||
</listitem>
|
||||
|
|
@ -1010,7 +1010,7 @@
|
|||
<varlistentry>
|
||||
<term><varname>PeerSessionId=</varname></term>
|
||||
<listitem>
|
||||
<para>Specifies the peer session identifier. Takes an number in the range 1–4294967295.
|
||||
<para>Specifies the peer session identifier. Takes an number in the range 1…4294967295.
|
||||
The value used must match the <literal>PeerSessionId=</literal> value being used at the peer.
|
||||
This setting is compulsory.</para>
|
||||
</listitem>
|
||||
|
|
@ -1234,7 +1234,7 @@
|
|||
<term><varname>TTL=</varname></term>
|
||||
<listitem>
|
||||
<para>A fixed Time To Live N on tunneled packets. N is a
|
||||
number in the range 1–255. 0 is a special value meaning that
|
||||
number in the range 1…255. 0 is a special value meaning that
|
||||
packets inherit the TTL value. The default value for IPv4
|
||||
tunnels is 0 (inherit). The default value for IPv6 tunnels is
|
||||
64.</para>
|
||||
|
|
@ -1256,7 +1256,7 @@
|
|||
It is only used for IPv6 tunnels.
|
||||
A flow label of zero is used to indicate packets that have
|
||||
not been labeled.
|
||||
It can be configured to a value in the range 0–0xFFFFF, or be
|
||||
It can be configured to a value in the range 0…0xFFFFF, or be
|
||||
set to <literal>inherit</literal>, in which case the original flowlabel is used.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -1673,15 +1673,15 @@
|
|||
<para>Sets a comma-separated list of IP (v4 or v6) addresses with CIDR masks
|
||||
from which this peer is allowed to send incoming traffic and to
|
||||
which outgoing traffic for this peer is directed.</para>
|
||||
|
||||
<para>The catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses,
|
||||
and ::/0 may be specified for matching all IPv6 addresses.</para>
|
||||
<para>Note that this only affects "routing inside the network interface itself",
|
||||
as in, which wireguard peer packets with a specific destination address are sent to,
|
||||
and what source addresses are accepted from which peer.</para>
|
||||
<para>To cause packets to be sent via wireguard in first place, a route needs
|
||||
to be added, as well - either in the <literal>[Routes]</literal> section on the
|
||||
<literal>.network</literal> matching the wireguard interface, or outside of networkd.
|
||||
</para>
|
||||
|
||||
<para>Note that this only affects <emphasis>routing inside the network interface itself</emphasis>,
|
||||
i.e. the packets that pass through the tunnel itself. To cause packets to be sent via the tunnel in
|
||||
the first place, an appropriate route needs to be added as well — either in the
|
||||
<literal>[Routes]</literal> section on the <literal>.network</literal> matching the wireguard
|
||||
interface, or externally to <filename>systemd-networkd</filename>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
|
@ -1823,7 +1823,7 @@
|
|||
<term><varname>AdUserPortKey=</varname></term>
|
||||
<listitem>
|
||||
<para>Specifies the 802.3ad user defined portion of the port key. Takes a number in the range
|
||||
0–1023.</para>
|
||||
0…1023.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -2036,9 +2036,9 @@
|
|||
|
||||
<refsect1>
|
||||
<title>[BatmanAdvanced] Section Options</title>
|
||||
<para>The [BatmanAdvanced] section only applies for
|
||||
netdevs of kind <literal>batadv</literal> and accepts the
|
||||
following keys:</para>
|
||||
|
||||
<para>The [BatmanAdvanced] section only applies for netdevs of kind <literal>batadv</literal> and accepts
|
||||
the following keys:</para>
|
||||
|
||||
<variablelist class='network-directives'>
|
||||
<varlistentry>
|
||||
|
|
|
|||
|
|
@ -1423,7 +1423,7 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
|
|||
<term><varname>Metric=</varname></term>
|
||||
<listitem>
|
||||
<para>The metric of the route. Takes an unsigned integer in the range 0…4294967295.
|
||||
Defaluts to unset, and the kernel's default will be used.</para>
|
||||
Defaults to unset, and the kernel's default will be used.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
|
@ -1615,9 +1615,10 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
|
|||
<term><varname>SendHostname=</varname></term>
|
||||
<listitem>
|
||||
<para>When true (the default), the machine's hostname (or the value specified with
|
||||
<varname>Hostname=</varname> below) will be sent to the DHCP server. Note that the hostname must
|
||||
consist only of 7-bit ASCII lower-case characters and no spaces or dots, and be formatted as a
|
||||
valid DNS domain name. Otherwise, the hostname is not sent even if this option is true.</para>
|
||||
<varname>Hostname=</varname>, described below) will be sent to the DHCP server. Note that the
|
||||
hostname must consist only of 7-bit ASCII lower-case characters and no spaces or dots, and be
|
||||
formatted as a valid DNS domain name. Otherwise, the hostname is not sent even if this option is
|
||||
true.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -1911,8 +1912,8 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
|
|||
<term><varname>FallbackLeaseLifetimeSec=</varname></term>
|
||||
<listitem>
|
||||
<para>Allows to set DHCPv4 lease lifetime when DHCPv4 server does not send the lease lifetime.
|
||||
Takes one of <literal>forever</literal> or <literal>infinity</literal> means that the address
|
||||
never expires. Defaults to unset.</para>
|
||||
Takes one of <literal>forever</literal> or <literal>infinity</literal>. The latter means that the
|
||||
address never expires. Defaults to unset.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -2339,9 +2340,9 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
|
|||
<varlistentry>
|
||||
<term><varname>ServerAddress=</varname></term>
|
||||
<listitem><para>Specifies server address for the DHCP server. Takes an IPv4 address with prefix
|
||||
length, e.g., <literal>192.168.0.1/24</literal>. This setting may be useful when the link which
|
||||
DHCP server running on has multiple static addresses. When unset, one of static addresses in
|
||||
the link will be automatically selected. Defaults to unset.</para></listitem>
|
||||
length, for example <literal>192.168.0.1/24</literal>. This setting may be useful when the link on
|
||||
which the DHCP server is running has multiple static addresses. When unset, one of static addresses
|
||||
in the link will be automatically selected. Defaults to unset.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
@ -2521,23 +2522,22 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
|
|||
|
||||
<refsect1>
|
||||
<title>[DHCPServerStaticLease] Section Options</title>
|
||||
<para>The <literal>[DHCPServerStaticLease]</literal> section configures a static DHCP lease to
|
||||
assign a pre-set IPv4 address to a specific device based on its MAC address. This section can be
|
||||
specified multiple times.</para>
|
||||
<para>The <literal>[DHCPServerStaticLease]</literal> section configures a static DHCP lease to assign a
|
||||
fixed IPv4 address to a specific device based on its MAC address. This section can be specified multiple
|
||||
times.</para>
|
||||
|
||||
<variablelist class='network-directives'>
|
||||
<varlistentry>
|
||||
<term><varname>MACAddress=</varname></term>
|
||||
|
||||
<listitem><para>The hardware address of a device which should be assigned IPv4 address
|
||||
specified in <varname>Address=</varname>. This key is mandatory.</para></listitem>
|
||||
<listitem><para>The hardware address of a device to match. This key is mandatory.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>Address=</varname></term>
|
||||
|
||||
<listitem><para>IPv4 address that should be assigned to a device with a hardware address
|
||||
specified in <varname>MACAddress=</varname>. This key is mandatory.</para></listitem>
|
||||
<listitem><para>The IPv4 address that should be assigned to the device that was matched with
|
||||
<varname>MACAddress=</varname>. This key is mandatory.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
|
|
|||
|
|
@ -202,7 +202,7 @@
|
|||
capabilities (see
|
||||
<citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
for details). The <varname>AmbientCapability=</varname> setting
|
||||
specifies capability which will be passed to to started program
|
||||
specifies capability which will be passed to the started program
|
||||
in the inheritable and ambient capability sets. This will grant
|
||||
these capabilities to this process. This setting correspond to
|
||||
the <option>--ambient-capability=</option> command line switch.
|
||||
|
|
|
|||
|
|
@ -207,7 +207,7 @@ disable *</programlisting>
|
|||
<citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
</para>
|
||||
|
||||
<para><citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
<para><citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
has a discussion of packaging scriptlets.</para>
|
||||
|
||||
<para>Fedora page introducing the use of presets:
|
||||
|
|
|
|||
|
|
@ -1134,7 +1134,7 @@
|
|||
<literal>\;</literal>.</para>
|
||||
|
||||
<para>Each command line is unquoted using the rules described in "Quoting" section in
|
||||
<citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
|
||||
<citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
|
||||
first item becomes the command to execute, and the subsequent items the arguments.</para>
|
||||
|
||||
<para>This syntax is inspired by shell syntax, but only the meta-characters and expansions
|
||||
|
|
|
|||
|
|
@ -1535,7 +1535,7 @@
|
|||
<varlistentry>
|
||||
<term><varname>ConditionControlGroupController=</varname></term>
|
||||
|
||||
<listitem><para>Check whether given cgroup controllers (eg. <literal>cpu</literal>) are available
|
||||
<listitem><para>Check whether given cgroup controllers (e.g. <literal>cpu</literal>) are available
|
||||
for use on the system or whether the legacy v1 cgroup or the modern v2 cgroup hierarchy is used.
|
||||
</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@
|
|||
url="https://systemd.io/USER_GROUP_API">User/Group Record Lookup API via Varlink</ulink>, and may also
|
||||
pick up drop-in JSON user and group records from <filename>/etc/userdb/</filename>,
|
||||
<filename>/run/userdb/</filename>, <filename>/run/host/userdb/</filename>,
|
||||
<filename>/use/lib/userdb/</filename>.</para>
|
||||
<filename>/usr/lib/userdb/</filename>.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
|
@ -104,7 +104,7 @@
|
|||
|
||||
<listitem><para>Controls whether to include user/group lookups in the output that are defined using
|
||||
drop-in files in <filename>/etc/userdb/</filename>, <filename>/run/userdb/</filename>,
|
||||
<filename>/run/host/userdb/</filename>, <filename>/use/lib/userdb/</filename>. If
|
||||
<filename>/run/host/userdb/</filename>, <filename>/usr/lib/userdb/</filename>. If
|
||||
<option>--with-dropin=no</option> is used these records are suppressed. If
|
||||
<option>--with-dropin=yes</option> is specified such users/groups are included in the output (which
|
||||
is the default).</para></listitem>
|
||||
|
|
@ -260,7 +260,7 @@
|
|||
<citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
and picks up JSON user/group records from <filename>/etc/userdb/</filename>,
|
||||
<filename>/run/userdb/</filename>, <filename>/run/host/userdb/</filename>,
|
||||
<filename>/use/lib/userdb/</filename>.</para></listitem>
|
||||
<filename>/usr/lib/userdb/</filename>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
|
|
|||
Loading…
Reference in a new issue