Well, that was short. Seems we need CAP_DAC_OVERRIDE at least for the
OVS plugin. The OVS socket is
srwxr-x---. 1 openvswitch openvswitch 0 Xxx xx xx:xx /run/openvswitch/db.sock
and without CAP_DAC_OVERRIDE, NetworkManager cannot talk to OVS.
We should fix that differently by adding a nm-sudo D-Bus service that
can hand a file descriptor to NetworkManager.
This reverts commit 2e334f54b2.
> If there is no network [1] to connect to (if network interface is down [2])
> NetworkManager will make "nm-online -s" stop [3] without waiting.
[1] we usually talk about connection profiles or devices/interfaces
[2] it would be better to say, if no suitable profile is ready to
autoconnect.
[3] `nm-online -s` waits until NetworkManager declares "startup
complete" reached.
I find the wording of the comment not very clear or useful.
Possibly I don't understand it properly, but that is a problem
for a comment that is supposed to help.
Remove it.
We encountered the following situation:
* nm-online (NetworkManager-wait-online.service) is started
* NetworkManager tries to configure network
* the first try of using dhclient fails with timeout for some reasons
* the second try of running dhclient completes successfully (NMs tries himself)
We get a working network, but it takes more that 30 seconds.
NetworkManager-wait-online.service fails, it may be a false negative
to checkers of network being online. It will also be a false positive signal
to start mounting network (CIFS, NFS etc.) shares, for example, because
they depend from network-online.target and network-online.target will become
reached right after NetworkManager-wait-online.service fails.
So, it makes sense to increase default timeout from 30 to 60 seconds.
@thaller wrote in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/237
that there may be cases where, for example, incorrectly set up bridges
or just network may lead to delays when booting the system.
Yes, but:
* if there is no possibility to start trying to connect the network, e.g. if all network interfaces,
managed by NetworkManager, are DOWN, NM will not try to connect network and "nm-online -s" will
exit with 0 without waiting (so, this will not prolong start up of workstations or servers
when ethernet cable is just not plugged in)
* an additional potential 30 seconds delay seems to be less harmful then a false positive to start
mounting network shares or doing abything else too eraly, when an additional wait for a few seconds
would have prevented those things from failing.
All things considered, it seems reasonable to increase this timeout from 30 seconds to 1 minute (60 seconds).
Signed-off-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/675
Install a NM-specific firewalld zone to be used for interfaces that
are used for connection sharing. The zone blocks all traffic to the
local machine except some protocols (DHCP, DNS and ICMP) and allows
all forwarded traffic.
The 'Before' dependency between NM-dispatcher and NM causes a deadlock
when stopping the NM service. When terminating, NM wants to D-Bus
activate NM-dispatcher to synchronously handle pre-down events; but
NM-dispatcher start is ordered after NM shutdown due to the following
behavior described in systemd.unit(5) man page:
Given two units with any ordering dependency between them, if one
unit is shut down and the other is started up, the shutdown is
ordered before the start-up. It doesn't matter if the ordering
dependency is After= or Before=, in this case. It also doesn't
matter which of the two is shut down, as long as one is shut down
and the other is started up; the shutdown is ordered before the
start-up in all cases.
So, NM is waiting NM-dispatcher to start and NM-dispatcher is queued
by systemd, waiting that NM is stopped. The result is a 90 seconds
delay, after which systemd kills NM and continues.
The dependency was added so that during shutdown NM-dispatcher would
be stopped after NM. I don't think it worked as expected because
NM-dispatcher is not supposed to be active most of the times, and so
it doesn't need a dependency that delays its stop after NM.
This reverts commit acc335aad4.
We don't need such data duplicated. The build setup should
have only one configuration_data() for patching such values.
Now we only have one global, immutable data_conf dictionary with
configuration values. Note that none of the users of data_conf uses all
entries, but as the entries are basically only dependent on the
meson/configure option and valid for the entire project, this simplifies
to handling.
Some variables belong to variables in their correspondent pkg-config
file.
These variables have been renamed to `dependency_variable` to
reflect the dependency and variables from pkg-config files they are
related to.
Some of these has also been fixed to use paths relative to
installation prefix.
Functions derived from generators as `configure_file`,
`custom_target` and `i18n.merge_file` can use placeholders like
`@BASENAME@` that removes the extension from the input filename
string.
The output string has been replaced by this placeholder that
allows in some cases the use of less variables.
Systemd v243 is complaining about the wrong substitution there. That is
sort of harmless, because systemd-udevd in that version doesn't need the
rule anyway. But still fix it, to avoid a warning.
Also, newer udevd's $PATH doesn't include sbin. That is also okay,
because we don't need the rule to actually work there. But fix it
anyway.
https://bugzilla.redhat.com/show_bug.cgi?id=1740655
WARNING: Project targetting '>= 0.44.0' but tried to use feature
introduced in '0.50.0': install arg in configure_file
From the documentation:
"install (added 0.50.0) When true, this generated file is installed
during the install step, and install_dir must be set and not
empty. When false, this generated file is not installed regardless of
the value of install_dir. When omitted it defaults to true when
install_dir is set and not empty, false otherwise."
The parameter can be omitted because install_dir is set.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/216
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
During shutdown, systemd should first stop NetworkManager and then
the dispatcher service. Note that dispatcher service is D-Bus activated,
so the two services don't Want/Require each other. But the ordering
still matters.
Previously, Wi-Fi scans uses polkit action
"org.freedesktop.NetworkManager.network-control". This is introduced
in commit 5e3e19d0. But in a system with restrict polkit rules, for
example "org.freedesktop.NetworkManager.network-control" was set as
auth_admin. When you open the network panel of GNOME Control Center, a
polkit dialog will keep showing up asking for admin password, as GNOME
Control Center scans the Wi-Fi list every 15 seconds.
Fix that by adding a new polkit action
"org.freedesktop.NetworkManager.wifi.scan" so that distributions can
add specific rule to allow Wi-Fi scans.
[thaller@redhat.com: fix macro in "shared/nm-common-macros.h"]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/68
Correct the spelling across the *entire* tree, including translations,
comments, etc. It's easier that way.
Even the places where it's not exposed to the user, such as tests, so
that we learn how is it spelled correctly.
If the NetworkManager daemon has been stopped manually we don't want it
to be autostarted by a client request.
[lkundrak@v3.sk: The auto-activation is probably more surprising than useful.
Services that need NetworkManager API should depend on NetworkManager service
directly.
I have no idea what purpose does the D-Bus service file serve nowadays,
but it looks rather hacky (really, activating /bin/false) and the comment
in it suggests that the autoactivating behavior was not intended anyway.
Debian has been shipping this for quite some time and no complains have been
heard.]
https://github.com/NetworkManager/NetworkManager/pull/230
Load the thunderbolt-net module if we see a host-to-host connection
and configure the resulting ethernet connection automatically to be
a link-local only one. The latter is done by setting a new udev
property "NM_AUTO_DEFAULT_LINK_LOCAL_ONLY" which is picked up when
we configure the connection for the device.
https://github.com/NetworkManager/NetworkManager/pull/97
This is the approach used by systemd-networkd.
I don't understand the logic that caused systemd-networkd to make the change -
9e49656037
Instead, I am suggesting it for consistency, and because it seems to me this is the
exact correct behaviour. Because if you enable NetworkManager, and rely on it to
configure your network devices, then network mounts will not start correctly at boot
time unless you also enable NetworkManager-wait-online.service.
Enabling NetworkManager-wait-online.service does not cause unnecessary serialization
of the boot process; it is only pulled in if something else (like a network mount)
pulls in network-online.target.
I am suggesting this in response to reading this user support request [1].
[1] https://unix.stackexchange.com/questions/429604/fstab-not-automatically-mounting-smb-storage
[thaller@redhat.com: reworded commit message]
https://github.com/NetworkManager/NetworkManager/pull/76
`systemctl start network-online.target` should suffice to start
"NetworkManager.service".
That would work because
- "network-online.target" has "Wants=NetworkManager-wait-online.service"
- "NetworkManager-wait-online.service" has "Require=NetworkManager.service".
But previously, "NetworkManager-wait-online.service" would just
fail with missing dependency.
See also https://github.com/systemd/systemd/pull/6065 which does the
same for networkd's wait-online serice, and see rh#1452866 for a
use-case.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1452866
Add new Reload D-Bus command to reload NetworkManager configuration.
For now, this is like sending SIGHUP to the process. There are several
advantages here:
- it is guarded via PolicyKit authentication while signals
can only be sent by root.
- the user can wait for the reload to be complete instead of sending
an asynchronous signal. For now, we operation completes after
nm_config_reload() returns, but later we could delay the response
further until specific parts are fully reloaded.
- SIGHUP reloads everything including re-reading configuration from
disk while SIGUSR1 reloads just certain parts such as writing out DNS
configuration anew.
Now, the Reload command has a flags argument which is more granular
in selecting parts which are to be reloaded. For example, via
signals the user can:
1) send SIGUSR1: this writes out the DNS configuration to
resolv.conf and possibly reloads other parts without
re-reading configuration and without restarting the DNS plugin.
2) send SIGHUP: this reloads configuration from disk,
writes out resolv.conf and restarts the DNS plugin.
There is no way, to only restart the DNS plugin without also reloading
everything else.
network.target is a very early boot target which basically says "I can start
opening sockets now". It has nothing to do with being connected to the internet
and is often required by early boot services as well.
Drop the unnecessary and wrong Wants=/Before=network.target to avoid dependency
cycles and boot delays.
https://bugzilla.gnome.org/show_bug.cgi?id=746039https://launchpad.net/1430280
Those are not required with systemd-udevd v210 or newer. This way
distros which have a new enough version of udev can skip installing
84-nm-drivers.rules. While at it, don't use absolute paths for sed and
ethtool.