When a reverse DNS entry must be added to dnsmasq, instead of
considering IP addresses as classful use the prefix to compute one or
more "in-addr.arpa" according to CIDR rules.
https://bugzilla.gnome.org/show_bug.cgi?id=767174
(cherry picked from commit 4d1e7dc23c)
With
[main]
#dns=
we would see in the log:
dns-mgr: init: dns=(null), rc-manager=symlink
Instead, it should be
dns-mgr: init: dns=default, rc-manager=symlink
Also, we should avoid logging NULL values with "%s", although
glib's printf is fine with that.
(cherry picked from commit bcb88d540e)
Before, we would first check whether the file is immuable before
parsing main.rc-manager setting. That means, if you configured
[main]
dns=default
rc-manager=unmanged
we would still first try to detect whether the file is immutable.
The result of course is only minor, e.g. showing up in logging
as rc-manager=immutable instead of rc-manager=unmanged.
Also, an immutable resolv.conf would suppress a warning about
a bogus rc-manager setting.
Also, when selecting rc-manager=symlink and resolv.conf is a symlink
to an immutable file, we don't actually care about that. The reason is,
that if the link-target is not /var/run/NetworkManager/resolv.conf,
we anyway wouldn't modify the file.
The effect of this change is pretty minor, now in logging you would see:
dns-mgr: init: dns=default, rc-manager=symlink
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 /some/where/else
instead of
dns-mgr: init: dns=default, rc-manager=immutable
dns-mgr: update-resolv-conf: write internal file /var/run/NetworkManager/resolv.conf succeeded
Which feels slightly more right.
Note that symlinks cannot have file attributes.
(cherry picked from commit 4711867915)
Until before 1.2.0, NetworkManager would always write resolv.conf as file, but
if /etc/resolv.conf was a symlink, it would follow the link instead of
replacing it with a file ([1], [2]).
With 1.2.0, we initially dropped that behavior and added a new 'rc-manager=none'
which writes resolv.conf to /var/run/NetworkManager and symlinks resolv.conf [3].
In case resolv.conf being already a symlink to another target, it would
not be replaced [4].
Later, we added 'rc-manager=file', which always writes /etc/resolv.conf as
file [5].
With 1.4.0, we will rename 'rc-manager=none' to 'rc-manager=symlink' [6].
This commit now fixes 'rc-manager=file' to restores the pre-1.2 behavior
and follow symlinks.
[1] 5761e328b8
[2] https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/324233
[3] 4805be2ed2
[4] 583568e12f
[5] 288799713d
[6] cd6a469668https://github.com/NetworkManager/NetworkManager/pull/7
(cherry picked from commit 718fd22436)
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)
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)
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)
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)
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)
Pass an empty configuration file otherwise dnsmasq loads
"/etc/dnsmasq.conf".
We already allow for a config.d/ directory "/etc/NetworkManager/dnsmasq.d"
to allow the user to overwrite configuration. We don't want to consider
the global config file.
Fixes: 497a8aa5c6
(cherry picked from commit 3d3f71acec)
The 4 private fields pid, watch_id, progname and pidfile strictly
belong together. When spawning a child, we set all 4 of them and
when killing the child all get cleared. Cleanup to code to always
set those 4 fields together.
(cherry picked from commit 4d5ca7f9de)
