delta/NetworkManager.git/man/NetworkManager.conf.xml, branch th/fix-python-test

settings: drop ibft settings plugin

2019-06-20T14:06:44+00:00

The functionality of the ibft settings plugin is now handled by
nm-initrd-generator. There is no need for it anymore, drop it.

Note that ibft called iscsiadm, which requires CAP_SYS_ADMIN to work
([1]). We really want to drop this capability, so the current solution
of a settings plugin (as it is implemented) is wrong. The solution
instead is nm-initrd-generator.

Also, on Fedora the ibft was disabled and probably on most other
distributions as well. This was only used on RHEL.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1371201#c7

settings: drop deprecated NetworkManager.conf option "main.monitor-connection-files"

2019-05-28T15:51:24+00:00

It's deprecated and off by default for a long time.

It is bad to automatically reload connection profiles. For example, ifcfg
files may consist of multiple files, there is no guarantee that we
pick up the connection when it's fully written.

Just don't do this anymore.

Users should use D-Bus API or `nmcli connection reload` or `nmcli
connection load $FILENAME` to reload profiles from disk.

doc: replace "Split DNS" with "Conditional Forwarding"

2019-05-17T10:08:45+00:00

Split DNS usually refers to "Split Horizon DNS" whereas "Conditional
Forwarding" is specifically for what the documentation describes.

[thaller@redhat.com: rewrote commit message]

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143

wireguard: add "mtu" setting for WireGuard profiles

2019-03-05T11:23:59+00:00

This adds new API for 1.16.0 and is an ABI break since 1.16-rc1.

(cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)

man: add a warning to NetworkManager.conf manual for rp_filter and connectivity checking

2019-02-08T15:05:36+00:00

man: explain purpose of connectivity checking in `man NetworkManager.conf`

2019-02-05T10:12:07+00:00

man: fix a typo

2019-02-05T09:20:27+00:00

man: better explain "connectivity.response" in "NetworkManager.conf" manual

2019-01-31T10:33:45+00:00

connectivity: fix handling of no-response for captive portal detection

2019-01-31T10:33:44+00:00

Since we only compare that the HTTP response starts with the expected
response, we need to handle the empty expected response specially
(because, every response has "" as prefix).

So now if connectivity.response is set to "" (empty) we accept:

- HTTP status code 204. We ignore and accept any extra data that we
  might receive.

- HTTP status code 200 and an empty (or no) body.

core: fix match spec behavior for a list of all "except:"

2018-12-11T12:58:24+00:00

If the spec specifies only negative matches (and none of them matches),
then the result shall be positive.

Meaning:

    [connection*] match-device=except:dhcp-plugin:dhclient
    [connection*] match-device=except:interface-name:eth0
    [.config] enabled=except:nm-version:1.14

should be the same as:

    [connection*] match-device=*,except:dhcp-plugin:dhclient
    [connection*] match-device=*,except:interface-name:eth0
    [.config] enabled=*,except:nm-version:1.14

and match by default. Previously, such specs would never yield a
positive match, which seems wrong.

Note that "except:" already has a special meaning. It is not merely
"not:". That is because we don't support "and:" nor grouping, but all
matches are combined by an implicit "or:". With such a meaning, having
a "not:" would be unclear to define. Instead it is defined that any
"except:" match always wins and makes the entire condition to explicitly
not match. As such, it makes sense to treat a match that only consists
of "except:" matches special.

This is a change in behavior, but the alternative meaning makes
little sense.