FIx some malformed XML in option descriptions

E.g. these were using "<para>" at the *end* of a description. The real
WTF is that this is possible at all...
This commit is contained in:
Eelco Dolstra 2019-05-13 09:15:17 +02:00
parent 59a733edae
commit de9e238469
No known key found for this signature in database
GPG key ID: 8170B4726D7198DE
6 changed files with 21 additions and 50 deletions

View file

@ -54,9 +54,7 @@ in
default = "libc";
description = ''
The system-wide memory allocator.
</para>
<para>
Briefly, the system-wide memory allocator providers are:
<itemizedlist>
<listitem><para><literal>libc</literal>: the standard allocator provided by libc</para></listitem>
@ -64,7 +62,6 @@ in
(name: value: "<listitem><para><literal>${name}</literal>: ${value.description}</para></listitem>")
providers)}
</itemizedlist>
</para>
<warning>
<para>
@ -79,8 +76,6 @@ in
Changing this option does not affect the current session.
</para>
</note>
<para>
'';
};
};

View file

@ -13,23 +13,17 @@ with lib;
default = true;
description = ''
Whether to allow creation of user namespaces.
</para>
<para>
The motivation for disabling user namespaces is the potential
presence of code paths where the kernel's permission checking
logic fails to account for namespacing, instead permitting a
namespaced process to act outside the namespace with the same
privileges as it would have inside it. This is particularly
damaging in the common case of running as root within the namespace.
</para>
<para>
When user namespace creation is disallowed, attempting to create a
user namespace fails with "no space left on device" (ENOSPC).
root may re-enable user namespace creation at runtime.
</para>
<para>
'';
};
@ -48,21 +42,15 @@ with lib;
Whether to allow SMT/hyperthreading. Disabling SMT means that only
physical CPU cores will be usable at runtime, potentially at
significant performance cost.
</para>
<para>
The primary motivation for disabling SMT is to mitigate the risk of
leaking data between threads running on the same CPU core (due to
e.g., shared caches). This attack vector is unproven.
</para>
<para>
Disabling SMT is a supplement to the L1 data cache flushing mitigation
(see <xref linkend="opt-security.virtualization.flushL1DataCache"/>)
versus malicious VM guests (SMT could "bring back" previously flushed
data).
</para>
<para>
'';
};
@ -73,10 +61,8 @@ with lib;
Whether the hypervisor should flush the L1 data cache before
entering guests.
See also <xref linkend="opt-security.allowSimultaneousMultithreading"/>.
</para>
<para>
<variablelist>
<variablelist>
<varlistentry>
<term><literal>null</literal></term>
<listitem><para>uses the kernel default</para></listitem>
@ -98,7 +84,7 @@ with lib;
enters the guest. May incur significant performance cost.
</para></listitem>
</varlistentry>
</variablelist>
</variablelist>
'';
};
};

View file

@ -7,28 +7,23 @@ let
planDescription = ''
The znapzend backup plan to use for the source.
</para>
<para>
The plan specifies how often to backup and for how long to keep the
backups. It consists of a series of retention periodes to interval
associations:
</para>
<para>
<literal>
retA=>intA,retB=>intB,...
</literal>
</para>
<para>
Both intervals and retention periods are expressed in standard units
of time or multiples of them. You can use both the full name or a
shortcut according to the following listing:
</para>
<para>
Both intervals and retention periods are expressed in standard units
of time or multiples of them. You can use both the full name or a
shortcut according to the following listing:
<literal>
second|sec|s, minute|min, hour|h, day|d, week|w, month|mon|m, year|y
</literal>
</para>
<para>
See <citerefentry><refentrytitle>znapzendzetup</refentrytitle><manvolnum>1</manvolnum></citerefentry> for more info.
'';
planExample = "1h=>10min,1d=>1h,1w=>1d,1m=>1w,1y=>1m";
@ -139,12 +134,10 @@ let
type = nullOr ints.u16;
description = ''
Port to use for <command>mbuffer</command>.
</para>
<para>
If this is null, it will run <command>mbuffer</command> through
ssh.
</para>
<para>
If this is not null, it will run <command>mbuffer</command>
directly through TCP, which is not encrypted but faster. In that
case the given port needs to be open on the destination host.

View file

@ -62,8 +62,7 @@ in {
description = ''
The resolution of the console. The following values are valid:
</para>
<para>
<itemizedlist>
<listitem><para>
<literal>"0"</literal>: Standard UEFI 80x25 mode

View file

@ -35,7 +35,7 @@ in
when resolving single-label host names (domain names which
contain no dot), in order to qualify them into fully-qualified
domain names (FQDNs).
</para><para>
For compatibility reasons, if this setting is not specified,
the search domains listed in
<filename>/etc/resolv.conf</filename> are used instead, if
@ -50,8 +50,9 @@ in
description = ''
Controls Link-Local Multicast Name Resolution support
(RFC 4795) on the local host.
</para><para>
If set to
<variablelist>
<varlistentry>
<term><literal>"true"</literal></term>

View file

@ -65,10 +65,9 @@ let
default = [];
description = ''
Network ports to publish from the container to the outer host.
</para>
<para>
Valid formats:
</para>
<itemizedlist>
<listitem>
<para>
@ -91,21 +90,19 @@ let
</para>
</listitem>
</itemizedlist>
<para>
Both <literal>hostPort</literal> and
<literal>containerPort</literal> can be specified as a range of
ports. When specifying ranges for both, the number of container
ports in the range must match the number of host ports in the
range. Example: <literal>1234-1236:1234-1236/tcp</literal>
</para>
<para>
When specifying a range for <literal>hostPort</literal> only, the
<literal>containerPort</literal> must <emphasis>not</emphasis> be a
range. In this case, the container port is published somewhere
within the specified <literal>hostPort</literal> range. Example:
<literal>1234-1236:1234/tcp</literal>
</para>
<para>
Refer to the
<link xlink:href="https://docs.docker.com/engine/reference/run/#expose-incoming-ports">
Docker engine documentation</link> for full details.