Make link domain settings more conventional. If an IP Config only has no
search entries, use domains for search instead otherwise ignore domains.
Also on connections which are never the default, setup the
search/domains as routing-only meaning that only dns queries for those
domains will be done on this link. Prevents quering DNS information for
on-vpn host with other namservers and using the VPN DNS server for host
not on the VPN.
This is also fixes issues with a recent change in systemd-resolved where
links with a routing domain will only be used for those domains, which
meant that the previous strategry with a typical ip configuration (no
search only domains) resulted in no usable name resolution.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=772343
- use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere.
- reorder statements, to have GObject related functions (init, dispose,
constructed) at the bottom of each file and in a consistent order w.r.t.
each other.
- unify whitespaces in signal and properties declarations.
- use NM_GOBJECT_PROPERTIES_DEFINE() and _notify()
- drop unused signal slots in class structures
- drop unused header files for device factories
- mode in init_resolv_conf_mode() must be initialized in
case it is NULL.
- drop the NULL sentinal from resolved_paths and make it
static.
- resolved_proxy_created() must handle the fact that @self
might be already destroyed.
- call_done() must not access @self before ensuring that
the call was not cancelled.
What's more, send_update() can be called by resolved_proxy_created(),
thus it must ensure that it has an @update_cancellable. Let
send_update() create and cancel the @update_cancellable().
Also, send_update() -- which now manages @update_cancellable
instead of update() -- must actually cancel the previous
cancellable, otherwise the callback again might access
a disposed @self.
Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
Add initial DNS backend that pushes DNS information into
systemd-resolved. Backend is choosen by default if the systems
resolv.conv is setup to pointing to one of the standard resolved
locations.
This doesn't handle global dns configuration.
Signed-off-by: Sjoerd Simons <sjoerd@luon.net>
https://bugzilla.gnome.org/show_bug.cgi?id=762540
- don't include "nm-default.h" in header files. Every source file must
include as first header "nm-default.h", thus our headers get the
default include already implicitly.
- we don't support compiling NetworkManager itself with a C++ compiler. Remove
G_BEGIN_DECLS/G_END_DECLS from internal headers. We do however support
users of libnm to use C++, thus they stay in public headers.
(cherry picked from commit f19aff8909)
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
