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)
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)
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)
It turnes out that 'nm_dns_manager_add_ip{4,6}_config' can be called to add VPN/DEVICE
config for device that already has one. On this case old config gets overwritten in
'priv->ip{4,6}_{vpn,device}_config' but is not removed from 'priv->configs'.
The result of that is that old config still being applyed but is treated as 'other'
config.
Apart from being a slight memory leak this has user facing consequences: if old config
was a split DNS VPN config 'split DNS' part will no longer work and those DNS servers
will be used as 'global' DNS servers.
This patch addresses the problem by making sure old values in 'priv->ip{4,6}_{vpn,device}_config'
are removed from 'priv->configs' before new values are applyed.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
When the list of DNS servers changes, old DNS entries cached by
dnsmasq must be invalidated as the answers returned by new servers may
be different (especially, old NXDOMAIN entries may now be valid). Call
the dnsmasq "ClearCache" D-Bus method to achieve this.
https://bugzilla.redhat.com/show_bug.cgi?id=1338731
(cherry picked from commit 4feb58b50b)
Sometimes the netlink event lacks the IFLA_ADDRESS attribute with
the MAC address of the link. In this case, take the value from
the cached link instance. A missing netlink attribute should have the
meaning of reusing the previous value, not clearing the address.
(cherry picked from commit 791cbd0817)
To allow the execution of asynchronous actions before the system is
suspended, add a mechanism for delaying the drop of inhibitor lock.
Clients can supend the suspension by calling inhibit_take() in their
handler for SLEEPING signal and use inhibit_release() later when they
are done.
We take a "delay" type inhibitor lock, which means that the system
will proceed anyway after a certain amount of time.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
(cherry picked from commit 69ab984fed)
The only user of the sleep-monitor singleton was NMManager anyway.
Also, even if we ever get more users that are interested in the SLEEPING
signal, we would hook them onto NMManager -- because NMManager should
collect, coordinate and possibly forward the SLEEPING signal. In no case,
another object should react on the SLEEPING signal and thus bypassing the
NMManager.
(cherry picked from commit 1e3b2cbb77)
Both files do very similar things, with "nm-sleep-monitor-upower.c"
being suboptimal, for example by creating the proxy synchronously.
Clean that up in the next steps. Just basic merging for now.
(cherry picked from commit c76eb3e8f7)
The lifetime of the proxy is not necesarily the same as the lifetime
of the NMSleepMonitor instance. Disconnect the signals during dispose().
(cherry picked from commit a09a5f7fc1)
The daemon does not run with a particular locale of a user. Localizing
makes no sense (at least, we don't do it usually and it would make
logging localized).
(cherry picked from commit 753f727af5)
As we don't take a reference on @self during the asynchronous
request, we must properly support cancelling in case of early
destruction.
I think, it's gdbus' responsibility not to leak any file descriptors
when cancelling a D-Bus request that returns file descriptors. Thus,
our usual pattern works here too.
(cherry picked from commit 2e3ff56cdc)
