Make the main/dns config key be a single value rather than a list of
plugins. Since there is currently only one valid value for it
("dnsmasq"), this is backward-compatible.
In the future, it will be possible to specify custom DNS-configuring
scripts here, which is a more flexible way of handling complicated
behavior than trying to create chainable internal plugins.
Remove the unused NMDnsPlugin::init method, some unused #includes, and
an out-of-date comment.
Use the correct macro for the default "/etc/resolv.conf" path.
Simplify NMDnsManager::dispose() a bit.
Make nm_dns_dnsmasq_new() return an NMDnsPlugin* rather than
NMDnsDnsmasq*.
Rather than passing specific bits of data to NMDHCPManager and
NMDnsManager, just let them call nm_config_get() and then get the data
themselves.
Also, remove the GError argument from nm_dhcp_manager_new(), since the
function never returned NULL. This in turn means there is no longer
any need for a distinction between nm_dhcp_manager_new() and
nm_dhcp_manager_get(), so remove the former.
gcc 4.8.0 has a new warning that triggers on
static void
compute_hash (NMDnsManager *self, guint8 buffer[HASH_LEN])
{
...
memset (buffer, 0, sizeof (buffer));
...
}
because "sizeof (buffer)" is *not* HASH_LEN, it's sizeof(guint8*). The
memset() was not necessary anyway since the g_checksum_get_digest()
after it will always end up filling in buffer, so just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=697041
"config-changed" signal is added to dns-manager and emited when resolv.conf is
changed. Policy listens for the signal and restarts reverse-lookup in order to
get correct results.
Various bits of code want the network interface which an IP config
came from, for example when distinguishing which interface to
send DNS requests to when the DNS servers are link-local. DNS
plugins may also want this data for various reasons.
So it makes sense to attach the interface name to the IP config
object when the DNS manager gets it, so that later DNS updates
that don't have any interface information (hostname changes, etc)
can still generate correct DNS information.
This also eliminates the "last_iface" hack, which was often
inaccurate.
It also now sends "NetworkManager" to SUSE netconfig as the
interface name, because the DNS information being sent is already
merged/prioritized and not specific to a network interface, so
it's time to stop lying about where it came from.
Use autoconf/automake variables for NetworkManager paths. Use
NetworkManager subdirectory where appropriate.
Files in /var/run (or /run on some distros) are moved into a separate
directory as is usual with other daemons. It makes the filesystem
more readable and file prefixing unnecessary.
/var/run/NetworkManager.pid -> /var/run/NetworkManager/NetworkManager.pid
/var/run/nm-dns-dnsmasq.pid -> /var/run/NetworkManager/dnsmasq.pid
/var/run/nm-dns-dnsmasq.conf -> /var/run/NetworkManager/dnsmasq.conf
The /var/run/NetworkManager directory is created at runtime, if it doesn't
exist.
Note: Path-based security policies like SELinux and AppArmor may need to
be adapted.
NetworkManager can use resolvconf and netconfig as alternatives
to direct modifications to /etc/resolv.conf. You can now choose
whether to build with netconfig or not.
The default is --with-netconfig=yes on SUSE and --with-netconfig=no
on other distributions. Default --with-resolvconf=no still applies
on any distribution.
This function was basically the same for all distributions and
was used only in one place. It tried to restart nscd or ask it
to reload configuration. This is not necessary as nscd uses
inotify to watch /etc/resolv.conf.
We don't use the default dnsmasq directory because packages often drop files
there that don't take account of NM's specific use-case and end up conflicting
with the specific local caching nameserver functionality that NM uses dnsmasq
for. NM's private dnsmasq is orthogonal to whatever global dnsmasq
daemon may be running, and with that daemons configuration.
(dcbw: change directory to private one)
The previous code did a cheap hash based on pointers, under the
assumption that the IP configs don't get recreated. But with IPv6
the IP6 config that's eventually applied is a composite of the
DHCPv6 and the RA information, and is thus recreated each time
something in the DHCPv6 or RA changes. Switch to actually hashing
the IP config data and its order to prevent this problem.
Next, add functions to signal that a batch of updates will be
started, and to only commit those updates when all of them
have landed, and if they have actually changed anything. We'll
use these functions later to reduce the number of changes
that get made to /etc/resolv.conf.
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
Commit 217c5bf6ac fixed processing of unix
signals: signals are blocked in all threads and a dedicated thread handles the
signals using sigwait().
However, the commit forgot that child processes inherit signal mask as well.
That is why we have to unblock signals for child processes we spawn from NM, so
that they can receive signals.
This will allow DNSSEC data to be visible in browsers, which would otherwise
not be the case by default because of dnsmasq acting as a middle-man for
resolution.
Otherwise, we have a regression from the libc resolver behavior.
Drop --strict-order; dnsmasq is intelligent enough to ask nameservers in
an order that makes the best of possibly slow nameservers (or broken ones),
and interrogating them in strict order breaks this.
Add --no-hosts: by default dnsmasq will read /etc/hosts as a list of things
to resolve statically; this is something we want to avoid as nsswitch.conf
already lists files as the first data store to look at; where the entries
in /etc/hosts will already have been returned if that's what the user wants
to see. If the /etc/hosts file then changes, dnsmasq would have to be restarted
before the user would get the new value resolved externally. Avoid this, let
/etc/hosts override DNS entries normally through the resolver and show
changes as soon as the file is updated.
All of the information in the configuration files for local caching
dnsmasq or BIND servers are accessible already over the D-Bus
interface, so there's no sensitive information here.
inet_ntop() either returns 'address%interface' or just 'address'. In the first
case, we replace '%' with '@' since dnsmasq supports '%' only since version
2.58. In the second case, we append '@interface' to make it work.
(small fixes by dcbw)
If any ethernet devices were left up (because we can assume control
over them seamlessly when NM starts up again) make sure we write
out a usable resolv.conf for the device on shutdown, otherwise the
users networking is broken with an empty resolv.conf. This only
happened when DNS plugins were active, in which case the user
would be left with a localhost-pointing resolv.conf but no
local caching nameserver running since NM shut it down when NM
terminated.
When split DNS is used for a local caching nameserver, make sure
that reverse DNS queries for hosts within the VPN tunnel are directed
to the VPN's nameservers, not to the public upstream nameservers.
config.h defines _GNU_SOURCE, which in turn defines the bits necessary
for kill, isblank, and isascii. So wherever we use those, we need
to make sure config.h is included.
It's still got a bunch of issues that need debugging, like when VPN
nameservers exist but no domain and thus not doing split DNS, sometimes
hosts outside the VPN don't resolve correctly, which was previously
masked by having the non-VPN nameservers in /etc/resolv.conf where
glibc would erroneously use them instead of asking BIND. To be fixed
in a subsequent patch.
The dnsmasq plugin seems to work great though.
If all nameservers are listed in resolv.conf, glibc apparently
tries them all (even if 'options rotate' isn't specified??). Leading
to queries for internet hosts being directed to VPN-specific DNS
servers in split-DNS situations. I've verified this with wireshark;
I see queries going out over the tunnel to VPN nameservers for
non-internal addresses, while BIND itself never logs anything about
queries to VPN nameservers for that same address. Thus the only
thing left is to blame glibc...
Despite most guides saying that without restricting to port 53 queries
won't get through a firewall, I cannot make it work with this option.
DNS queries through a WRT54G just time out even when the WRT54G isn't
caching anything itself (ie, explicit upstream nameservers are the
forwarders in the bind config).
This was supposed to hook up to the bits Adam Langley did last year
for his local-dns-cache DBus service, but I misunderstood the
architecture. It was a separate service, not Chromium itself. But
it's unclear what happened to his local-dns-cache since the project
doesn't seem to have any commits in a year and I'm unsure if it's
actually being used. So remove this stuff for now.
Use a pseudo-hash to quickly check whether the DNS config has really
changed or not. This is certainly better than the 500 line patch I
did then scrapped in favor of this approach... yay. This helps ensure
that we don't kill then respawn caching DNS servers more often than
we have to.
