Instead of having basically the same code in a bunch of different
place to find helper programs, just have one place do it. Yes, this
does mean that the same sequence of paths is searched for all helpers
(so for example, dnsmasq will no longer be found first in /usr/local)
but I think consistency is the better option here.
https://bugzilla.gnome.org/show_bug.cgi?id=734131
Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
Fix this by changing the include guards in the non-API-stable parts of
the tree:
- libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H
- libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__
- src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__
And likewise for all other headers.
The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.
Out-of-tree build fails with:
../../src/dns-manager/nm-dns-manager.c:38:33: fatal error: libnm-util/nm-utils.h: No such file or directory
Fixes regression introduced by commit 7580cfef20.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Use nm_utils_inet4_ntop() and nm_utils_inet6_ntop() instead.
And get rid of the unneeded error-checking.
gcc warns:
make[4]: Entering directory `/data/src/NetworkManager/src'
CC nm-dns-manager.lo
dns-manager/nm-dns-manager.c: In function 'merge_one_ip4_config':
dns-manager/nm-dns-manager.c:137:37: warning: ordered comparison of pointer with integer zero [-Wextra]
if (inet_ntop (AF_INET, &addr, buf, INET_ADDRSTRLEN) > 0)
^
dns-manager/nm-dns-manager.c:168:37: warning: ordered comparison of pointer with integer zero [-Wextra]
if (inet_ntop (AF_INET, &addr, buf, INET_ADDRSTRLEN) > 0)
^
dns-manager/nm-dns-manager.c: In function 'merge_one_ip6_config':
dns-manager/nm-dns-manager.c:197:64: warning: ordered comparison of pointer with integer zero [-Wextra]
if (inet_ntop (AF_INET, &(addr->s6_addr32[3]), buf, INET_ADDRSTRLEN) > 0)
^
dns-manager/nm-dns-manager.c:200:38: warning: ordered comparison of pointer with integer zero [-Wextra]
if (inet_ntop (AF_INET6, addr, buf, INET6_ADDRSTRLEN) > 0) {
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
When building with '--disable-concheck' with libsoup installed,
configure would set HAVE_LIBSOUP. But without connection
checking, we didn't link against libsoup, resulting in a
linker error.
Add a new configure option '--with-libsoup' / '--without-libsoup'
to control whether linking against libsoup.
The combination '--without-libsoup --enable-concheck' does not
make sense.
https://bugzilla.gnome.org/show_bug.cgi?id=734062
Signed-off-by: Thomas Haller <thaller@redhat.com>
Clean up some of the cross-includes between headers (which made it so
that, eg, if you included NetworkManagerUtils.h in a test program, you
would need to build the test with -I$(top_srcdir)/src/platform, and if
you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all
GObject struct definitions for src/ and src/settings/ into nm-types.h
(which already existed to solve the NMDevice/NMActRequest circular
references).
Update various .c files to explicitly include the headers they used to
get implicitly, and remove some now-unnecessary -I options from
Makefiles.
The script is called synchronously from NetworkManager so it can handle
asynchronicity itself. The long-term plan is to incorporate the script
partially into the new plugin and partially into a dnssec-trigger
library which will be used instead of dnssec-trigger daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=699810
Acked-By: Thomas Haller <thaller@redhat.com>
Acked-By: Dan Williams <dcbw@redhat.com>
dfe194ee made it so that we don't use "public suffixes" as resolv.conf
search domains (eg, we don't add "search com" if the hostname is
"example.com"). However, if this results in us writing a resolv.conf
with no "search" line at all, then the resolver will fall back to
using the parent domain of the hostname as a search domain anyway,
thwarting us.
To fix that, use the domain itself as a search domain in this case,
since that's likely to be the expected behavior anyway. (And even if
it's not, there doesn't appear to be any way to block the resolver
from using the hostname's parent domain as a search domain unless we
specify at least one search domain ourselves.)
https://bugzilla.gnome.org/show_bug.cgi?id=729137
resolv.conf(5) says:
The domain and search keywords are mutually exclusive. If more than
one instance of these keywords is present, the last instance wins.
NM always writes out a "search" line if it writes a "domain" line, so
the "domain" line is always a no-op. So drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=729137
VPN services that use the kernel's IPSec stack (like OpenSwan/LibreSWAN)
obviously don't have a tunnel interface, so don't require one. If
those services provide Link-Local IPv6 DNS servers they simply won't
work, but perhaps we can filter those out later or warn about them.
If the hostname is "foo.example.com" then we want to add
"search example.com" to resolv.conf, but if it's just "example.com",
we don't want to add "search com" (rh #812394).
So if NetworkManager is being built with recent libsoup, use
soup_tld_domain_is_public_suffix() to double-check the domain before
adding it. (If it is not being built with libsoup, or is being built
with too old a version, we just skip that test, keeping the old
behavior.)
NMPolicy only updates the NMDnsManager's hostname when it changes,
which previously did not include at startup. Meaning if your hostname
never changed, NMDnsManager would never learn it (and so would never
add an appropriate "search" line to resolv.conf). Fix that.
If /etc/resolv.conf has the immutable flag set, then behave as though
"dns=none" was specified (rather than repeatedly trying and failing to
update it).
Add a property indicating whether NMDnsManager is ignoring
resolv.conf, managing it by explicitly putting nameservers into it, or
managing it by proxying to another service (eg, dnsmasq) with
"nameserver 127.0.0.1".
ip6_addr_to_string did assume, that inet_ntop might write a scope id to
the result. But it does not (and cannot, because struct in6_addr does
not have any interface identifer).
Simplify and rework the function.
Also fix a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=711684
Signed-off-by: Thomas Haller <thaller@redhat.com>
These are (most likely) only warnings and not severe bugs.
Some of these changes are mostly made to get a clean run of
Coverity without any warnings.
Error found by running Coverity scan
https://bugzilla.redhat.com/show_bug.cgi?id=1025894
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Although having different parts of NM in different subdirectories
keeps the source tree neat, it has made the build messy, particularly
because of cross-dependencies between the subdirs.
Reorganize to build all of the pieces of the NetworkManager binary
from src/Makefile, and only use recursive make for test programs,
helper binaries, and plugins.
As part of this, get rid of all the per-directory convenience
libraries, and switch to building a single top-level
libNetworkManager.la, containing everything except main.c, which all
of the test programs can then link against.
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.
