From aafc1dbe4712c86189bbc1d4d54ad8cb4c69be7e Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Mon, 5 Oct 2020 22:27:18 +0200 Subject: New upstream version 1.27.90 --- docs/api/html/NetworkManager.html | 75 ++++++++++++++++++++++++++++++++------- 1 file changed, 62 insertions(+), 13 deletions(-) (limited to 'docs/api/html/NetworkManager.html') diff --git a/docs/api/html/NetworkManager.html b/docs/api/html/NetworkManager.html index f25c6299..47cc602d 100644 --- a/docs/api/html/NetworkManager.html +++ b/docs/api/html/NetworkManager.html @@ -508,29 +508,78 @@

Debugging

- The following environment variables are supported to help - debugging. When used in conjunction with the - --no-daemon option (thus echoing PPP and DHCP - helper output to stdout) these can quickly help pinpoint the - source of connection issues. Also see the - --log-level and --log-domains - to enable debug logging inside NetworkManager itself. + NetworkManager only configures your system. So when your networking setup doesn't + 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.

- NM_PPP_DEBUG: When set to anything, causes - NetworkManager to turn on PPP debugging in pppd, which logs - all PPP and PPTP frames and client/server exchanges. + You can for example try to ping hosts (by + IP address or DNS name), look at ip link show, ip address show and ip route show, + and look at /etc/resolv.conf for name resolution issues. + Also look at the connection profiles that you have configured in NetworkManager (nmcli connection + and nmcli connection show "$PROFILE") + and the configured interfaces (nmcli device). +

+

+ If that does not suffice, look at the logfiles of NetworkManager. NetworkManager + logs to syslog, so depending on your system configuration you can call journalctl + 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 nmcli general logging level TRACE domains ALL. + But usually a better way is to collect full logs from the start, by configuring + level=TRACE in NetworkManager.conf. See + NetworkManager.conf(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 + journald.conf(5) manual). +

+
+
+

/var/lib/NetworkManager/secret_key and /etc/machine-id

+

+ 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's 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. +

+

+ 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 + machine-id(5)). +

+

+ 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. +

+

+ 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.

-

Bugs

+

Bugs

Please report any bugs you find in NetworkManager at the - NetworkManager bug tracker. + NetworkManager issue tracker.

-

See Also

+

See Also

NetworkManager home page, NetworkManager.conf(5), -- cgit 1.3.0-6-gf8a5