<description> is now an XML element, no longer an attribute. Fix the
style sheets.
Fixes: 89abede3df ('docs: rework generating property infos to use <description> element')
"generate-docs-nm-settings-docs-merge.py" merges properties from
multiple XMLs. It supported an argument "--only-from-first", to
only select properties that were in the first of the provided XMLs.
The idea is that the first XML would be "src/nmcli/gen-metadata-nm-settings-nmcli.xml"
which is generated from nmcli meta-data and exactly describes the
supported properties. For example, "connection.read-only", "user.data"
or "wireless.tx-power" exist as properties somewhere, but not supported
by nmcli.
Change that, to not tie the selected property to the first XML.
"gen-metadata-nm-settings-nmcli.xml" is the XML that contains which
properties to select from, but "src/libnm-client-impl/nm-property-infos-nmcli.xml"
contains hand crafted descriptions. The latter descriptions are
preferred. As the order of the XML is already relevant for which
description is preferred, the selection is orthogonal to that.
With this, prefer descriptions from "src/libnm-client-impl/nm-property-infos-nmcli.xml"
but still select properties from "src/nmcli/gen-metadata-nm-settings-nmcli.xml".
Note that the argument is only used to generate "man/nm-settings-docs-nmcli.xml",
and with the current input, there is no actual change in behavior.
When we generate the manual page for nm-settings-nmcli, we run:
"/usr/bin/python" \
./tools/generate-docs-nm-settings-docs-merge.py \
--only-from-first \
man/nm-settings-docs-nmcli.xml \
src/nmcli/gen-metadata-nm-settings-nmcli.xml \
src/libnm-client-impl/nm-property-infos-nmcli.xml \
src/libnm-client-impl/nm-settings-docs-gir.xml
If "gen-metadata-nm-settings-nmcli.xml" contains either a <description>
or a <description-docbook>, then we must not continue searching the
other XML documents. The user provided an explicit override, and
fallback (search further) is wrong. Previously, we might take
<description> from the first file, and <description-docbook> from the
second file. As "man/nm-settings-nmcli.xsl" prefers
<description-docbook>, it takes the wrong text. Instead, as we search
the files during merge, we must prefer the first one.
Note that the change doesn't really matter anymore, because each XML
now must also contain both <description> and <description-docbook>.
There is an assertion for that.
Also, stop generating <deprecated-docbook>. First, it lacked the
important "since=" attribute and was necessary. Also, it's redundant and
does not contain anything interesting. So far, we don't need special
formatting for the deprecated message, and we likely never will.
Also, stop accepting or generating the "description=" attribute. This
should always be an XML element now.
The input always actually has a <description-docbook> field, so the secret-flags
hint was never shown.
Move it. It's indepenent from <description> and <description-docbook> anyway.
With this we see the expected messages
See the section called “Secret flag types:” for flag values.
The manual page is large. When you search for a properties, then it's
not immediately clear to which setting it belongs. You would have to
scroll up for the setting name.
This also makes sense for the nmcli manual page, because on the command
line you have to specify the full name.
Now the settings in the [global-dns] section are used *in addition* to
connection-specific ones. Only the global domains sections, when
valid, override connection settings. Update the man page to clarify
that.
Fixes: 1f0d1d78d2 ('dns-manager: always apply options from [global-dns]')
NetworkManager dispatcher will now run dispatcher scripts with 'reapply'
as action as well. Each time the connection is reapplied on a device,
this action is triggered. Document this action in the documentation.
(cherry picked from commit 0e3d2c367c)
Support managing the loopback interface through NM as the users want to
set the proper mtu for loopback interface when forwarding the packets.
Additionally, the IP addresses, DNS, route and routing rules are also
allowed to configure for the loopback connection profiles.
https://bugzilla.redhat.com/show_bug.cgi?id=2060905
This is the better name, becuse this is not in particular about "docs".
It's about generating an XML with the information from the settings
meta data for nmcli.
We will do something similar with the libnm-core meta data.
1) The "enabled-on-global-iface" flag was odd. Instead, have only
and "enabled" flag and skip (by default) endpoints on interface
that have no default route. With the new flag "also-without-default-route",
this can be overruled. So previous "enabled-on-global-default" now is
the same as "enabled", and "enabled" from before behaves now like
"enabled,also-without-default-route".
2) What was also odd, as that the fallback default value for the flags
depends on "/proc/sys/net/mptcp/enabled". There was not one fixed
fallback default, instead the used fallback value was either
"enabled-on-global-iface,subflow" or "disabled".
Usually that is not a problem (e.g. the default value for
"ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case
it is a problem, because the mptcp-flags (for better or worse) encode
different things at the same time.
Consider that the mptcp-flags can also have their default configured in
"NetworkManager.conf", a user who wants to switch the address flags
could previously do:
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled-on-global-iface,signal,subflow
but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer
honored. That means, MPTCP handling was always on, even if the sysctl was
disabled. Now, "enabled" means that it's only enabled if the sysctl
is enabled too. Now the user could write to "NetworkManager.conf"
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled,signal,subflow
and MPTCP handling would still be disabled unless the sysctl
is enabled.
There is now also a new flag "also-without-sysctl", so if you want
to really enable MPTCP handling regardless of the sysctl, you can.
The point of that might be, that we still can configure endpoints,
even if kernel won't do anything with them. Then you could just flip
the sysctl, and it would start working (as NetworkManager configured
the endpoints already).
Fixes: eb083eece5 ('all: add NMMptcpFlags and connection.mptcp-flags property')
(cherry picked from commit c00873e08f)
When NetworkManager runs in initrd, it can be cumbersome to enable debug logging.
Granted, when using dracut, the NetworkManager dracut module will honor "rd.debug".
However, a user may use NetworkManager in initrd without dracut. Then,
the only way to enable debug logging would be by changing
"NetworkManager.conf" and rebuild the initrd (or having some script in
place, that allows to more conveniently enable debug logging for
NetworkManager).
To make it easier for debugging, honor "nm.debug" on the kernel command
line.
Note that if "nm.debug" is set on the kernel command line, it always overrides
both the command line arguments and the configuration from NetworkManager.conf.
That is intentional. The only way to override that is by overriding the
kernel command line with a file "/run/NetworkManager/proc-cmdline".
https://bugzilla.redhat.com/show_bug.cgi?id=2102313
Improve documentation by preserving paragraphs in the
nm-settings-nmcli man pages.
To do that structure of src/libnm-client-impl/nm-settings-docs-gir.xml
was changed to have "description" as subnode to property node instead
of attribute of property node. Another subnode "description-docbook"
was added - this node is then used when generating man pages.
tools/generate-docs-nm-settings-docs-gir.py and man/nm-settings-dbus.xsl
were also changed to accomodate for changes mentioned above.
Replace xsltproc tool with python script when generating
./src/libnmc-setting/settings-docs.h.
Deleted settings-docs.xsl since it was replaced by python script.
Change src/libnmc-setting/settings-docs.h.in accodring to newly
generated src/libnmc-setting/settings-docs.h
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/661https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1260
It can be useful to choose a different "ipv6.addr-gen-mode". And it can be
useful to override the default for a set of profiles.
For example, in cloud or in a data center, stable-privacy might not be
the best choice. Add a mechanism to override the default via global defaults
in NetworkManager.conf:
# /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf
[connection-90-ipv6-addr-gen-mode-override]
match-device=type:ethernet
ipv6.addr-gen-mode=0
"ipv6.addr-gen-mode" is a special property, because its default depends on
the component that configures the profile.
- when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode
key means to default to "eui64".
- when configured via D-Bus, a missing addr-gen-mode property means to
default to "stable-privacy".
- libnm's ip6-config::addr-gen-mode property defaults to
"stable-privacy".
- when some tool creates a profile, they either can explicitly
set the mode, or they get the default of the underlying mechanisms
above.
- nm-initrd-generator explicitly sets "eui64" for profiles it creates.
- nmcli doesn' explicitly set it, but inherits the default form
libnm's ip6-config::addr-gen-mode.
- when NM creates a auto-default-connection for ethernet ("Wired connection 1"),
it inherits the default from libnm's ip6-config::addr-gen-mode.
Global connection defaults only take effect when the per-profile
value is set to a special default/unset value. To account for the
different cases above, we add two such special values: "default" and
"default-or-eui64". That's something we didn't do before, but it seams
useful and easy to understand.
Also, this neatly expresses the current behaviors we already have. E.g.
if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64"
is a pretty clear thing.
Note that usually we cannot change default values, in particular not for
libnm's properties. That is because we don't serialize the default
values to D-Bus/keyfile, so if we change the default, we change
behavior. Here we change from "stable-privacy" to "default" and
from "eui64" to "default-or-eui64". That means, the user only experiences
a change in behavior, if they have a ".conf" file that overrides the default.
https://bugzilla.redhat.com/show_bug.cgi?id=1743161https://bugzilla.redhat.com/show_bug.cgi?id=2082682
See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
This is an interface to the Checkpoint/Restore functionality that's
available for quite some time. It runs a command with a checkpoint taken
and rolls back unless success is confirmed before the checkpoint times
out:
$ nmcli dev checkpoint eth0 -- nmcli dev dis eth0
Device 'eth0' successfully disconnected.
Type "Yes" to commit the changes: No
Checkpoint was removed.
The details about how it's used are documented in nmcli(1) and
nmcli-examples(7).
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
This adds a global "--offline" option and allows its use with "add" and
"modify" commands. The "add" looks like this:
$ nmcli --offline conn add type ethernet ens3 ipv4.dns 192.168.1.1 \
>output.nmconnection
The "modify" is essentially implementing what's been suggested by
Beniamino in bugzilla ticked (referred to below):
$ nmcli --offline connection modify ens3 ipv4.dns 192.168.1.1 \
<input.nmconnection >output.nmconnection
Other commands don't support the argument at the moment:
$ nmcli --offline c up ens3
Error: 'up' command doesn't support --offline mode.
https://bugzilla.redhat.com/show_bug.cgi?id=1361145
The "unbound" DNS plugin was very rudimentary and is deprecated since
commit 4a2fe09853 ('man: mark [main].dns=unbound as deprecated') (Jun
2021).
It is part of dnssec-trigger tool, but the dnssec-trigger tool doesn't
actually use it. Instead it installs a dispatcher script
"/usr/lib/NetworkManager/dispatcher.d/01-dnssec-trigger".
Especially, since the plugin requires "/usr/libexec/dnssec-trigger-script",
which is provided by "dnssec-trigger" package on Fedora. At the same
time, the package provides the dispatcher script. So I don't this works
or anybody is using this.
https://mail.gnome.org/archives/networkmanager-list/2022-April/msg00002.html
Follow-up commits are going color Wi-Fi networks and connections that rely
on deprecated features differently, to provide a visual cue.
Add color definitions for those.
NetworkManager-wait-online is a constant source of confusion,
as it seems to delay the boot (when it's often just the messenger
or either a network problem, a NetworkManager misconfiguration
or a misconfiguration of other systemd services).
Try to clear that up with a manual page.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1130
People keep reporting bugs with `level=DEBUG` or set to a certain
domains. That is generally not useful. Complete debug logs should be
collected, we can always ignore what we don't care about, but we might
miss important information by limiting what we collect.
Try to make that clearer in the manual.
Background
==========
Imagine you run a container on your machine. Then the routing table
might look like:
default via 10.0.10.1 dev eth0 proto dhcp metric 100
10.0.10.0/28 dev eth0 proto kernel scope link src 10.0.10.5 metric 100
[...]
10.42.0.0/24 via 10.42.0.0 dev flannel.1 onlink
10.42.1.2 dev cali02ad7e68ce1 scope link
10.42.1.3 dev cali8fcecf5aaff scope link
10.42.2.0/24 via 10.42.2.0 dev flannel.1 onlink
10.42.3.0/24 via 10.42.3.0 dev flannel.1 onlink
That is, there are another interfaces with subnets and specific routes.
If nm-cloud-setup now configures rules:
0: from all lookup local
30400: from 10.0.10.5 lookup 30400
32766: from all lookup main
32767: from all lookup default
and
default via 10.0.10.1 dev eth0 table 30400 proto static metric 10
10.0.10.1 dev eth0 table 30400 proto static scope link metric 10
then these other subnets will also be reached via the default route.
This container example is just one case where this is a problem. In
general, if you have specific routes on another interface, then the
default route in the 30400+ table will interfere badly.
The idea of nm-cloud-setup is to automatically configure the network for
secondary IP addresses. When the user has special requirements, then
they should disable nm-cloud-setup and configure whatever they want.
But the container use case is popular and important. It is not something
where the user actively configures the network. This case needs to work better,
out of the box. In general, nm-cloud-setup should work better with the
existing network configuration.
Change
======
Add new routing tables 30200+ with the individual subnets of the
interface:
10.0.10.0/24 dev eth0 table 30200 proto static metric 10
[...]
default via 10.0.10.1 dev eth0 table 30400 proto static metric 10
10.0.10.1 dev eth0 table 30400 proto static scope link metric 10
Also add more important routing rules with priority 30200+, which select
these tables based on the source address:
30200: from 10.0.10.5 lookup 30200
These will do source based routing for the subnets on these
interfaces.
Then, add a rule with priority 30350
30350: lookup main suppress_prefixlength 0
which processes the routes from the main table, but ignores the default
routes. 30350 was chosen, because it's in between the rules 30200+ and
30400+, leaving a range for the user to configure their own rules.
Then, as before, the rules 30400+ again look at the corresponding 30400+
table, to find a default route.
Finally, process the main table again, this time honoring the default
route. That is for packets that have a different source address.
This change means that the source based routing is used for the
subnets that are configured on the interface and for the default route.
Whereas, if there are any more specific routes in the main table, they will
be preferred over the default route.
Apparently Amazon Linux solves this differently, by not configuring a
routing table for addresses on interface "eth0". That might be an
alternative, but it's not clear to me what is special about eth0 to
warrant this treatment. It also would imply that we somehow recognize
this primary interface. In practise that would be doable by selecting
the interface with "iface_idx" zero.
Instead choose this approach. This is remotely similar to what WireGuard does
for configuring the default route ([1]), however WireGuard uses fwmark to match
the packets instead of the source address.
[1] https://www.wireguard.com/netns/#improved-rule-based-routing
Configuration can have [device*] and [connection*] settings and both
can include a 'match-device=' key, which is a list of device-specs.
Introduce a new 'allowed-connections' key for [device*] sections,
which specifies a list of connection-specs to indicate which
connections can be activated on the device.
With this, it becomes possible to have a device configuration like:
[device-enp1s0]
match-device=interface-name:enp1s0
allowed-connections=except:origin:nm-initrd-generator
so that NM in the real root ignores connections created by the
nm-initrd-generator, and starts activating a persistent
connection. This requires also setting 'keep-configuration=no' to not
generate an assumed connection.
Add function nm_utils_connection_match_spec_list() to check whether a
connection matches a spec list. Also document the supported syntax in
the man page.
Add a new 'keep-configuration' device option, set to 'yes' by
default. When set to 'no', on startup NetworkManager ignores that the
interface is pre-configured and doesn't try to keep its
configuration. Instead, it activates one of the persistent
connections.
nmcli now accepts `nmcli device up|down` which works the same way as
`nmcli device connect|disconnect`
I also edited man pages of nmcli with new options.
`description-docbook` is the alternative tag to `description`, the
difference is that `description-docbook` expects docbook XML but not
plaintext.
Signed-off-by: Wen Liang <liangwen12year@gmail.com>
Since the [main].iwd-config-path functionality, where NM watches for
NMSettingsConnection changes and update IWD network config files with
new settings, has proven to work without issues so far, enable it by
default. Instead of hardcoding /var/lib/iwd as the value, and since the
value can't be probed at NM compile time, query it from IWD's recently-
added D-Bus interface for settings when [main].iwd-config-path is either
missing or set to the new value "auto".
If the configuration contains dns=none and resolv.conf is updated
through a dispatcher script, currently there is no way to tell NM that
the content of resolv.conf changed, so that it can restart a hostname
resolution.
Use SIGUSR1 (and SIGHUP) for that.
The code never set "iface_get_config->cidr_addr", despite
setting "cidr_prefix" and "has_cidr". As a result, cloud-setup
would think that the subnet is "0.0.0.0/$PLEN", and calculate
the gateway as "0.0.0.1".
As a result it would add a default route to table 30400 via 0.0.0.1,
which is obviously wrong.
How to detect the right gateway? Let's try obtain the subnet also via
the meta data. That seems mostly correct, except that we only access
subnet at index 0. What if there are multiple ones? I don't know.
https://bugzilla.redhat.com/show_bug.cgi?id=1912236
Watch for NMSettingConnection changes and creation signals and convert
them to IWD format and write them to the configured IWD profile storage
directory. The logic is off by default and gets enabled when the new
iwd-config-path setting in nm.conf's [main] group is set to a path to
an existing directory.
The idea here is that when a user edits an NM connection profile, the
change is immediately mirrored in IWD since IWD watches its
configuration directory using inotify. This way NM clients can be used
to edit 802.1x settings, the PSK passphrase or the SSID -- changes that
would previously not take effect with the IWD backend.
Some precautions are taken to not make connections owned by a user
available to other users, such connections are not converted at all.
In all other cases where a connection cannot be converted sufficiently
well to the IWD format, for various reasons, we also give up and not
mirror these connections.
Due to IWD limitations and design differences with NM this logic has
many problems where it may not do its task properly. It's meant to work
on a best-effort and "better than nothing" basis, but it should be safe
in that it shouldn't delete users data or reveal secrets, etc. The most
obvious limitation is that there can be multiple NM connections
referring to the same SSID+Security tuple and only one IWD profile can
exist because the filename is based on only the SSID+Security type. We
already had one NM connection selected for each IWD KnownNetwork and
referenced by a pointer, so we ignore changes in NM connections other
than that selected one.
Add support for `carrier-wait-timeout` setting from kernel cmdline.
This will create a new `15-carrier-timeout.conf` file in
/run/NetworkManager/conf.d with the parameter value as specified.
The setting also inserts `match-device` to `*`, matching all devices.
NB: The parameter on kernel cmdline is specified in seconds. This is
done to be backwards compatible with with network-legacy module. However
the generated setting will automatically multiply specified value by
1000 and store timeout value in ms.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/626https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/730
It's questionable whether the manual page should explain
exactly what it does.
However, it's a good exercise writing this up (to review
what happens). Also, a manual page that simply says "it configures
the network automatically" without going into how exactly, is
not very useful either.
NetworkManager is now able to configure veth interfaces throught the
NMSettingVeth. Veth interfaces only have "peer" property.
In order to support Veth interfaces in NetworkManager the design need
to pass the following requirements:
* Veth setting only has "peer" attribute.
* Ethernet profiles must be applicable to Veth interfaces.
* When creating a veth interface, the peer will be managed by
NetworkManager but will not have a profile.
* Veth connection can reapply only if the peer has not been modified.
* In order to modify the veth peer, NetworkManager must deactivate the
connection and create a new one with peer modified.
In general, it should support the basis of veth interfaces but without
breaking any existing feature or use case. The users that are using veth
interfaces as ethernet should not notice anything changed unless they
specified the veth peer setting.
Creating a Veth interface in NetworkManager is useful even without the
support for namespaces for some use cases, e.g "connecting one side of
the veth to an OVS bridge and the other side to a Linux bridge" this is
done when using OVN kubernetes [1][2]. In addition, it would provide
persistent configuration and rollback support for Veth interfaces.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
If this setting it true (or missing) we skip most of the D-Bus
Disconnect() calls whoe purpose was to keep IWD's internal autoconnect
mechanism always disabled. We use the IWD's Station.State property
updates, and secrets requets through our IWD agent, to find out when IWD
is trying to connect and create "assumed" activations on the NM side to
mirror the IWD state. This is quite complicated due to the many
possible combinations of NMDevice's state and IWD's state. A lot of
them are "impossible" but we try to be careful to consider all the
different possibilities.
NM has a nice API for "assuming connections" but it's designed for
slightly different use cases than what we have here and for now we
created normal "managed"-type activations when assuming an IWD automatic
connection.
Add a new `main.rc-manager=auto` setting, that favours to use
systemd-resolved (and not touch "/etc/resolv.conf" but configure
it via D-Bus), or falls back to `resolvconf`/`netconfig` binaries
if they are installed and enabled at compile time.
As final fallback use "symlink", like before.
Note that on Fedora there is no "openresolv" package ([1]). Instead, "systemd"
package provides "/usr/sbin/resolvconf" as a wrapper for systemd-resolved's
"resolvectl". On such a system the fallback to resolvconf is always
wrong, because NetworkManager should either talk to systemd-resolved
directly or not but never call "/usr/sbin/resolvconf". So, the special handling
for resolvconf and netconfig is only done if NetworkManager was build with these
applications explicitly enabled.
Note that SUSE builds NetworkManager with
--with-netconfig=yes
--with-config-dns-rc-manager-default=netconfig
and the new option won't be used there either. But of course, netconfig
already does all the right things on SUSE.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=668153
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Fix the following build error with meson:
/usr/bin/python3 /home/bgalvani/work/NetworkManager/tools/generate-docs-nm-settings-docs-merge.py man/nm-settings-docs-nmcli.xml --only-from-first clients/cli/generate-docs-nm-settings-nmcli.xml libnm/nm-propery-infos-nmcli.xml libnm/nm-settings-docs-gir.xml
Traceback (most recent call last):
File "/home/bgalvani/work/NetworkManager/tools/generate-docs-nm-settings-docs-merge.py", line 120, in <module>
xml_roots = list([ET.parse(f).getroot() for f in gl_input_files])
File "/home/bgalvani/work/NetworkManager/tools/generate-docs-nm-settings-docs-merge.py", line 120, in <listcomp>
xml_roots = list([ET.parse(f).getroot() for f in gl_input_files])
File "/usr/lib64/python3.8/xml/etree/ElementTree.py", line 1202, in parse
tree.parse(source, parser)
File "/usr/lib64/python3.8/xml/etree/ElementTree.py", line 584, in parse
source = open(source, "rb")
FileNotFoundError: [Errno 2] No such file or directory: '--only-from-first'
Fixes: 3c11116c48 ('docs: in "generate-docs-nm-settings-docs-merge.py" only take properties from first setting')
Especially for "nm-settings-docs-nmcli.xml", the first XML to merge is
"clients/cli/generate-docs-nm-settings-nmcli.xml". That file is
generated with the meta data from nmcli, and it contains all the
properties that are supported. Properties from other XML files,
that are passed as additional arguments should not be merged.
In most cases, there is no difference. It only matters for
"ipv6.dad-timeout" and "user.data". For example, "ipv6.dad-timeout"
is supported by GObject (part of "libnm/nm-settings-docs-gir.xml"),
but not by nmcli. Don't include it in the manual.
This also drops the now empty settings "dummy", "user", and "generic".
