| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
With a large number of interfaces, it can take longer than 45 seconds
before NetworkManager is started (and the D-Bus name acquired). Increase
the start timeout.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1612
|
| |
|
|
|
|
|
|
|
| |
Add "BindsTo=dbus.service" to NetworkManager.service so that when the
D-Bus service gets restarted, NM is also restarted instead of staying
stopped.
https://bugzilla.redhat.com/show_bug.cgi?id=2161915
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1605
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that POSIX select() can only handle up to 1024 descriptors. That
means, our code (and the libraries that we use) must not use select().
Note that libndp uses select(), which means NetworkManager will crash
when using file descriptors larger than 1023. On the other hand,
depriving NetworkManager of file descriptors will also crash it.
So libndp must be fixed ([1]).
[1] https://listman.redhat.com/archives/libndp-list/2021-February/msg00000.html
https://bugzilla.redhat.com/show_bug.cgi?id=1926599
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 2e334f54b27f91f40c3aa8bdba3254e2284d30bd.
|
| |
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=1921826
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/742
|
| |
|
|
|
| |
While dbus-send may not be installed, busctl is shipped with systemd
and so it should be always available.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the approach used by systemd-networkd.
I don't understand the logic that caused systemd-networkd to make the change -
https://github.com/systemd/systemd/commit/9e49656037717b96c06b1f1507a41550bdb2c795
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
|
| |
|
|
|
| |
instead of `kill -HUP`. We support "org.freedesktop.NetworkManager.Reload"
D-Bus method for a long time now. Use it because it is synchronous.
|
| |
|
|
|
|
|
|
|
|
| |
CAP_SYS_ADMIN
We don't want to enable this upstream, but make the requirement
more discoverable by documenting it and put a comment to
NetworkManager.service.
https://bugzilla.redhat.com/show_bug.cgi?id=1371201
|
| |
|
|
|
|
|
|
|
| |
Reference the nm-online and NetworkManager man page in the corresponding
service files.
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Documentation=
https://bugzilla.gnome.org/show_bug.cgi?id=767168
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=761001
|
| |
|
|
| |
CAP_SYS_CHROOT is needed for openvpn hardening.
|
| |
|
|
|
|
|
|
|
| |
Order NetworkManager after dbus. Otherwise during shutdown, both service are killed
together and possibly NetworkManager can no longer use D-Bus during shutdown. It
will need it however to communicate with VPN plugins and wpa-supplicant.
Related: https://bugs.freedesktop.org/show_bug.cgi?id=89847#c14
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1214466
|
| |
|
|
|
| |
It's for their own good. Otherwise stale dnsmasq instances haunt the shared
connections.
|
| |
|
|
| |
We need it to write messages to kernel auditing log.
|
| |
|
|
|
|
| |
Tested with dnsmasq (ipv4.method=shared), openvpn & vpnc.
https://bugzilla.gnome.org/show_bug.cgi?id=750598
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since f9e4af2, parts of the configuration can be reloaded
by sending SIGHUP to NetworkManager. Add ExecReload option
to service file to support reloading by sending a signal.
Note that 'man 5 systemd.service' advices to use a blocking
command instead of a sending a signal. Later we should add a
D-Bus method to allow reloading synchronously. For now, this
is better then nothing.
https://mail.gnome.org/archives/networkmanager-list/2015-April/msg00042.html
|
| |
|
|
|
|
|
|
|
|
| |
failure (bgo #741587)
Crashed NetworkManager.service was not restarted by systemd.
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
https://bugzilla.gnome.org/show_bug.cgi?id=741587
|
| |
|
|
|
|
| |
On Fedora/RHEL, NetworkManager.service needs to be started before
network.service, or else network.service may try to bring up NM's
devices itself.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Lennart sez:
"Oh, I wasn't aware it is short-lived only. In that case, drop the
multi-user.target bit, and just make it create the dbus alias.
[Install]
Alias=dbus-org.freedesktop.nm-dispatcher.service
And yeah, adding Also=NetworkManager-dispatcher.service to
NetworkManager.service certainly would be a good idea."
|
| |
|
|
|
|
|
| |
systemd's new network-online target abstracts the "wait until
networking is up" stuff, and NM-wait-online implements that
functionality. Thus NM-wait-online should be ordered before
(and thus be a dependency of) network-online.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When run with --no-daemon, NM used to duplicate all syslog output to
stderr, for ease of debugging. But this meant it had to tell systemd
to ignore stderr, so you wouldn't get duplicated log entries. But that
meant we lost error messages that didn't go through nm_log. (eg,
g_warning()s and g_return_if_fail()s).
Fix this by making --no-daemon no longer duplicate syslog output to
stderr, and removing the "StandardError=null" from the systemd service
file. To get the old behavior, you can use --debug instead of
--no-daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=700550
|
| |
|
|
|
|
|
|
|
|
| |
By default, when shutting NM down, systemd will kill everything in its
cgroup. But this can cause problems (eg, NM thinking that dhclient
crashed and then taking down an interface that it would otherwise have
left up). Fix this by setting KillMode=process, which tells systemd to
only kill NM itself, and let NM kill its children.
https://bugzilla.redhat.com/show_bug.cgi?id=876218
|
| |
|
|
| |
Mistakenly removed while merging 86f14392fc94189d24c0e65dcc5b2db74ca709ae
|
| |
|
|
|
| |
Inspired by openSUSE patches. There is no need to require
user/distributor manually enable nm-wait-online.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NetworkManager-wait-online.service
This pulls in network.target from NetworkManager.service (and not the
other way round), as suggested and agreed on on the systemd ML:
http://lists.freedesktop.org/archives/systemd-devel/2011-March/001692.html
This also introduces an auxiliary service
NetworkManager-wait-online.service that can be used to order a unit
after the point where the network is available. When this is enabled
with "systemd enable NetworkManager-wait-online.service" the unit
network.target will be delayed until the network is up, which is
suitable for synchronizing NFS mounts and similar to it.
https://bugzilla.redhat.com/show_bug.cgi?id=692008
|
| | |
|
| |
|
