We always build with PolicyKit support enabled, because it has no
additional dependencies, beside some D-Bus calls.
However, in NetworkManager.conf the user could configure
"main.auth-polkit" to disable PolicyKit. However, previously it would
only allow to disable PolicyKit while granting access to all users.
I think it's useful to have an option that disables PolicyKit and grants
access only to root. I think we should not go too far in implementing
our own authorization mechanisms beside PolicyKit (e.g. you cannot
disable PolicyKit and grant access based on group membership of the
user). However, disabling PolicyKit can be useful sometimes, and it's
simple to implement a "root-only" setup.
Note one change is that when NetworkManager now runs without a D-Bus
connection (in initrd), it would deny all non-root requests. Previously
it would grant access. I think there should be little difference in
practice, because if we have no D-Bus we also don't have any requests to
authenticate.
(cherry picked from commit 6d7446e52f)
We no longer add these. If you use Emacs, configure it yourself.
Also, due to our "smart-tab" usage the editor anyway does a subpar
job handling our tabs. However, on the upside every user can choose
whatever tab-width he/she prefers. If "smart-tabs" are used properly
(like we do), every tab-width will work.
No manual changes, just ran commands:
F=($(git grep -l -e '-\*-'))
sed '1 { /\/\* *-\*- *[mM]ode.*\*\/$/d }' -i "${F[@]}"
sed '1,4 { /^\(#\|--\|dnl\) *-\*- [mM]ode/d }' -i "${F[@]}"
Check remaining lines with:
git grep -e '-\*-'
The ultimate purpose of this is to cleanup our files and eventually use
SPDX license identifiers. For that, first get rid of the boilerplate lines.
The early boot tooling gets the root-path from our state file due to a
lack of a better way to do that. However, when booting with NFS root,
the root path alone is not sufficient; the server address is communicated
via the next-server option. Save that one in the state file as well.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/168
It's deprecated and off by default for a long time.
It is bad to automatically reload connection profiles. For example, ifcfg
files may consist of multiple files, there is no guarantee that we
pick up the connection when it's fully written.
Just don't do this anymore.
Users should use D-Bus API or `nmcli connection reload` or `nmcli
connection load $FILENAME` to reload profiles from disk.
We need a mode that:
* doesn't leave processes behind
* doesn't force an internal dhclient
* doesn't auto-generate default connections
* doesn't write out files into libdir, only /run
The original configure-and-quit mode doesn't really fit the initrd use. But
it's proobably not a good idea to just change its behavior.
On networked boot we need to somehow communicate this to the early boot
machinery. Sadly, no DBus there and we're running in configure-and-quit
mode.
Abusing the state file for this sounds almost reasonable and is
reasonably straightforward thing to do.
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
Even Gentoo disables this plugin since before 0.9.8 release
of NetworkManager. Time to say goodbye.
If somebody happens to show up to maintain it, we may resurrect it
later.
If "$distro_plugins=ifnet" was set, configure.ac would use that
to autodetect --with-hostname-persist=gentoo. Replace that autodetect
part by checking for /etc/gentoo-release file.
NMManager tries to assign unique route-metrics in an increasing manner
so that the device which activates first keeps to have the best routes.
This information is also persisted in the device's state file, however
we not only need to persist the effective route-metric which was
eventually chosen by NMManager, but also the aspired metric.
The reason is that when a metric is chosen for a device, the entire
range between aspired and effective route-metric is reserved for that
device. We must remember the entire range so that after restart the
entire range is still considered to be in use.
Fixes: 6a32c64d8f
NMManager will need to know the state of all device at once.
Hence, load it once and cache it in NMConfig.
Note that this wastes a bit of memory in the order of
O(number-of-interfaces). But each device state entry is
rather small, and we always consume memory in the order
of O(number-of-interfaces).
Let the config file select between creating classes of NMDeviceWifi
(for the usual wpa_supplicant based devices) and NMDeviceIwd depending
on the new NetworkManager.conf setting.
[bgalvani@redhat.com: fix leaking @backend in create_device()]
We already have various ways to mark a device as unmanaged.
1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus
at runtime.
2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and
keyfile.unmanaged-devices in NetworkManager.conf.
3) at runtime, via D-Bus. This is persisted in the run state file
and persists restarts (but not reboot).
This adds another way via NetworkManager.conf file. Note that the
existing keyfile.unmanaged-devices (above 2) is also a configuration
optin in NetworkManager.conf. However it has various downsides:
- it cannot be overwritten at runtime (see commit
c210134bd5).
- you can only explicitly mark a device as unmanaged. That means,
you cannot use it to manage a device which is unmanaged due to
a udev rule.
- the name "keyfile.*" sounds like it's only relevant for the keyfile settings
plugin. Nowadays the keyfile plugin is always loaded, so the option applies
to NetworkManager in general.
https://github.com/NetworkManager/NetworkManager/pull/29
Commits 39d0559d9a ("platform: sort links by name instead of
ifindex") and 529a0a1a7f ("manager: sort slaves to be autoconnected
by device name") changed the order of activation of slaves. Introduce
a system-wide configuration property to preserve the old behavior.
https://bugzilla.redhat.com/show_bug.cgi?id=1452585
nm_config_device_state_*() always access the file system directly,
they don't cache data in NMConfig. Hence, they don't use the
@self argument.
Maybe those functions don't belong to nm-config.h, anyway. For lack
of a better place they are there.
(cherry picked from commit 1940be410c)
For example, when starting without Wi-Fi plugin, a generic device
is created. On stop, we should not store the unmanaged state
on the state file, otherwise after restart the device is unmanaged.
Only store explicit user decisions.
https://bugzilla.redhat.com/show_bug.cgi?id=1440171
(cherry picked from commit 142ebb1037)
Also, ifnet plugin would read the configuration value, which is just wrong
because:
- the configuration might not be set and ifnet would fail to fallback
to the compile time default.
- the configuration only is in effect if the plugin is also available.
Otherwise, we fallback to the next plugin.
Only the dhcp-manager knows which DHCP plugin is in use.
Instead of having the caller do the fallback to the compile time default
plugins, let it be handled by nm_config_get_plugins().
The knowledge of fallback to a compile time default (and how to do that
properly) should be inside NMConfig/NMConfigData alone.
Also, as this function is only called once, let NMConfig not cache
the string list but create it once as needed.
On devices that have no real permanent hardware address (as returned
by ethtool), we take the current MAC address of the device.
Currently, NM is a bit flaky about whether to accept such fake permanent
addresses for settings like keyfile.unmanaged-devices or the per-
connection property ethernet.mac-address. Probably, we should allow
using fake addresses there in general.
However, that leads to problems because NetworkManager itself changes
the current MAC address of such devices. For example when
configuing
keyfile.unmanaged-device=22:33:44:55:66:77
and later activating a connection with
ethernet.cloned-mac-address=22:33:44:55:66:77
we have a strange situation after restart and the device becomes
unmanaged.
We are going to avoid that, by remembering the fake permanent address
in the device state file.
This only matters:
- for devices that don't have a real permanent address (veth)
- if the user or NetworkManager itself changed the MAC address
of the device
- after a restart of NetworkManager, without reboot. A reboot
clears the device state for /var/run/NetworkManager.
- use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere.
- reorder statements, to have GObject related functions (init, dispose,
constructed) at the bottom of each file and in a consistent order w.r.t.
each other.
- unify whitespaces in signal and properties declarations.
- use NM_GOBJECT_PROPERTIES_DEFINE() and _notify()
- drop unused signal slots in class structures
- drop unused header files for device factories
The data is still unused, the actual fields might change.
Note that the actual state we store is subject to change,
according to which data we need. The file format is non stable,
as the files don't survive reboot. So there is no backward
compatibility to maintain and the format can be changed later.
NetworkManager.conf already contains several per-device settings,
that is, settings that have a device-spec as argument.
main.ignore-carrier
main.no-auto-default
main.assume-ipv6ll-only
keyfile.unmanged-devices
Optimally, these settings should be moved to the new [device*]
section.
For now, only move main.ignore-carrier there. For the others
it may not make sense to do so:
- main.no-auto-default: is already merged with internal state
from /var/lib/NetworkManager/no-auto-default.state. While
NMConfig's write API would be fine to also persist and merge
the no-auto-default setting, we'd still have to read the old
file too. Thus, deprecating this setting gets quite cumbersome
to still handle the old state file.
Also, it seems a less useful setting to configure in the
global configuration aside setting main.no-auto-default=*.
- main.assume-ipv6ll-only: one day, I hope that we no longer
assume connections at all, and this setting becomes entirely
obsolete.
- keyfile.unmanged-devices: this sets NM_UNMANAGED_USER_SETTINGS,
which cannot be overruled via D-Bus. For a future device.managed
setting we want it it to be overwritable via D-Bus by an explicit
user action. Thus, a device.managed property should have a different
semantic, this should be more like a device.unmanaged-force setting,
which could be done.
Add a new [device*] section to NetworkManager.conf. This works similar
like the default connection settings in [connection*].
This will allow us to express per-device configuration in NetworkManager.conf
in our familar style.
Later, via NMConfig's write API it will be possible to make settings
accessible via D-Bus and persist them in NetworkManager-intern.conf.
This way, the user can both edit configuration snippets and modify
them via D-Bus, and also support installing default configuration
from the package.
In a way, a [device*] setting is similar to networkd's link files.
The match options is all encoded in the match-device specs.
One difference is, that the resulting setting can be merged together
by multiple section by partially overwriting them. This makes it
more flexible and allows for example to drop a configuration snippet
that only sets one property, while the rest can be merged from different
snippets.
For the most part, this patch just renames some change-flags, but
doesn't change much about them. The new name should better express
what they are.
A config-change signal can be emitted for different reasons:
when we receive a signal (SIGHUP, SIGUSR1, SIGUSR2) or for internal
reasons like resetting of no-auto-default or setting internal
values.
Depending on the reason, we want to perform different actions.
For example:
- we reload the configuration from disk on SIGHUP, but not for
SIGUSR1.
- For SIGUSR1 and SIGHUP, we want to update-dns, but not for SIGUSR2.
Another part of the change-flags encodes which part of the configuration
actually changed. Often, these parts can only change when re-reading
from disk (e.g. a SIGUSR1 will not change any configuration inside
NMConfig).
Later, we will have more causes, and accordingly more fine-grained
effects of what should be done on reload.
After all, this state is stored persistently to /var/lib/NetworkManager,
and not to volatile storage in /var/run. Hence the name is better.
It's also shorter, so rename it.
The commit is mostly trivial, including update of code comments
and logging messages.
Fixes: 1b43c880ba
Move reading and writing of the state file to NMConfig
("/var/lib/NetworkManager/NetworkManager.state" file).
Originally, I intended to persist more state, thus it made
sense to cleanup handling of the state file and move it all
at one place. Now, it's not clear that will happen anytime soon.
Still, the change is a worthy cleanup, so do it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=764474
