Instead of having 3 properties @gateway, @never_default and @has_gateway
on NMIP4Config/NMIP6Config that determine the default-route, track the
default-route as a regular route.
The gateway setting is the configuration knob for the default-route.
Since an NMIP4Config/NMIP6Config instance only has one gateway property,
it cannot track more then one default-routes (see related bug rh#1445417).
Especially with policy routing, it might be interesting to configure a
default-route in multiple tables.
Also, later it might be interesting to allow adding default-routes as
regular static routes in a connection, so that the user can configure additional
route parameters for the default-route or add default-routes in multiple tables.
With this patch, default-routes now have a rt_source property according to their
origin.
Also, the previous commits of this branch broke handling of the
default-route :) . That should be working now again.
Default-routes are for the most part like regular routes. Add support to
track them like regular routes in NMIP4Config/NMIP6Config.
One thing is, sometimes we need to figure out whether an ip-config
instance has a default-route. For that, keep track of the best
default-route (there might be multiple) and expose it. That is
the most complicated part of this patch, because there are so many
places where the list of routes gets modified (replace, intersect,
subtract, merge, add), and they all need to take care of updating
the best default-route.
In a next patch, NMDefaultRouteManager will be dropped and default-routes
will be tracked by NMIP4Config/NMIP6Config.
Reasons:
- it adds an O(1) lookup index for accessing NMIPxConfig's addresses.
Hence, operations like merge/intersect have now runtime O(n) instead
of O(n^2).
Arguably, we expect low numbers of addresses in general. For low
numbers, the O(n^2) doesn't matter and quite likely in those cases
the previous implementation was just fine -- maybe even faster.
But the simple case works fine either way. It's important to scale
well in the exceptional case.
- the tracked objects can be shared between the various NMPI4Config,
NMIP6Config instances with NMPlatform and everybody else.
- the NMPObject can be treated generically, meaning it enables code to
handle both IPv4 and IPv6, or addresses and routes. See for example
_nm_ip_config_add_obj().
- I want core to evolve to somewhere where we don't keep copies of
NMPlatformIP4Address, et al. instances. Instead they shall all be
shared. I hope this will reduce memory consumption (although tracking a
reference consumes some memory too). Also, it shortcuts nmp_object_equal()
when comparing the same object. Calling nmp_object_equal() on the
identical objects would be a common case after the hash function
pre-evaluates equality.
The DNS manager drops from the search list domains that are public
suffixes to prevent a possible domain hijack when using two-labels
hostnames [1].
This is a problem now that every single-label domain can be a TLD
since this means that such domains can't be used in the search list.
While it's useful to apply such restriction to the domain
automatically derived from the system hostname, it seems wrong to drop
domains specified by users in the configuration or provided by DHCP.
This commit keeps the public-suffix check only for the
hostname-derived domain
[1] https://bugzilla.redhat.com/show_bug.cgi?id=812394https://bugzilla.redhat.com/show_bug.cgi?id=1404350
Eventually, every NMPlatformIP4Route, NMPlatformIP6Route,
NMPlatformIP4Address and NMPlatformIP6Address should be shared
an deduplicated via the global NMDedupMultiIndex instance.
As first proof of concept, refactor NMIP4Config to track
IPv4 routes via the shared multi_idx. There is later potential
for improvement, when we pass (deduplicated) NMPObject instances
around instead of plain NMPlatformIP4Route, which needs still
a lot of comparing and cloning.
No need to clone the list anymore. Unfortunately, GPtrArray is not NULL
terminated (without extra effort), so we have to pass on the GPtrArray
instance for the length.
A negative ipv4.dns-priority and ipv6.dns-priority has the meaning to configure
the DNS information of the connection exclusively. With systemd-resolved, that means
we must explicitly unset the configuration from other interfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=783569
The code was correct previously, but it was confusing to me,
because
- once @skip gets set to TRUE, it stays TRUE for the rest
of the loop.
- in each additional skipped iteration, it would still set
plugin_confs[i] to NULL. Which is not wrong, but confusing.
- it would set "prev_prio = prio;" in each iteration.
After @skip is set to TRUE, that doesn't matter anymore,
but is confusing. Before @skip is set to TRUE it also
doesn't really matter to set it more then once, because
we only care about the very first priority.
- @skip sounded to me like the current iteration would
be skipped. But really all remaining will be skipped too.
We autodetect systemd-resolved based on whether /etc/resolv.conf points
to one of the well known files of systemd-resolved.
Extend the check by also
- follow symlinks and compare the absolute link target
- open the file and compare the inodes for hard-linking
Note that when NetworkManager starts, systemd-resolved might not
have started yet. So, while comparing the inode is the best check,
we also compare symlinks (g_file_read_link() and realpath()).
Based-on-patch-by: Sam Morris <sam@robots.org.uk>
https://github.com/NetworkManager/NetworkManager/pull/16https://bugzilla.gnome.org/show_bug.cgi?id=779269
When rc-manager=file other services may overwrite resolv.conf at any
time. We don't support merging configurations in resolv.conf but we can
be more tolerant avoiding updating resolv.conf when not strictly needed.
In this case, if the last write of resolv.conf had no nameservers (nor
options), reset the "dns_touched" flag in order to avoid resetting
resolv.conf when quitting (so, potentially overwriting some other
service configuration there).
https://bugzilla.redhat.com/show_bug.cgi?id=1426748
When hostname changes, resolv.conf should be rewritten to update the
"search" option with the new domain parameters. If no device is
active nor going to activate, skip triggering resolv.conf update.
The DNS configuration for VPN connections is associated to the VPN
device (tun, ppp, etc.) and that device can be unmanaged by NM: don't
ignore such configuration. We do the same for other DNS plugins.
https://bugzilla.gnome.org/show_bug.cgi?id=779087
The purpose of "rc-manager=symlink" is so that the administrator can point
the "/etc/resolv.conf" as a symlink to a certain file, and thus indicating
that a certain component is responsible to manage resolv.conf, while others
should stay away from it.
For example, systemd-resolved never touches "/etc/resolv.conf", but
expects the admin to setup the symlink appropriately. It also recognizes
whether the symlink points to it's own resolv.conf in /run or to another
component.
Previously, "rc-manager=symlink" would always replace a regular file
with a symlink to "/var/run/NetworkManager/resolv.conf". Only if
"/etc/resolv.conf" is already a symlink somewhere else, NM would not
touch it. This with the exception that if "/etc/resolv.conf" points to
"/var/run/NetworkManager/resolv.conf", it would replace the symlink
with the same link to raise inotify events.
Change behavior so if "/etc/resolv.conf" is already a regular file, keep
it as file.
This means, if you have multiple components that don't care, everybody
can write the "/etc/resolv.conf" (as file) and there is no clear
expressed responsibility.
It was wrong that NetworkManager would convert the file to a symlink,
this should be reserved to the admin. Instead, NetworkManager should
accept that the intent is unspecified and preserve the regular file.
It's up to the admin to replace the symlink to somewhere else (to keep
NM off), or to point it to "/var/run/NetworkManager/resolv.conf", to show
the explicit intent.
The wrong behavior causes dangling symlinks when somebody disables
NetworkManager for good.
https://bugzilla.redhat.com/show_bug.cgi?id=1367551
The DNS manager and other singletons have the problem that
they are not properly destroyed on exit, that is, we leak
most of the instances. That should be eventually fixed and
all resources/memory should be released.
Anyway, fix the shutdown procedure by adding an explict command
nm_dns_manager_shutdown(). We should not rely on cleanup actions
to take place when the last reference is dropped, because then
we get complex interactions where we must ensure that everybody
drops the references at the right pointer.
Since the previous shutdown action was effectively never performed,
it is not quite clear what we actually want to do on shutdown.
For now, move the code to nm_dns_manager_stop(). We will see if
that is the desired behavior.
The -Wimplicit-fallthrough=3 warning is quite flexible of accepting
a fall-through warning.
Some comments were missing or not detected correctly.
Thereby, also change all other comments to follow the exact
same pattern.
nm_spawn_process() only sets error if the g_spawn_sync() itself fails,
not when the program ran returns a non-zero code.
<debug> [148 059915.1567] dns-mgr: update-dns: updating resolv.conf
<info> [148 059915.1568] dns-mgr: Removing DNS information from /usr/bin/resolvconf
No resolv.conf for interface NetworkManager
Thread 1 "NetworkManager" received signal SIGSEGV, Segmentation fault.
0x0000555555 7c325 in nm_dns_manager_end_updates
1532 _LOGW ("could not commit DNS changes: %s", error->message);
(gdb) bt full
#0 0x0000555555 7c325 in nm_dns_manager_end_updates
error = 0x0
update_dns() is rather complicated. The part where we collect
resolv-conf data can be moved out. That is nice, because
_collect_resolv_conf_data() has no side-effects (except logging)
and it's only purpose is to return the out-arguments.
It is useful to let clients retrieve the current DNS configuration,
which can be displayed to users or used (together with dns=none) to
implement custom DNS configuration logic through external tools.
Extend the D-Bus API and introduce a new NMDnsManager interface that
contains all the information related to DNS configuration.
At the moment the new DnsManager object only contains basic properties
describing the current DNS mode and resolv.conf manager.
Previously we printed the DNS configuration for all devices including
unmanaged and unconfigured ones:
dns-mgr: config: 100 best v4 ens3 : 192.168.10.1
dns-mgr: config: 100 default v6 ens3 : fd01🔡:3681:c4ff:fec0:fe94
dns-mgr: config: 100 default v4 lo :
dns-mgr: config: 100 default v6 lo :
dns-mgr: config: 100 default v4 ens9 :
dns-mgr: config: 100 default v6 ens9 :
Instead, print only devices that have name servers set.
A new DNS may have different data for us. So tell dnsmasq to
automatically clear the cache when servers change.
Signed-off-by: Christian Hesse <mail@eworm.de>
Keep the include paths clean and separate. We use directories to group source
files together. That makes sense (I guess), but then we should use this
grouping also when including files. Thus require to #include files with their
path relative to "src/".
Also, we build various artifacts from the "src/" tree. Instead of having
individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be
unified. Previously, the CFLAGS for each artifact differ and are inconsistent
in which paths they add to the search path. Fix the inconsistency by just
don't add the paths at all.
