GitLab

When we want to change the zone an interface belongs to
we can't use firewalld's addInterface() because this one
doesn't allow to add interface to zone when it already
has been part of some other/same zone.
We need to use changeZone() method instead - hopefuly
this is the final name of this method.

Because firewalld has no idea what interface is part of which zone
we need to inform it after it (re)starts what interface belongs to which
zone.

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.

Otherwise if another connection was subsequently activated on a
bond interface, and didn't specify all options, ones set for the
previous connection could stay set for the new connection.

Since the options are a hash table now there wasn't any way to
determine what options were allowed and what their default values
are.  Add some functions to do that.

We already have the master device kept in the active connection, so
we can just use that instead of having the Policy determine and set
it manually.  This also should allow slaves to auto-activate their
master connections if the master is able to activate.

Let the master control how the slave gets enslaved and released
since that's dependent on the virtual interface type of the master.

Virtual devices that we might create when their slave is started
(like bonds) have a virtual carrier that often isn't set on when
until the device is brought up.  The device is brought up during
creation, but the initial carrier check happens before the device
is up, so the initial carrier state from the constructor isn't
quite accurate in some cases.

Since we want to use virtual interfaces that we create right after
we create them, we want them to be available too, and that usually
requires the carrier to be on.  So recheck the carrier right after
bringing the interface up, so that the carrier state is accurate
immediately after the device is created.

Before jumping to activation stage 1, make sure dependencies are activated.

Track a master active connection and emit wait/ready/fail when
it changes state.  This signal is intended for devices to
delay their activation until a master device is ready.

If the connection requires a master connection or master device,
find that connection, and activate it if it's not already
activated.

This function used to be used only from activation paths, so it
was fine to assert there because we always expected that there
would be an activation request.  These days we'd like to use it
in more places, so just return NULL if there's no connection.

Just split the VPN-specific stuff out to its own function so that
nm_manager_activate_connection() isn't so large.

They are the basic class that tracks active connections, and we're
going to use them for connection dependencies.  So use the fact that
both NMVPNConnection and NMActRequest have the same base class
instead of using object paths.

Many different interface types can support VLANs, including
Infiniband, WiFi, etc.  So we have to create a new device class
for them instead of keeping the support in NMDeviceEthernet.

We'll want to eventually match (for VLAN) a given hardware address
that's not the device's hardware address.  Only the device itself
knows which NMSetting should contain it's hardware address (ie
the 'wired' setting for NMDeviceEthernet, 'infiniband' for
NMDeviceInfiniband, etc) and VLANs take their hardware address
from the parent interface.  So eventually we'll have VLAN
interfaces use these new arguments to ask their parent interface
to match the VLAN hardware address in a connection, since the
VLAN doesn't know (or need to know) what kind of interface it
really is underneath.

It's useful for more than just NMDeviceWired and subclasses.

It's the parent, not the master, that we care about here.

The 'parent' property of NMSettingVlan is now what describes the
interface from which the VLAN gets created, not master.

Add some testcases checking for DEVICE/PHYSDEV/VLAN_ID variations,
and read/write the new VLAN_ID tag, which we can use in
combination with the 'parent' property to determine the interface
name if no interface name/DEVICE is given.

For bonding-master:
  TYPE=bond
  BONDING_MASTER=yes
  DEVICE=<NAME>
  BONDING_OPTS="..."

For bonding-slaves:
  MASTER=<NAME>

v2: Resolved test failures after feedback from Jirka.
Signed-off-by: Thomas Graf <tgraf@redhat.com>

Necessary when building from git srcdir != builddir.

It's still enabled by default if you don't pass --with-wext=no.
But now it's possible to build without WEXT entirely.

NM emits coalesced PropertiesChanged signals, which might be
delayed slightly and thus sent after the StateChanged signal
for devices.  Clients of libnm-glib listening for the
'state-changed' signal and then querying the state manually
using nm_device_get_state() would still see the old state until
it was updated via the delayed PropertiesChanged signal
processing.  Since when the StateChanged signal comes in the
device is already in the new state, just update the state and
leave the GObject property notify signal to the
PropertiesChanged signal handling code so that clients have
an accurate device state.