"TLS/SSL error: SSL is required, but the server does not support it" in Debian Trixie

[zen-fu]

Describe the Bug

This module defaults to ssl = false in the server, but "Starting from 11.4 MariaDB encrypts the transmitted data between the server and clients by default (they also say "unless the server and client run on the same host" but that's not what I experience in Debian Trixie).

Deploying MariaDB with this module in a fresh Debian Trixie install leads to:

# mysql
ERROR 2026 (HY000): TLS/SSL error: SSL is required, but the server does not support it

Expected Behavior

Connecting to the server should succeed.

Steps to Reproduce

Steps to reproduce the behavior:

1. Start from a fresh Debian Trixie installation.
2. Install Puppet and Git
3. Download latest versions of puppetlabs-stdlib and puppetlabs-mysql
4. Puppet-apply include mysql::server

This should be enough to reproduce the issue:

apt-get update && apt-get -y install git puppet
mkdir -p /root/modules
git clone --depth 1 --branch v9.7.0 https://github.com/puppetlabs/puppetlabs-stdlib.git /root/modules/stdlib
git clone --depth 1 --branch v16.2.0 https://github.com/puppetlabs/puppetlabs-mysql.git /root/modules/mysql
puppet apply --modulepath /root/modules -e 'include mysql::server'

Then:

# mysql
ERROR 2026 (HY000): TLS/SSL error: SSL is required, but the server does not support it

Environment

• Version 16.2.0
• Platform Debian Trixie (MariaDB 11.8.1)

[thomasgoirand]

Hi,

I just found out that the issue is this module setting-up:

ssl = false

in /etc/mysql/my.cnf. Commenting out the directive fixes the issue. I'll se how this may be fixed/patched, I guess it shouldn't be too hard.

[thomasgoirand]

Ok, so I got it now. There's no issue, it's just that to have no SSL config at all, one needs to pass:

ssl-disable => true

to this module. This way, any directive that starts with ssl will be skipped from the config file, including ssl = false, which will automagically makes everything work. :)

Note that this behavior in this module is backward compatible until at least version 5, even though it seems like the issue if not setting ssl-disable => true is only relevant to newer mariadb servers.

So I believe this issue can be closed.

[zen-fu]

Hello @thomasgoirand !

There's no issue

i don't understand your rationale because, in my tests, when i deploy the module with its default config i can't just type mysql and get a working connection to the local service, as i expect.

Do you not consider this behavor an issue, or do you have a different behavior with the default config? Or is it something else that i didn't get? :-)

Thanks!

[lelutin]

@thomasgoirand I concur with @zen-fu here. users expect defaults from the module to make sense. if the configuration created by the default options is broken it is indeed a bug.

In mysql::server::params some choices are made for the default $provider, choosing between mysql and mariadb.

I would suggest that when mariadb is chosen as the default $provider, and for releases where mariadb 11.4+ is shipped, the ssl => false option be omitted from $default_options

caveat: debian 13 is not released yet, but it should be expected to be there this summer.

[pkhillari]

@thomasgoirand, setting ssl-disable to true worked for me.
I'm using Ubuntu 24.04 and MySQL v8.4 LTS

@lelutin In my opinion, setting defaults is fine, but code should have a provision to alter defaults.
In this case, there should be a choice to remove SSL=FALSE.
Hardcoding config options wouldn't be future-proof.

As per my understanding of this module, the override_options param of mysql::server should handle this.

[lelutin]

@lelutin In my opinion, setting defaults is fine, but code should have a provision to alter defaults. In this case, there should be a choice to remove SSL=FALSE. Hardcoding config options wouldn't be future-proof.

As per my understanding of this module, the override_options param of mysql::server should handle this.

agreed it should be possible to change the configuration.

my point of view is really just that default options should not generate a configuration that's broken