network: only process non-error message

[thirdparty/systemd.git] / man / systemd.resource-control.xml

diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml
index 6d3568576cd5b90ce30c53c78073b105f3a0331a..3ccb5c49271dfcc516f00521fce03697f4cf2292 100644 (file)
--- a/man/systemd.resource-control.xml
+++ b/man/systemd.resource-control.xml
@@ -596,13 +596,13 @@
             <listitem><para>Otherwise, access is granted.</para></listitem>
           </itemizedlist>
 
-          <para>In order to implement a whitelisting IP firewall, it is recommended to use a
-          <varname>IPAddressDeny=</varname><constant>any</constant> setting on an upper-level slice unit (such as the
-          root slice <filename>-.slice</filename> or the slice containing all system services
+          <para>In order to implement an allow-listing IP firewall, it is recommended to use a
+          <varname>IPAddressDeny=</varname><constant>any</constant> setting on an upper-level slice unit
+          (such as the root slice <filename>-.slice</filename> or the slice containing all system services
           <filename>system.slice</filename> – see
-          <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
-          details on these slice units), plus individual per-service <varname>IPAddressAllow=</varname> lines
-          permitting network access to relevant services, and only them.</para>
+          <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          for details on these slice units), plus individual per-service <varname>IPAddressAllow=</varname>
+          lines permitting network access to relevant services, and only them.</para>
 
           <para>Note that for socket-activated services, the IP access list configured on the socket unit
           applies to all sockets associated with it directly, but not to any sockets created by the
@@ -670,8 +670,8 @@
       </varlistentry>
 
       <varlistentry>
-        <term><varname>IPIngressFilterPath=<replaceable>BPF_FS_PROGRAMM_PATH</replaceable></varname></term>
-        <term><varname>IPEgressFilterPath=<replaceable>BPF_FS_PROGRAMM_PATH</replaceable></varname></term>
+        <term><varname>IPIngressFilterPath=<replaceable>BPF_FS_PROGRAM_PATH</replaceable></varname></term>
+        <term><varname>IPEgressFilterPath=<replaceable>BPF_FS_PROGRAM_PATH</replaceable></varname></term>
 
         <listitem>
           <para>Add custom network traffic filters implemented as BPF programs, applying to all IP packets
@@ -719,7 +719,7 @@
           <para>The device node specifier is either a path to a device node in the file system, starting with
           <filename>/dev/</filename>, or a string starting with either <literal>char-</literal> or
           <literal>block-</literal> followed by a device group name, as listed in
-          <filename>/proc/devices</filename>. The latter is useful to whitelist all current and future
+          <filename>/proc/devices</filename>. The latter is useful to allow-list all current and future
           devices belonging to a specific device group at once. The device group is matched according to
           filename globbing rules, you may hence use the <literal>*</literal> and <literal>?</literal>
           wildcards. (Note that such globbing wildcards are not available for device node path
@@ -733,9 +733,9 @@
           all pseudo TTYs and all ALSA sound devices, respectively. <literal>char-cpu/*</literal> is a
           specifier matching all CPU related device groups.</para>
 
-          <para>Note that whitelists defined this way should only reference device groups which are
+          <para>Note that allow lists defined this way should only reference device groups which are
           resolvable at the time the unit is started. Any device groups not resolvable then are not added to
-          the device whitelist. In order to work around this limitation, consider extending service units
+          the device allow list. In order to work around this limitation, consider extending service units
           with a pair of <command>After=modprobe@xyz.service</command> and
           <command>Wants=modprobe@xyz.service</command> lines that load the necessary kernel module
           implementing the device group if missing.