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
No longer support disabling the global-dns configuration via the
"enable" option.
Instead, the user can put the entire dns-configuration in one separate
snippet, and disable it altogether with ".config.enable".
Support a new configuration option
[.config]
enable=<ENABLED>
for configuration snippets.
This new [.config] section is only relevant within the snippet itself
and it is not merged into the combined configuration.
Currently only the "enable" key is supported. If the "enable" key is
missing, it obviously defaults to being enabled. It allows snippets
to be skipped from loading. The main configuration "NetworkManager.conf"
cannot be skipped.
<ENABLED> can be a boolean value (false), to skip a configuration
snippet from loading.
It can also be a string to match against the NetworkManager version,
like "enable=nm-version-min:1.1,nm-version-min:1.0.6"
There are several motivations for this:
- the user can disable an entire configuration snippet by toggeling
one entry.
This generalizes the functionality of the global-dns.enable
setting, but in a way that applies to configuration on a per-file
basis.
- for developing, we often switch between different versions of
NetworkManager. Thus, we might want to use different configuration.
E.g. before global-dns options, I want to use "dns=none" and manage
resolv.conf myself. Now, I can use global-dns setting to do that.
That can be achieved with something like the following (not exactly,
it's an example only):
[.config]
enable=nm-version-min:1.1
[main]
dns=default
[global-dns-domain-*]
nameserver=127.0.0.1
Arguably, this would be more awesome, if we would bump our micro devel
version (1.1.0) more often while developing 1.2.0 (*hint*).
- in principle, packages could drop configuration snippets and enable
them based on the NetworkManager version.
- with the "env:" spec, you can enable/disable snippets by configuring
an environment variable. Again, useful for testing and developing.
