It doesn't actually work inside the root-less container...
Well, it works as far as starting to activate, before it
fails. That is still somewhat useful. So have it there...
The majority of times when I call this script, I want it to do the reformatting,
not the check-only mode. This is also because we use git, so I start with a
clean working directory and run the reformatting code. In the best case, there
is nothing to reformat, and all is good. I seldom want to only check.
Change the default of the script.
"nm-code-format.sh" is going to change the default behavior from "-n" to
"-i", that is, from check-only to reformat. Explicitly pass "-n" where
we want it.
There was always the idea that you could pass paths and filenames
to "nm-code-format.sh" to format only a subset. However, the script
also needs to honor files that should be excluded and don't need
formatting.
Previously, what was implemented via `git ls-files -- ':(exclude)...'`
command, but git-ls-files has a bug ([1]) and might not list all files.
Refactor and do the filtering ourselves.
[1] https://www.spinics.net/lists/git/msg397982.html
The only reason is consistency. The majority of times we
do use g_snprintf(). As there are no strong reasons to
prefer one over the other, prefer the one that use use
most of the time.
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
g_idle_add() is discouraged, and the checkpatch.pl script warns
about it.
Sometimes there is a legitimate use of it, when you want to always
schedule an idle action (without intent to cancel or track it). That
makes more sense for g_idle_add() than it does for g_timeout_add(),
because a timeout really should be tracked and cancelled if necessary.
Add a wrapper to rename the legitimate uses. This way, we can avoid the
checkpatch.pl warnings, and can grep for the remaining illegitimate uses.
The numeric source IDs exist from a time before 2000, when there
was only one "GMainContext" singleton instance. Nowadays, the source
ID is only relative to one GMainContext, and you'd have to track
that association yourself. Als, g_source_remove() requires an additional
hash lookup, when you could simply track the GSource instance from the
start.
This API should not be used anymore. Operate on GSouce instances
direclty and use API like
nm_clear_g_source_inst()
nm_g_idle_add_source()
nm_g_idle_souce_new()
nm_g_source_attach()
g_source_attach
g_source_destroy
g_source_unref
etc.
Note that if you don't care about to ever remove a source again, like
scheduling an idle action that should not be cancelled, then
g_idle_add(callback, user_data);
is fine. It is only problematic to do something with those numeric IDs.
checkpatch.pl would also flag those uses, but these are just warnings
and in the few cases where such a warning is emitted wrongly, it's find
to ignore them.
It's an example for how to use libnm and asynchronous API.
But it's also a script I will use to test activating many
profiles in parallel.
Also add a test script that creates many veth interfaces and connection
profiles. So now you can do:
sudo NUM_DEVS=100 contrib/scripts/test-create-many-device-setup.sh setup
./examples/python/gi/nm-up-many.py c-a{1..100}
and cleanup with
nmcli connection down c-a{1..100}
sudo contrib/scripts/test-create-many-device-setup.sh cleanup
Of course, be careful to do this on your production machine.
Changing "NetworkManager.conf" is problematic, because the package management
system will detect if the user modified the file and leave .rpmnew files (or
similar).
Still, we only recently modified the file already to mention Libera.Chat.
So now is the time for more rewording.
Ups, we actually still require libuuid. Actually, we only need to
to build the example script `examples/C/glib/add-connection-gdbus.c`.
The proper solution would be to make this an optional dependency.
So far this was not yet done. Also, libuuid is really an ubiquitous
dependency on Linux, so it's not really a problem to have this build
dependency, even if it's just to build the examples.
This reverts commit c0a3947ff9.
These subpackages existed before commit 886366d0fd ('contrib/rpm:
update spec file after renaming NM plugins') (2014, before 0.9.9.95).
rpm warns about unversioned obsoletes like:
It's not recommended to have unversioned Obsoletes: Obsoletes: NetworkManager-atm
It's not recommended to have unversioned Obsoletes: Obsoletes: NetworkManager-bt
These packages are so long gone by now, let's just drop the Obsoletes.
"dhcdbd" is gone since 2007. Drop it. Also, rpm doesn't really like
unversioned obsoletes and warns:
It's not recommended to have unversioned Obsoletes: Obsoletes: dhcdbd
We really only require "iptables" as build dependency to autodetect the
path where iptables is installed. On Fedora/RHEL, this is always /usr/sbin,
so we can just as well hard code this.
Alternatively, if the autodetection is really necessary, we would also require
a build dependency on /usr/sbin/nft. That seems a waste.
"/etc/NetworkManager/VPN" was historically the place for .name files for
VPN plugins. In the meantime, those should be under "/usr/lib/NetworkManager/VPN".
Still, NetworkManager honors (and possibly watches) the directory in
/etc. Mark the directory as %ghost.
The exact effect of this is not clear to me. It seems however right to
do, and works for my testing.
Since commit a447942fc0 ('contrib/rpm: rename package
"NetworkManager-config-routing-rules" to
"NetworkManager-dispatcher-routing-rules"'), the config-routing-rules
subpackage is gone.
This way to specify the version number with a variable parameter, causes
repeated messages in rpmdiff:
INFO NetworkManager-dispatcher-routing-rules changed from Obsoletes: NetworkManager-config-routing-rules < 1:1.32.0-0.2.el8 to Obsoletes: NetworkManager-config-routing-rules < 1:1.32.0-0.3.el8 on noarch
Avoid this by hard coding the obsoleted version.
This "Conflicts" is since commit b85b8ed6fa ('contrib/rpm: let
NetworkManager-libnm and NetworkManager-glib of differing version
conflict'). This was probably fine back then, but NetworkManager-glib is
long gone.
Also, not hard coding the version number leads to rpmdiff messages like:
NEEDS INSPECTION NetworkManager-libnm changed from Conflicts: NetworkManager-glib < 1:1.32.0-0.2.el8 to Conflicts: NetworkManager-glib < 1:1.32.0-0.3.el8 on all architectures
As NetworkManager-glib is long gone, hard code the version with which
we conflict.
On Fedora 33, we get it automatically because "clang" package
has an indirect (weak) dependency for clang-tools-extra. On
Fedora 34, that is no loger the case.
We need to explicitly install it.
When supported by the D-Bus daemon, it's better to have service files
in /usr rather than in /etc. Change the path for RHEL 8.
See also commit ef8c292881 ('contrib/rpm: install D-Bus service
files to /usr if we can').
