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)
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)
