diff options
Diffstat (limited to 'man/NetworkManager.conf.xml')
| -rw-r--r-- | man/NetworkManager.conf.xml | 115 |
1 files changed, 97 insertions, 18 deletions
diff --git a/man/NetworkManager.conf.xml b/man/NetworkManager.conf.xml index 79f18e45..df85e641 100644 --- a/man/NetworkManager.conf.xml +++ b/man/NetworkManager.conf.xml @@ -86,6 +86,12 @@ Certain settings from the configuration can be reloaded at runtime either by sending SIGHUP signal or via D-Bus' Reload call. </para> + <para> + NetworkManager does not require any configuration in <literal>NetworkManager.conf</literal>. Depending + on your use case, you may remove all files to restore the default configuration (factory reset). But + note that your distribution or other packages may drop configuration snippets for NetworkManager, such + that they are part of the factory default. + </para> </refsect1> @@ -107,7 +113,7 @@ below. </para> <para> - Minimal system settings configuration file looks like this: + A simple configuration file looks like this: <programlisting> [main] plugins=keyfile @@ -313,10 +319,12 @@ no-auto-default=* <filename>/usr/lib/systemd/resolv.conf</filename>. In that case, <literal>systemd-resolved</literal> is chosen automatically. </para> + <para><literal>default</literal>: NetworkManager will update <filename>/etc/resolv.conf</filename> to reflect the nameservers provided by currently active connections. The <literal>rc-manager</literal> setting (below) controls how this is done.</para> + <para><literal>dnsmasq</literal>: NetworkManager will run dnsmasq as a local caching nameserver, using "Conditional Forwarding" if you are connected to a VPN, and then update @@ -330,12 +338,17 @@ no-auto-default=* after some time. This behavior can be modified passing the 'all-servers' or 'strict-order' options to dnsmasq (see the manual page for more details).</para> + <para><literal>systemd-resolved</literal>: NetworkManager will push the DNS configuration to systemd-resolved</para> + <para><literal>unbound</literal>: NetworkManager will talk to unbound and dnssec-triggerd, using "Conditional Forwarding" with DNSSEC support. <filename>/etc/resolv.conf</filename> - will be managed by dnssec-trigger daemon.</para> + will be managed by dnssec-trigger daemon. This option is + deprecated. Note that dnssec-trigger ships a NetworkManager dispatcher + script so this DNS plugin is not necessary.</para> + <para><literal>none</literal>: NetworkManager will not modify resolv.conf. This implies <literal>rc-manager</literal> <literal>unmanaged</literal></para> @@ -474,6 +487,51 @@ no-auto-default=* </para> </listitem> </varlistentry> + + <varlistentry> + <term><varname>firewall-backend</varname></term> + <listitem> + <para> + The firewall backend for configuring masquerading + with shared mode. + Set to either <literal>iptables</literal>, <literal>nftables</literal> + or <literal>none</literal>. + <literal>iptables</literal> and <literal>nftables</literal> + require <literal>iptables</literal> and <literal>nft</literal> + application, respectively. + <literal>none</literal> means to skip firewall configuration if + the users wish to manage firewall themselves. + If unspecified, it will be auto detected. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>iwd-config-path</varname></term> + <listitem> + <para> + If the value is "auto" (the default), IWD is queried for its + current state directory when it appears on D-Bus -- the + directory where IWD keeps its network configuration files -- + usually /var/lib/iwd. NetworkManager will then attempt to + write copies of new or modified Wi-Fi connection profiles, + converted into the IWD format, into this directory thus making + IWD connection properties editable. NM will overwrite existing + files without preserving their contents. + </para> + <para> + The path can also be overriden by pointing to a specific + existing and writable directory. On the other hand setting + this to an empty string or any other value disables the + profile conversion mechanism. + </para> + <para> + This mechanism allows editing connection profile settings such + as the 802.1x configuration using NetworkManager clients. + Without it such changes have no effect in IWD. + </para> + </listitem> + </varlistentry> </variablelist> </refsect1> @@ -502,19 +560,29 @@ no-auto-default=* </varlistentry> <varlistentry> <term><varname>unmanaged-devices</varname></term> - <listitem><para>Set devices that should be ignored by - NetworkManager. - </para> - <para>See <xref linkend="device-spec"/> for the syntax on how to - specify a device. - </para> - <para> - Example: - <programlisting> + <listitem> + <para>Set devices that should be ignored by NetworkManager. + </para> + <para> + A device unmanaged due to this option is strictly + unmanaged and cannot be overruled by using the API like + <command>nmcli device set $IFNAME managed yes</command>. + Also, a device that is unmanaged for other reasons, like + an udev rule, cannot be made managed with this option (e.g. by + using an <literal>except:</literal> specifier). + These two points make it different from the <literal>device*.managed</literal> + option which for that reason may be a better choice. + </para> + <para>See <xref linkend="device-spec"/> for the syntax on how to + specify a device. + </para> + <para> + Example: + <programlisting> unmanaged-devices=interface-name:em4 unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth2 </programlisting> - </para> + </para> </listitem> </varlistentry> </variablelist> @@ -1016,16 +1084,27 @@ managed=1 <listitem> <para> Specify the timeout for waiting for carrier in milliseconds. + The default is 5000 milliseconds. + This setting exists because certain drivers/hardware can take + a long time to detect whether the cable is plugged in. + </para> + <para> When the device loses carrier, NetworkManager does not react immediately. Instead, it waits for this timeout before considering - the link lost. Also, on startup, NetworkManager considers the + the link lost. + </para> + <para> + Also, on startup, NetworkManager considers the device as busy for this time, as long as the device has no carrier. This delays startup-complete signal and NetworkManager-wait-online. Configuring this too high means to block NetworkManager-wait-online - longer then necessary. Configuring it too low, means that NetworkManager - will declare startup-complete, although carrier is about to come - and auto-activation to kick in. - The default is 5000 milliseconds. + longer than necessary when booting with cable unplugged. Configuring + it too low, means that NetworkManager will declare startup-complete too + soon, although carrier is about to come and auto-activation to kick in. + Note that if a profile only has static IP configuration or Layer 3 configuration + disabled, then it can already autoconnect without carrier on the device. + Once such a profile reaches full activated state, startup-complete + is considered as reached even if the device has no carrier yet. </para> </listitem> </varlistentry> @@ -1109,7 +1188,7 @@ managed=1 If <literal>wifi.backend</literal> is <literal>iwd</literal>, setting this to <literal>false</literal> forces IWD's autoconnect mechanism to be disabled for this device and connections will only be initiated by NetworkManager whether - commaned by a client or automatically. Leaving it <literal>true</literal> (default) + commanded by a client or automatically. Leaving it <literal>true</literal> (default) stops NetworkManager from automatically initiating connections and allows IWD to use its network ranking and scanning logic to decide the best networks to autoconnect to next. Connections' <literal>autoconnect-priority</literal>, |