The [.config] section is configuration about the configuration file itself,
it should not be merged.
Properly ignore the [.config] section before merging the configuration
file.
(cherry picked from commit ca5028e608)
Support 3 new flags for Reload:
- 0x01 (CONF): reload the configuration from disk
- 0x02 (DNS_RC): write DNS configuration to resolv.conf
- 0x04 (DNS_FULL): restart DNS plugin
Omitting all flags is the same as reloading everything, thus SIGHUP.
(cherry picked from commit 0acee97220)
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.
(cherry picked from commit 1d0e0eeffd)
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.
(cherry picked from commit eb6140a772)
Previously, on SIGHUP we would re-read the configuration and possibly
reconfigure DNS. However, if the DNS plugin didn't change, we would
not restart it. That is good, because restarting the DNS plugin shortly
interrupts name resolution.
dnsmasq might depend on additional configuration from /etc/NetworkManager/dnsmasq.d,
thus, the user also needs a way to restart the plugin to pickup the
configuration. For that, it could just kill the dnsmasq instance, but
that means, ratelimiting will hit and restarting dnsmasq too often
might bork the plugin for 5 minutes.
Now, on SIGHUP, also restart the DNS plugin. The advantage is that
one signal reloads everything, including the dnsmasq instance, without
ratelimiting.
The disadvantage is, that it shortly interrupts name resolution.
(cherry picked from commit 9ae307347b)
This also fixes cancelling the timeout in dispose().
Just to be explicit, also cancel it in dispose(),
although dispose() alreay calls _clear_plugin().
(cherry picked from commit a920155d0b)
_clear_plugin() should explicitly stop the DNS plugin, instead of just
unreferencing it. Unreferencing does not necessarily mean, that the
plugin will be destroyed right away.
(cherry picked from commit e1d5b27c4f)
The DNS priority property of a IP configuration determines how the
configuration compares to others when deciding their order, but
doesn't specify directly parameters to be applied. In other words, two
configurations which differs only for the dns-priority should have the
same hash as applying them will give the same result.
Especially, when the DNS manager computes the hash of IP
configurations, the ones without real configuration data (servers,
domans, options...) should not change the hash value.
Thus, exclude the property from the hash computation and dowgrade any
modification to 'minor change'.
Fixes: bfabfb05ae
Fixes: f09f5e1ec8
(cherry picked from commit 28938155e0)
Since 027f4c65ac, the ip_iface for
nm_dns_manager_add_ip_config() must be set.
Wit interface-less VPN types like libreswan, we thus hit the assertion
nm_dns_manager_add_ip_config: assertion 'iface && iface[0]' failed
Fix that, by fallback to the interface name of the parent device.
Fixes: 027f4c65ac
(cherry picked from commit 3f8a60def6)
and nm_vpn_connection_get_ip_ifindex(). For VPN types that have no own
IP interface, we often want instead lookup the IP interface from the
parent device.
(cherry picked from commit 18501d7b68)
ip_iface and ip_ifindex come as a pair. They must be either set both, or not
at all. Ensure that whenever setting one, the other is set too (or cleared).
(cherry picked from commit 5357b1874e)
Downstream might want to choose a different default value for
main.rc-manager setting (and it can does so, by compiling with
explicit resolvconf or netconfig support).
Make the default configurable at build-time and also embed it into
the manual page of "NetworkManager.conf".
https://bugzilla.redhat.com/show_bug.cgi?id=1337222
(cherry picked from commit 51791c4772)
Currently we don't specify to dnsmasq which interface must be used to
contact a given nameserver and so requests can be sent through the
wrong interface.
Fix this by concatenating a @interface prefix to each server (unless
an IPv6 interface scope-id is already present).
https://bugzilla.gnome.org/show_bug.cgi?id=765153
(cherry picked from commit b71e104d33)
Under no circumstance should a non-global configuration with NULL or
empty iface be added to the DNS manager. Assert this early and remove
other unnecessary checks.
(cherry picked from commit 027f4c65ac)
When a configuration is replaced by another with different metadata,
disconnect signals and clear @best_conf pointers. Also, the check in
remove_ip_config() was wrong.
Fixes: 8e6d442477
Fixes: 570d73979b
(cherry picked from commit fc8cc8393e)
Use the ipvx.dns-priority when sorting the array of
configurations. When a negative value is found, all following entries
with a greater value are skipped.
(cherry picked from commit 570d73979b)
Fall back to system default value for ipvx.dns-priority when it's zero
in the setting. For VPNs the default value is 50; for other
connections is 100, but it depends also on the content of
[connection*] sections in NetworkManager.conf.
(cherry picked from commit 77ded12da4)
In a following commit configurations will be ordered by their
priority; arrange them in a single array to make this simpler. Also,
instead of using g_object_set_data() to store metadata, introduce a
NMDnsIPConfigData structure.
(cherry picked from commit 8e6d442477)
If the initial hash includes the global configuration, every update
attempt will be skipped because the configuration never changes, and
resolv.conf will never be updated. Instead, use a NULL global
configuration to compute the hash and force an initial update.
(cherry picked from commit 16d5c8222b)
This is both supported by clang and gcc. Using it is nicer then
casting the (void), which requires an additional line of code.
(cherry picked from commit ee29228277)
The following settings are effectively identical:
dns=none,rc-manager=*any*
dns=none,rc-manager=unmanaged
dns=default,rc-manager=unmanaged
The new setting is only there for completeness and only
makes sense for a dns plugin.
(cherry picked from commit 2789345d5b)
Already previously, the mode and rc-manager were intertwined in a complicated
way:
- dns=none effectively disables rc-manager.
- if resolv.conf was immutable, it would disable the rc-manager
by setting "resolv_conf_mode=NM_DNS_MANAGER_RESOLV_CONF_UNMANAGED".
- resolv_conf_mode was anyway a redundant piece of information to
rc_manager.
Now there are only two relevant settings: priv->plugin and
priv->rc_manager. And they can be set independently from each other.
Before that was not possible. For example, you could not set a
dns plugin with rc-manager=unmanaged (the only way to achive that
was via an immutable resolv.conf or by having rc-manager=symlink
and let resolv.conf link somewhere else.
(cherry picked from commit 161f86b5b3)
The "dns" and "rc-manager" properties are strongly related. Initialize them
together in init_resolv_conf_mode().
One difference is, that we now set rc_manager before setting the mode.
But that shouldn't matter.
(cherry picked from commit a252dfdb9d)
Makes more sense in the next commit, when init_resolv_conf_manager()
gets merged with init_resolv_conf_mode(). Bear with me.
(cherry picked from commit aea2d98e2d)
We already have "rc-manager=file", rename "rc-manager=none" to "symlink"
because that better describes what it is actually doing. Of course, the
old name is still accepted.
(cherry picked from commit cd6a469668)
It is interesting to find in the logfile when we write to "/etc/resolv.conf"
or our internal version "/var/run/NetworkManager/resolv.conf".
(cherry picked from commit c486c38962)
Now that we support multiple VPNs active at the same time, the DNS
manager must be able to keep a list of all the VPN configurations and
give them a higher priority than other configurations.
Before this commit all the VPN configuration except one were
considered as normal configurations.
https://bugzilla.gnome.org/show_bug.cgi?id=764689
(cherry picked from commit f439f05237)
A HUP or USR1 signal forces the rewrite of DNS configuration, however
caching plugins are ignored when using dns=dnsmasq and so the real
servers are written to resolv.conf:
$ cat /etc/resolv.conf
nameserver 127.0.0.1
# killall -USR1 NetworkManager
$ cat /etc/resolv.conf
nameserver 192.168.1.1
Set @no_caching to FALSE when calling update_dns() after a signal to
take caching plugins into account.
(cherry picked from commit b88ce6d044)
The NM_AVAILABLE_IN_* and NM_DEPRECATED_IN_* macros are kinda internal macros
to mark public API (although they are in public headers).
On 1.2 branch, we will never add a new API that is marked with one of the
1.4 macros, because from 1.2's point of view 1.4 does not exist. Remove
those macros, but add instead a 1.2.4 macro that we will use.
Otherwise, when killing dnsmasq it does not get respawned:
dnsmasq[0x560dd7e43cf0]: dnsmasq exited normally
dns-mgr: plugin dnsmasq child quit unexpectedly
dns-mgr: update-dns: updating resolv.conf
dns-mgr: config: 100 best v4 enp0s25
dns-mgr: config: 100 best v6 enp0s25
dns-mgr: config: 100 default v6 lo
dns-mgr: config: 100 default v4 lo
dns-mgr: update-dns: updating plugin dnsmasq
dnsmasq[0x560dd7e43cf0]: adding nameserver '192.168.0.2@enp0s25'
dnsmasq[0x560dd7e43cf0]: trying to update dnsmasq nameservers
dns-mgr: update-resolv-conf: write internal file /var/run/NetworkManager/resolv.conf succeeded but don't update /etc/resolv.conf as it points to resolv.conf.nm
dnsmasq[0x560dd7e43cf0]: dnsmasq disappeared
Previously, we would create priv->dnsmasq proxy only once,
and not respawn the process at all.
https://bugzilla.gnome.org/show_bug.cgi?id=766996
(cherry picked from commit 2e7f4aeb60)
When the ipv4.dhcp-fqdn property is set, NM adds the following options
to dhclient.conf:
send fqdn.fqdn "foo.bar";
send fqdn.encoded on;
send fqdn.server-update on;
which enable the S (server-update) and E (encoded) flags in DHCP
option 81, since they are sensible default values and dhclient
requires a "send fqdn.server-update [on|off]" directive in order to
send the option.
Users may want to change these flags according to their server's
configuration, but this is not possible at the moment since NM options
are placed after user's ones, overriding them.
To fix this, collect user's fqdn options and add them after NM
configuration; note that the fqdn.fqdn option still can't be
overridden by users, as NM must control the FQDN sent to server.
Fixes: c3573ebf2b
(cherry picked from commit f940428c65)
For changing the hardware address, we must bring the device down. When doing
that, IP addressing is lost and it must be re-configured after bringing the
device up again.
We already do something similar in device_link_changed(), but that might
not be sufficient, because device_link_changed() is run on an idle
handler, thus, while changing the hardware address it has no chance to
run (or notice that the device was shortly down).
https://bugzilla.redhat.com/show_bug.cgi?id=1309899
(cherry picked from commit 63571b2666)
