Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.4.27, 10.5.18, 10.6.11, 10.7.7, 10.8.6, 10.9.4, 10.10.2, 10.11.1
-
None
-
Ubuntu 22.04, RHEL 8.7, or any other distribution that comes with socat version >= 1.7.4.0
Description
socat version 1.7.4.0 has added this new feature:
OPENSSL-CONNECT now automatically uses the SNI feature, option
|
openssl-no-sni turns it off. Option openssl-snihost overrides the value
|
of option openssl-commonname or the server name.
|
Tests: OPENSSL_SNI OPENSSL_NO_SNI
|
Thanks to Travis Burtrum for providing the initial patch
|
This leads to setups using encrypted mariabackup SST method with encrypt=4 (haven't tested other encryption modes yet) to fail with
E Failed to set SNI host ""
|
on the donor side on distributions that have already upgraded to the new socat version, e.g. RHEL 8 and Ubuntu 22.04 "Jammy" which both come with 1.7.4.1
For now I have been able to fix this by adding the new no-sni=1 option to the donor side socat call when detecting socat version 1.7.4+, but I don't understand the situation well enough yet to say whether this may not be a bit too brute force after all ...
diff --git a/wsrep_sst_mariabackup b/wsrep_sst_mariabackup
|
index 63ef8be..d60d6d5 100755
|
--- a/wsrep_sst_mariabackup
|
+++ b/new/wsrep_sst_mariabackup
|
@@ -339,6 +339,10 @@ get_transfer()
|
"Use workaround for socat $SOCAT_VERSION bug"
|
fi
|
fi
|
+ get_socat_ver
|
+ if check_for_version "$SOCAT_VERSION" '1.7.4.0'; then
|
+ tcmd="$tcmd,no-sni=1"
|
+ fi
|
fi
|
|
if [ "${sockopt#*,dhparam=}" = "$sockopt" ]; then
|
|