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
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.
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.
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
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.
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.
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.
This also fixes cancelling the timeout in dispose().
Just to be explicit, also cancel it in dispose(),
although dispose() alreay calls _clear_plugin().
_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.
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
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
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
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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.
Since long, dnsmasq supports scoping the IPv6 address
with '@<interface-name>'. Since 2.58, it also supports
'%' as delimiter, which is the standard way to specify
the zone-id (rfc6874).
Since 2.73, specifying the scope with '@' as "server"
address is no longer working properly, thus breaking
NetworkManager with dnsmasq >= 2.73.
To work around that, use '%' delimiter. That breaks pre-2.58
users that have a DNS server on a link local address, but that
seems acceptable as that version was released in January 2012.
https://bugzilla.gnome.org/show_bug.cgi?id=764839
