Recent gettext version can extract and merge back strings from and to
various file formats, no need for intltool anymore.
https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigrationhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/133https://github.com/NetworkManager/NetworkManager/pull/303https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/96
Clarification about the use of AM_GNU_GETTEXT_REQUIRE_VERSION:
In configure.ac, specify the minimum gettext version we require, rather
than the exact one. This fixes a situation where the autoconf macros
used for gettext will be the latest available on the system (for
example, 0.20); but the copied-in Makefile.in.in will be for the exact
version specified in configure.ac (in this case, 0.19).
In that situation, the gettext build rules will error out at `make` time
with the message:
*** error: gettext infrastructure mismatch: using a Makefile.in.in
from gettext version 0.19 but the autoconf macros are from gettext
version 0.20
Avoid that by specifying a minimum version dependency rather than an
exact one. This should not cause problems as we haven’t committed any
generated or external gettext files into git, so each developer will end
up regenerating the build system for their system’s version of gettext,
as expected.
See the subsection of
https://www.gnu.org/software/gettext/manual/html_node/Version-Control-Issues.html
for more information.
Note that autoreconf currently doesn’t recognise
AM_GNU_GETTEXT_REQUIRE_VERSION, so we must continue also using
AM_GNU_GETTEXT_VERSION. autopoint will ignore the latter if the former
is present. See
https://lists.gnu.org/archive/html/autoconf-patches/2015-10/msg00000.html.
[lkundrak@v3.sk: Fixed the meson build, adjusted autogen.sh:
droped "|| exit 1", dropped call to aclocal,
dropped --copy from gtkdocize.]
In systemd, it's common that a D-Bus activatable service references
`SystemdService=dbus-$BUSNAME.service` instead the real service name.
Together with an `[Install].Alias=dbus-$BUSNAME.service` directive,
this allowed to enable/disable D-Bus activation without uninstalling the
service altogether ([1]).
Currently, when we install the RPM then `nm-priv-helper.service` is not
enabled, consequently the alias is not created, and D-Bus activation
does not work. I guess, we should fix that by enabling the service in
the %post section or via a systemd preset? Dunno.
Anyway. It seems that nm-priv-helper.service is more of an
implementation detail of NetworkManager. It makes not sense for the user
to interact directly, or to enable/disable D-Bus activation (because
that is how it works).
So, drop the alias.
See-also: [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#activation_dbus
"-" is not allowed as D-Bus path and interface name, and discouraged as
bus name. This cause nm-priv-helper to crash, because GDBus asserts the
the object path is valid.
Replace the '-' with '_'. This way, it's consistent with
"nm_dispatcher".
Fixes: d68ab6b8f0 ('nm-sudo: rename to nm-priv-helper')
NetworkManager handles "add" and "move" actions the same way, by
tracking the "struct udev_device" instance.
Still, this means that also for move events, we need the right
attributes set.
See-also: https://github.com/openshift/sriov-network-operator/issues/414
The advantage of environment variables is that the user can use
`systemctl edit NetworkManager-dispatcher.service` for setting them,
without need to change the ExecStart= line.
Also, enabling debugging from the start is useful, despite that debug
logging can be enabled per-request.
Also, there is a difference whether we want verbose logging or whether
we want to log to stdout. There should be a flag, that only increases the
logging verbosity, but does not change the logging backend.
- exit-on-idle needs to be done correctly. Fix the race, by first
notifying systemd (STOPPING=1), releasing the name, and all the
while continue processing requests.
- don't use g_bus_own_name_on_connection(). That one also listens
to NameLost and NameAcquired signals, but we don't care about those.
systemd will take care to only spawn one process at a time. And
anyway, the well-known name is only important to be reachable, we
don't require it to be functional. We can get the first request
before RequestName completed and we can continue getting requests
after releasing the name.
NetworkManager runs as root and has lots of capabilities.
We want to reduce the attach surface by dropping capabilities,
but there is a genuine need to do certain things.
For example, we currently require dac_override capability, to open
the unix socket of ovsdb. Most users wouldn't use OVS, so we should
find a way to not require that dac_override capability. The solution
is to have a separate, D-Bus activate service (nm-sudo), which
has the capability to open and provide the file descriptor.
For authentication, we only rely on D-Bus. We watch the name owner
of NetworkManager, and only accept requests from that service. We trust
D-Bus to get it right a request from that name owner is really coming
from NetworkManager. If we couldn't trust that, how could PolicyKit
or any authentication via D-Bus work? For testing, the user can set
NM_SUDO_NO_AUTH_FOR_TESTING=1.
https://bugzilla.redhat.com/show_bug.cgi?id=1921826
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
