New upstream version 1.27.90 upstream/1.27.90

1 files changed, 64 insertions, 13 deletions

diff --git a/man/NetworkManager.8 b/man/NetworkManager.8
index 2a92f0ed..9c09d3ea 100644
--- a/man/NetworkManager.8
+++ b/man/NetworkManager.8
@@ -2,12 +2,12 @@
 .\"     Title: NetworkManager
 .\"    Author: 
 .\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
-.\"      Date: 08/19/2020
+.\"      Date: 10/05/2020
 .\"    Manual: Network management daemons
-.\"    Source: NetworkManager 1.26.2
+.\"    Source: NetworkManager 1.27.90
 .\"  Language: English
 .\"
-.TH "NETWORKMANAGER" "8" "" "NetworkManager 1\&.26\&.2" "Network management daemons"
+.TH "NETWORKMANAGER" "8" "" "NetworkManager 1\&.27\&.90" "Network management daemons"
 .\" -----------------------------------------------------------------
 .\" * Define some portability stuff
 .\" -----------------------------------------------------------------
@@ -339,19 +339,70 @@ The signal has no effect at the moment but is reserved for future use\&.
 An alternative to a signal to reload configuration is the Reload D\-Bus call\&. It allows for more fine\-grained selection of what to reload, it only returns after the reload is complete, and it is guarded by PolicyKit\&.
 .SH "DEBUGGING"
 .PP
-The following environment variables are supported to help debugging\&. When used in conjunction with the
-\fB\-\-no\-daemon\fR
-option (thus echoing PPP and DHCP helper output to stdout) these can quickly help pinpoint the source of connection issues\&. Also see the
-\fB\-\-log\-level\fR
+NetworkManager only configures your system\&. So when your networking setup doesn\*(Aqt work as expected, the first step is to look at your system to understand what is actually configured, and whether that is correct\&. The second step is to find out how to tell NetworkManager to do the right thing\&.
+.PP
+You can for example try to
+\fBping\fR
+hosts (by IP address or DNS name), look at
+\fBip link show\fR,
+\fBip address show\fR
 and
-\fB\-\-log\-domains\fR
-to enable debug logging inside NetworkManager itself\&.
+\fBip route show\fR, and look at
+/etc/resolv\&.conf
+for name resolution issues\&. Also look at the connection profiles that you have configured in NetworkManager (\fBnmcli connection\fR
+and
+\fBnmcli connection show "$PROFILE"\fR) and the configured interfaces (\fBnmcli device\fR)\&.
+.PP
+If that does not suffice, look at the logfiles of NetworkManager\&. NetworkManager logs to syslog, so depending on your system configuration you can call
+\fBjournalctl\fR
+to get the logs\&. By default, NetworkManager logs are not verbose and thus not very helpful for investigating a problem in detail\&. You can change the logging level at runtime with
+\fBnmcli general logging level TRACE domains ALL\fR\&. But usually a better way is to collect full logs from the start, by configuring
+level=TRACE
+in NetworkManager\&.conf\&. See
+\fBNetworkManager.conf\fR(5)
+manual\&. Note that trace logs of NetworkManager are verbose and systemd\-journald might rate limit some lines\&. Possibly disable rate limiting first with the
+RateLimitIntervalSec
+and
+RateLimitBurst
+options of journald (see
+\fBjournald.conf\fR(5)
+manual)\&.
+.SH "/VAR/LIB/NETWORKMANAGER/SECRET_KEY AND /ETC/MACHINE\-ID"
+.PP
+The identity of a machine is important as various settings depend on it\&. For example,
+ipv6\&.addr\-gen\-mode=stable
+and
+ethernet\&.cloned\-mac\-address=stable
+generate identifiers by hashing the machine\*(Aqs identity\&. See also the
+connection\&.stable\-id
+connection property which is a per\-profile seed that gets hashed with the machine identity for generating such addresses and identifiers\&.
 .PP
-\fBNM_PPP_DEBUG\fR: When set to anything, causes NetworkManager to turn on PPP debugging in pppd, which logs all PPP and PPTP frames and client/server exchanges\&.
+If you backup and restore a machine, the identity of the machine probably should be preserved\&. In that case, preserve the files
+/var/lib/NetworkManager/secret_key
+and
+/etc/machine\-id\&. On the other hand, if you clone a virtual machine, you probably want that the clone has a different identity\&. There is already existing tooling on Linux for handling
+/etc/machine\-id
+(see
+\fBmachine-id\fR(5))\&.
+.PP
+The identity of the machine is determined by the
+/var/lib/NetworkManager/secret_key\&. If such a file does not exist, NetworkManager will create a file with random content\&. To generate a new identity just delete the file and after restart a new file will be created\&. The file should be read\-only to root and contain at least 16 bytes that will be used to seed the various places where a stable identifier is used\&.
+.PP
+Since 1\&.16\&.0, NetworkManager supports a version 2 of secret\-keys\&. For such keys
+/var/lib/NetworkManager/secret_key
+starts with ASCII
+"nm\-v2:"
+followed by at least 32 bytes of random data\&. Also, recent versions of NetworkManager always create such kinds of secret\-keys, when the file does not yet exist\&. With version 2 of the secret\-key,
+/etc/machine\-id
+is also hashed as part of the generation for addresses and identifiers\&. The advantage is that you can keep
+/var/lib/NetworkManager/secret_key
+stable, and only regenerate
+/etc/machine\-id
+when cloning a VM\&.
 .SH "BUGS"
 .PP
 Please report any bugs you find in NetworkManager at the
-\m[blue]\fBNetworkManager bug tracker\fR\m[]\&\s-2\u[1]\d\s+2\&.
+\m[blue]\fBNetworkManager issue tracker\fR\m[]\&\s-2\u[1]\d\s+2\&.
 .SH "SEE ALSO"
 .PP
 \m[blue]\fBNetworkManager home page\fR\m[]\&\s-2\u[2]\d\s+2,
@@ -365,9 +416,9 @@ Please report any bugs you find in NetworkManager at the
 \fBudev\fR(7)
 .SH "NOTES"
 .IP " 1." 4
-NetworkManager bug tracker
+NetworkManager issue tracker
 .RS 4
-\%https://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager
+\%https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues
 .RE
 .IP " 2." 4
 NetworkManager home page