Handle the iptables, dnsmasq and dnssec-trigger paths in the same way
through common code.
The path set by user must be accepted as is, even if does not exist,
because this is a requirement for cross-compilation. When user does
not specify a path, search a predefined set of paths and fall back to
an hardcoded one.
(cherry picked from commit 220dea0948)
If the user explicitly passes --with-netconfig=$PATH or --with-resolvconf=$PATH,
the path is accepted as is. We only do autodetection, if the binary was not found.
In that case, if the binary cannot be found in the common paths fail compilation.
Some path variable like $(bindir), $(datadir), etc. are special for
autotools and must be handled separately through config-extra.h.
But dhcp path variables are just normal variables defined through
the configure script and should go into config.h.
Handle the iptables, dnsmasq and dnssec-trigger paths in the same way
through common code.
The path set by user must be accepted as is, even if does not exist,
because this is a requirement for cross-compilation. When user does
not specify a path, search a predefined set of paths and fall back to
an hardcoded one.
Set the execution bit on /usr/sbin/{ifup,ifdown} ghost files to match
the mode of same files installed by initscripts.
Otherwise, they will appear as changed according to rpm verify:
.M....... g /usr/sbin/ifdown
.M....... g /usr/sbin/ifup
when the alternatives mechanism is not in place.
# ll /usr/sbin/if{up,down}
-rwxr-xr-x. 1 root root 1651 Aug 24 06:23 /usr/sbin/ifdown
-rwxr-xr-x. 1 root root 5010 Aug 24 06:23 /usr/sbin/ifup
https://bugzilla.redhat.com/show_bug.cgi?id=1626517
A few components are still disabled. Most notably, team support
which is not available on Ubuntu 14.04 (trusty).
All other components which are disabled are bugs in our build tools.
It should be possible to enable them, but currently breaks on travis.
Those needs additional fixes.
In particular, the DHCP plugins and ifcfg-rh plugin with meson.
Also, netconfig plugin with autotools requires that the path exists.
(cherry picked from commit e893405927)
A few components are still disabled. Most notably, team support
which is not available on Ubuntu 14.04 (trusty).
All other components which are disabled are bugs in our build tools.
It should be possible to enable them, but currently breaks on travis.
Those needs additional fixes.
In particular, the DHCP plugins and ifcfg-rh plugin with meson.
Also, netconfig plugin with autotools requires that the path exists.
Rename variables for the error number. Commonly the naming
is:
- errno: the error number from <errno.h> itself
- errsv: a copy of errno
- nlerr: a netlink error number
- err: an error code, but not a errno/errsv and not
a netlink error number.
(cherry picked from commit f4de941d98)
Rename variables for the error number. Commonly the naming
is:
- errno: the error number from <errno.h> itself
- errsv: a copy of errno
- nlerr: a netlink error number
- err: an error code, but not a errno/errsv and not
a netlink error number.
Internal DHCPv4 client requires a valid MAC address for functioning.
Just always require a MAC address to start DHCP, both v4 and v6.
We have no MAC address for example on Layer3 devices like tun or wireguard.
Also, before "0a797bdc2a systemd/dhcp: fix assertion starting DHCP
client without MAC address", if we tired to start sd_dhcp_client without
setting a MAC address, an assertion was triggered.
(cherry picked from commit e8fa75ce06)
An assertion in dhcp_network_bind_raw_socket() is triggered when
starting an sd_dhcp_client without setting setting a MAC address
first.
- sd_dhcp_client_start()
- client_start()
- client_start_delayed()
- dhcp_network_bind_raw_socket()
In that case, the arp-type and MAC address is still unset. Note that
dhcp_network_bind_raw_socket() already checks for a valid arp-type
and MAC address below, so we should just gracefully return -EINVAL.
Maybe sd_dhcp_client_start() should fail earlier when starting without
MAC address. But the failure here will be correctly propagated and
the start aborted.
See-also: https://github.com/systemd/systemd/pull/10054
(cherry picked from commit 34af574d58)
Internal DHCPv4 client requires a valid MAC address for functioning.
Just always require a MAC address to start DHCP, both v4 and v6.
We have no MAC address for example on Layer3 devices like tun or wireguard.
Also, before "34af574d58 systemd/dhcp: fix assertion starting DHCP
client without MAC address", if we tired to start sd_dhcp_client without
setting a MAC address, an assertion was triggered.
An assertion in dhcp_network_bind_raw_socket() is triggered when
starting an sd_dhcp_client without setting setting a MAC address
first.
- sd_dhcp_client_start()
- client_start()
- client_start_delayed()
- dhcp_network_bind_raw_socket()
In that case, the arp-type and MAC address is still unset. Note that
dhcp_network_bind_raw_socket() already checks for a valid arp-type
and MAC address below, so we should just gracefully return -EINVAL.
Maybe sd_dhcp_client_start() should fail earlier when starting without
MAC address. But the failure here will be correctly propagated and
the start aborted.
See-also: https://github.com/systemd/systemd/pull/10054
It's enough that all code paths in impl_ppp_manager_set_ifindex() log exactly
one message. Also, give all messages the same prefix, so that it's clear where
they come from.
(cherry picked from commit 2a45c32e8c)
In src/ppp/nm-pppd-plugin.c, it seems that pppd can invoke
phasechange(PHASE_RUNNING:) multiple times. Hence, the plugin
calls SetIfindex multiple times too. In nm-ppp-manager.c, we
want to make sure that the ifindex does not change after it
was set once. However, calling SetIfindex with the same ifindex
is not something worth warning. Just log a debug message and nothing.
Maybe the plugin should remember that it already set the ifindex,
and avoid multiple D-Bus calls. But it's unclear that that is desired.
For now, just downgrade the warning.
(cherry picked from commit 4a4439835d)
