Add addr_to_ip and get_ip_from_hostname helpers to PVE::Network
The first helper, addr_to_ip, is based on Wolfgangs version of this
[0]
I just moved it from PVE::Tools to PVE::Network, as it seems a more
fitting place.
It uses getnameinfo to extract information from the paddr parameter,
which is sockaddr struct
It gets used in the second helper and in a bug fix series from
Wolfgang [1]
The second helper, get_ip_from_hostname, resolves an hostname to an
IP and checks if it isn't one from the for loopback reserved 127/8
subnet. It will be used in get_remote_nodeip from PVE::CLuster and
for a bugfix in pvecm.
[0]: http://pve.proxmox.com/pipermail/pve-devel/2017-April/026099.html
[1]: http://pve.proxmox.com/pipermail/pve-devel/2017-April/026098.html
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
(cherry picked from commit 87aa00de73)
We shouldn't mix different tool sets on the one hand, and on
the other hand net-tools is an optional package in stretch
and there's no real need for us to depend on it.
When a container stops or hotplug changes are applied we
do a veth_delete() which does not cleanup the firewall
bridges or OVS ports. This is problematic at the next
startup. When creating a network device we usually want to
copy the MTU of the bridge we intend to put it on, however,
with OVS still having the old port lying around the
recreated device gets associated with the bridge before we
read its MTU, potentially reducing it to that of the newly
created device.
This cleanup also gets rid of stale fwbr/fwln devices from
stopped containers.
The get_local_ip_from_cidr method can be used to determine addresses
configured on interfaces from the callers node which are located
in the subnet. The subnet can be passed in CIDR notation.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Many interfaces used to get an ipv6 link-local address which
was usually unusable and therefore pointless.
In order to ensure consistency this is called in various
places:
* $bridge_add_interface() and $ovs_bridge_add_port() because
it's generally a good choice for bridge ports.
* tap_create() and veth_create() because the activate the
interfaces and we want to avoid the link local address to
exist temporarily between bringing the interface up and
adding it to a bridge.
* create_firewall_bridge_*() because firewall bridges aren't
meant to have addresses either.
* activate_bridge_vlan() - if vlan_filtering is disabled we
create vlan-bridges and neither them nor their physical
ports should have link local addresses.
It's possible for two simultaneous VM starts to try to
create vlan bridges on non-vlan-aware bridges
simultaneously, which causes one of them to fail with the
error "can't add bridge ...".
This avoids a circular dependency between PVE::INotify and
PVE::Network.
Also renamed to get_active_network_interfaces since the
package name now doesn't hint at this anymore.
Since we already allow this for container IP addresses it is
reasonable to assume the host might be using such a setup as
well. (You can use an additional route to reach the gateway
and then simply have no "LAN".) Some people seem to want
this...
tap_unplug() is only called in hotplugging functions which
perform a tap_plug() afterwards, and and in qemu-server's
bridge-down script.
The OVS port cleanup for non-firewall ports was done only in
tap_plug(), which means that in the case when qemu exits and
the tap device disappears, the OVS port for it stays.
With this patch the cleanup happens in both tap_unplug() and
tap_plug() to avoid problems with upgrades on systems
where there have already been ports leaked.
Any action we take in tap_plug() when using OVS will undo
our rate limiting, which means any hotplug change must
restore the previous rate setting.
Since this means tap_plug() would always be followed by a
tap_rate_limit() call anyway we just include the rate
parameter here and let the caller decide whether the full
tap_plug() is required or the simple tap_rate_limit()
suffices.
read_etc_network_interfaces used the content of
/proc/net/if_inet6 to decide whether an interface's state is
"active", which means an interface is only active when it
has an ipv6 address, thus using net.ipv6.conf.*.disable_ipv6
on an interface will cause it to show as inactive in the web
interface.
We now filter the interfaces found in /proc/dev/net by their
IFF_UP flag read via an SIOCGIFFLAGS ioctl().
We use Net::Ping twice in pve-storage (once for ISCSIPlugin
and once in GlusterfsPlugin, both with the 'tcp' variant.),
but Net::Ping doesn't support IPv6.
