Similarly to what systemd-resolved does, introduce the concept of
"routing" domain, which is a domain in the search list that is used
only to decide the interface over which a query must be forwarded, but
is not used to complete unqualified host names. Routing domains are
those starting with a tilde ('~') before the actual domain name.
Domains without the initial tilde are used both for completing
unqualified names and for the routing decision.
The "domain" key of the D-Bus configuration dictionary specifies the
domains a configuration applies to. In DNS code we consider domains
and searches as equivalent, so they should be exported via D-Bus using
the same logic used to populate resolv.conf and for plugins.
Otherwise, having a meson build directory along autotools,
lets `make check` fail with
The following files contain translations and are currently not in use. Please
consider adding these to the POTFILES.in file, located in the po/ directory.
build/data/org.freedesktop.NetworkManager.policy.in
If some of these files are left out on purpose then please add them to
POTFILES.skip instead of POTFILES.in. A file 'missing' containing this list
of left out files has been written in the current directory.
Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager
if [ -r missing -o -r notexist ]; then \
exit 1; \
fi
Yes, meson does not require that the build directory is named "build"
and this fix only works for the default case.
The `settings-docs.c` file is generated by processing the
`nm-property-docs.xml` file. Although this works in autotools,
the `.c` extension makes meson not to handle it properly.
Given the fact that it only contains a number of defines it
makes sense to change its extension to `.h` an use it as a header.
This also makes meson to handle it properly and build it before
its used.
https://mail.gnome.org/archives/networkmanager-list/2018-January/msg00057.html
The following symbols are missing from the libnm-glib library:
* libnm_glib_get_network_state
* libnm_glib_init
* libnm_glib_register_callback
* libnm_glib_shutdown
* libnm_glib_unregister_callback
This has been changed by linking `libdeprecated_nm_glib` as a whole.
https://mail.gnome.org/archives/networkmanager-list/2018-January/msg00056.html
When NM knows of the ifindex/name of the new PPP interface (through
the SetIfindex() call), it renames it. This can race with the pppd
daemon, which issues ioctl() using the interface name cached in the
global 'ifname' variable:
...
NetworkManager[27213]: <debug> [1515427406.0036] ppp-manager: set-ifindex 71
pppd[27801]: sent [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
NetworkManager[27213]: <debug> [1515427406.0036] platform: link: setting 'ppp5' (71) name dsl-ppp
pppd[27801]: sent [IPCP ConfAck id=0x2 <addr 3.1.1.1>]
pppd[27801]: ioctl(SIOCSIFADDR): No such device (line 2473)
pppd[27801]: Interface configuration failed
pppd[27801]: Couldn't get PPP statistics: No such device
...
Fortunately the variable is exposed to plugins and so we can turn the
SetIfindex() D-Bus call into a synchronous one and then update the
value of the 'ifname' global variable with the new interface name
assigned by NM.
If IPV6CP terminates before IPCP, pppd enters the RUNNING phase and we
start IP configuration without having an IP interface set, which
triggers assertions.
Instead, add a SetIfindex() D-Bus method that gets called by the
plugin when pppd becomes RUNNING. The method sets the IP ifindex of
the device and starts IP configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1515829
We also unconditionally use them with autotools.
Also, the detection for have_version_script does
not seem correct to me. At least, it didn't work
with clang.
I think it's because meson doesn't run the tests in their
own D-Bus session, hence the use the system service.
automake solves this running all tests via ./tools/run-nm-test.sh,
which knows how to prepare a suitable environment for the tests.
The strings holding the names used for libraries have also been
moved to different variables. This way they would be less error
as these variables can be reused easily and any typing error
would be quickly detected.
Some targets are missing dependencies on some generated sources in
the meson port. These makes the build to fail due to missing source
files on a highly parallelized build.
These dependencies have been resolved by taking advantage of meson's
internal dependencies which can be used to pass source files,
include directories, libraries and compiler flags.
One of such internal dependencies called `core_dep` was already in
use. However, in order to avoid any confusion with another new
internal dependency called `nm_core_dep`, which is used to include
directories and source files from the `libnm-core` directory, the
`core_dep` dependency has been renamed to `nm_dep`.
These changes have allowed minimizing the build details which are
inherited by using those dependencies. The parallelized build has
also been improved.
In some cases we might want to load device plugins from multiple
directories. A special case that I have in mind is to load plugins from
build directory subdirectories in order to run NetworkManager from the
build directory.
[thaller@redhat.com: modify original patch]
Many of the configured directories default to being defined using existing
directory configuration. As a result you usually don't see the actual
directories that will be used. With the added directories you can at least
assemble the information and thus see which directories will be used.
Although it is possible to generate distributable files on meson
since version 0.41 by using the `ninja dist` command, autotools does
different things that end up creating a different distributable
file.
meson build files have been added to autotools build files as
distributable files, so the whole meson port would also be
distributed.
https://mail.gnome.org/archives/networkmanager-list/2018-January/msg00047.html
The connection.mdns setting is a per-connection setting,
so one might expect that one activated device can only have
one MDNS setting at a time.
However, with certain VPN plugins (those that don't have their
own IP interface, like libreswan), the VPN configuration is merged
into the configuration of the device. So, in this case, there
might be multiple settings for one device that must be merged.
We already have a mechanism for that. It's NMIP4Config. Let NMIP4Config
track this piece of information. Although, stricitly speaking this
is not tied to IPv4, the alternative would be to introduce a new
object to track such data, which would be a tremendous effort
and more complicated then this.
Luckily, NMDnsManager and NMDnsPlugin are already equipped to
handle multiple NMIPConfig instances per device (IPv4 vs. IPv6,
and Device vs. VPN).
Also make "connection.mdns" configurable via global defaults in
NetworkManager.conf.
Don't track the per-device configuration in NMDnsManager by
the ifname, but by the ifindex. We should consistently treat
the ifindex as the ID of a link, like kernel does.
At the few places where we actually need the ifname, resolve
it by looking into the platform cache. That is not necessarily
the same as the ifname that is currently tracked by NMDevice,
because netdev interfaces can be renamed, and NMDevice updates
it's link properties delayed. However, the platform cache has
the most recent notion of the correct interface name for an
ifindex, so if we ever hit a race here, we do it now more
correctly.
This also temporarily drops support for mdns. Will be re-added next,
but differently.
