Bug#1056193: glusterfs-client: GlusterFS SSL path changed without warning in Bookworm
Xan Charbonnet
Version: 10.3-5
Severity: normal
Dear Maintainer,
I have a bullseye GlusterFS cluster which uses SSL/TLS. Three machines have
a replica of the data, and an additional one merely mounts the cluster without
local storage for purposes of backing it up.
I recently upgraded the backup machine to bookworm. Suddenly I was unable to
mount the cluster. The key error in the logs was:
E [socket.c:4405:ssl_setup_connection_params] 0-glusterfs: could not load our
cert at /usr/lib/ssl/glusterfs.pem
/usr/lib/ssl/ is a strange path. As far as I can tell, the correct path is
/etc/ssl/. Creating three symlinks fixed the problem and allowed the cluster
to be mounted:
/usr/lib/ssl/glusterfs.ca -> /etc/ssl/glusterfs.ca
/usr/lib/ssl/glusterfs.pem -> /etc/ssl/glusterfs.pem
/usr/lib/ssl/glusterfs.key -> /etc/ssl/glusterfs.key
Taking another look at the apt-listchanges output for the upgrade, there is
nothing from any gluster package. This leads me to believe that the changing
of this path was unintentional and is a bug. Not sure what's the best thing
to do about it at this point, since fixing it would break people's existing
bookworm configurations.
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-13-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages glusterfs-client depends on:
ii glusterfs-common 10.3-5
ii libc6 2.36-9+deb12u3
ii python3 3.11.2-1+b1
glusterfs-client recommends no packages.
glusterfs-client suggests no packages.
-- no debconf information
David Bremner
"Debian Bug Tracking System" <ow...@bugs.debian.org> writes:
> This is an automatic notification regarding your Bug report
> which was filed against the glusterfs-client package:
> Am 18.11.2023 um 17:37 schrieb Xan Charbonnet:
>> I recently upgraded the backup machine to bookworm. Suddenly I was unable to
>> mount the cluster. The key error in the logs was:
>>
>> E [socket.c:4405:ssl_setup_connection_params] 0-glusterfs: could not load our
>> cert at /usr/lib/ssl/glusterfs.pem
>>
>
> But if you look in /usr/lib/ssl =>
>
> $ ls -l /usr/lib/ssl/ insgesamt 4 lrwxrwxrwx 1 root root 34 23. Okt
> 19:52 cert.pem -> /etc/ssl/certs/ca-certificates.crt lrwxrwxrwx 1 root
> root 14 13. Mär 2012 certs -> /etc/ssl/certs drwxr-xr-x 2 root root 4096
> 25. Okt 06:25 misc lrwxrwxrwx 1 root root 20 23. Okt 19:52 openssl.cnf
> -> /etc/ssl/openssl.cnf lrwxrwxrwx 1 root root 16 13. Mär 2012 private
> -> /etc/ssl/private
>
> So if you use the subdirectories the paths are correct (in /etc)
That's all very well, but glusterd is not looking in a subdirectory of
/usr/lib/ssl it is looking for /usr/lib/ssl/glusterfs.pem, as pointed
out above.
FYI, upstreams docs [1] show gluster looking in /etc/ssl, not in a
subdirectory.
https://docs.gluster.org/en/latest/Administrator-Guide/SSL/
Patrick Matthäi
tag #1056193 + pending
thanks
Hey,
I will upload the attached patch with my next upload. But this is nothing I can fix in stable => since an update will break again now working setups using /usr/lib/ssl/..
The best option would be if gluster would make the paths configureable
btw I may also upload 11.x this year to bookworm-backports
That's all very well, but glusterd is not looking in a subdirectory of /usr/lib/ssl it is looking for /usr/lib/ssl/glusterfs.pem, as pointed out above. FYI, upstreams docs [1] show gluster looking in /etc/ssl, not in a subdirectory. https://docs.gluster.org/en/latest/Administrator-Guide/SSL/
# On Debian like systems the output of openssl version -d is
/usr/lib/ssl,
# where are symlinks in it to the correct directories in
/etc/ssl.
# But glusterfs hardcodes the certificate files to be placed
directly in
# /usr/lib/ssl, without the correct subdirectories. So that it
is possible
# again to store the certificate data in /etc/ssl/ we hardcode
the path now.
# A better solution would be to configure the paths in the
volfiles, but that
# is not possible, yet.
# Closes: #1056193
diff -Naur glusterfs-11.1.orig/configure
glusterfs-11.1/configure
--- glusterfs-11.1.orig/configure 2023-11-06
16:24:29.990040453 +0100
+++ glusterfs-11.1/configure 2023-12-12 11:59:03.930931968
+0100
@@ -14553,7 +14553,7 @@
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for OpenSSL
trusted certificates path" >&5
$as_echo_n "checking for OpenSSL trusted certificates path... "
>&6; }
-SSL_CERT_PATH=$(openssl version -d | sed -e 's|OPENSSLDIR:
"\(.*\)".*|\1|')
+SSL_CERT_PATH=/etc/ssl
if test -d "${SSL_CERT_PATH}" 1>/dev/null 2>&1; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$SSL_CERT_PATH" >&5
$as_echo "$SSL_CERT_PATH" >&6; }
diff -Naur glusterfs-11.1.orig/configure.ac
glusterfs-11.1/configure.ac
--- glusterfs-11.1.orig/configure.ac 2023-11-06
16:24:25.401026631 +0100
+++ glusterfs-11.1/configure.ac 2023-12-12 11:59:20.278889134
+0100
@@ -803,7 +803,7 @@
dnl Find out OpenSSL trusted certificates path
AC_MSG_CHECKING([for OpenSSL trusted certificates path])
-SSL_CERT_PATH=$(openssl version -d | sed -e 's|OPENSSLDIR:
"\(.*\)".*|\1|')
+SSL_CERT_PATH=/etc/ssl
if test -d "${SSL_CERT_PATH}" 1>/dev/null 2>&1; then
AC_MSG_RESULT([$SSL_CERT_PATH])
AC_DEFINE_UNQUOTED(SSL_CERT_PATH, ["$SSL_CERT_PATH"], [Path
to OpenSSL trusted certificates.])
Xan Charbonnet
It seems to me that a warning about the situation needs to be added to
the bookworm release notes, and/or apt-listchanges, because people might
upgrade to bookworm as I recently did and find their configuration broken.
The same would need to be done for trixie since anybody successfully
running the bookworm version will find their configuration broken when
upgrading to trixie.