Debian stretch's init script for isc-dhcp-server uses the INTERFACESv4|6
variables to decide whether to start the v4 and/or v6 DHCP server.
If they are not empty, the daemon is started for the respective version,
however, if both are empty (the default), to listen on all interfaces, the
daemon is started for both versions. The latter would require a subnet
config for IPv6 as the daemon otherwise exits, letting the init script fail,
while keeping the successfully started v4 version running, which, in turn,
can't be stopped anymore with the init script because it thinks the daemon
is not running.
So it's not possible with this init script to start DHCPv4 on all interfaces
without having to configure and run DHCPv6 also.
While we could continue to use FreeRADIUS 2.x that branch is officially EOL.
So instead of investing time and effort in updating/migrating the patches to
FreeRADIUS 3.x (the module changed quite significantly as it relies solely on
the naeap library in that release), for a protocol that is superseded anyway,
we just remove these scenarios and the dependencies. Actually, the
complete rlm_eap_tnc module will be removed with FreeRADIUS 4.0.
RC4, which was previously used for performance reasons, is not supported
anymore with newer versions of SSH (stretch still supports it, but it
requires explicit configuration on the guests when they act as clients
too - the version in Ubuntu 18.04 apparently doesn't support it anymore
at all).
AES-GCM should actually be faster (at least for larger amounts of data and
in particular with hardware acceleration).
ClientAuthentication is known in OpenSSL 1.1 and the redefinition, therefore,
causes an error. These two OIDs are not used anyway in these config
files.
We could make the same change for charon (actually setting it for charon
in strongswan.conf.testing would work for charon-systemd too), however,
there are dozens of test cases that currently set charondebug in
ipsec.conf.
When charon is started via service command LEAK_DETECTIVE_LOG is not set
because the command strips the environment. Since we only want the
variable to be set during the automated test runs we can't just set it
in /etc/default/charon. Instead, we do so in this wrapper when charon is
started and remove the variable again when it is stopped.
This reverts commit dee01d019ba9743b2784b417155601d10c173a66.
Thanks to 505c31870162 ("leak-detective: Try to properly free
allocations after deinitialization") this is not required anymore.
The main issue is that the ldap and curl plugins, or rather the libraries
they use, initialize GnuTLS (curl, strangely, even when it is, by its own
account, linked against OpenSSL). Some of these allocations are only freed
once the libraries are unloaded. This means that the leak detective causes
invalid frees when swanctl is terminated and libraries are unloaded after the
leak detective is already deinitialized.
It is still compatible with the current release as the config in
sites-available will be ignored, while conf-enabled does not exist and
is not included in the main config.
GnuTLS, which can get loaded by the curl plugin, does not properly cleanup
some allocated memory when deinitializing. This causes invalid frees if
leak detective is active. Other invalid frees are related to time
conversions (tzset).
References #1382.
We will use this to set some defaults (e.g. timeouts to make testing
negative tests quicker). We don't want these settings to show up in the
configs of the actual scenarios though.
