So I have a test like (with custom config since require_secure_transport=ON)

[grooverdan]

          So I have a test like (with custom config since `require_secure_transport=ON`)

test: [ "CMD", "healthcheck.sh", "--defaults-file=/etc/mysql/conf.d/my.cnf", "--connect", "--innodb_initialized" ]

And it's spamming a lot of warnings like

2024-06-24 11:44:15 120 [Warning] Aborted connection 120 to db: 'unconnected' user: 'unauthenticated' host: '::1' (This connection closed normally without authentication)

And looks like it's spamming this specifically if there is a --connect argument, even though validation succeeds. I tested this specifically spamming the respective command manually on the container.
I understand that this is "kind of" normal, since --connect is expected to just try to establish TCP connection, not authenticate, but can we somehow suppress the warnings for the check? The settings in manual do suggest using 10s interval, but then it means spamming the false-positive warning every 10 seconds, even when connection is technically established.
Or am I doing something wrong?

Originally posted by @Simbiat in #573 (comment)

[grooverdan]

caused by #594

[grooverdan]

@Simbiat - testing of #597 welcome.

[Simbiat]

I am not sure I fully understand the description of the pull request, but if what it's changing is related to a workaround for incorrect TLS, then I am not sure this is correct approach.
My logic is simple: if require_secure_transport is off - we do not care for TLS and if it fails during --connect, but we still connect - it's fine. If require_secure_transport is on, then failing of TLS handshake essentially means failure of --connect. No, if the server-side keys are not setup correctly - that's on server admin entirely, and if keys are not present, or otherwise fail - we should fail the healthcheck. But if the issue is with incorrect client-side keys - that's something that can be managed: just generate the keys for healthcheck user, if they do not exist. If a custom config is used - that's again on the server admin, so we should fail the check if something is wrong.
As for removing protocol=tcp, I got inconsistent behavior. On test environment - that did seem to help, but on prod environment - no, even after container restart to ensure new config is pulled in (in case there is some caching). But then, i also switched to using custom config in the first place (for the sake of TLS), and custom config does not have protocol in it at all, and I was still getting warnings, when using --connect

[grooverdan]

Am I missing the minimal case of what is the issue:

$ podman run --rm --env MARIADB_ROOT_PASSWORD=1 --name msec  -d  mariadb:11.4 --require-secure-transport=1
$ podman exec msec bash -x -v healthcheck.sh --connect && echo ya

Seem to be healthy? Are you using TLS certs/keys as well?

[Simbiat]

Contents of config are here, security.cnf included in it has only login/password for client and ssl_* files for both server and client (3 for each).
Server launched in Docker container through docker compose (dockerfile).

healthcheck.sh --defaults-file=/etc/mysql/conf.d/my.cnf --connect

In this case it works fine, but generates warnings in logs.

healthcheck.sh --connect

Fails because no TLS is used, and not setup in healthcheck.cnf generated on original container start

[grooverdan]

Thanks for the clarification and I can immediately see that #594 caused this problem for you.

There's a current problem with < 11.4 images which is:

$ podman run --rm --env MARIADB_ROOT_PASSWORD=1 --name msec  -d  mariadb:10.6 --require-secure-transport=1
1a4620f1de4ef21e666dd60f671ca82dd0c1be834682bd71da5fa0dd6777b499

$ podman exec msec healthcheck.sh --connect --innodb_initialized
ERROR 1045 (28000): Access denied for user 'healthcheck'@'::1' (using password: YES)
healthcheck innodb_initialized failed

This probably isn't a new problem, but using --require-secure-transport would make the healthchecks fails and it seems important to fix this at the same time.

Because healthchecks are over tcp and with TLS disabled because of #594, the --require-secure-transport is considering the connection insecure and failing to perform any SQL test.

11.4, similar thing with a better error message:

$ podman run --rm --env MARIADB_ROOT_PASSWORD=1 --name msec  -d  mariadb:11.4 --require-secure-transport=1
1cae8bb80bee3d2583c1dcd68a711e26d2e671c92b558f786ccd2c17905f7733

$ podman exec msec healthcheck.sh --connect --innodb_initialized
ERROR 3159 (08004): Connections using insecure transport are prohibited while --require_secure_transport=ON.
healthcheck innodb_initialized failed

So its these two cases that is making the fix a little more extensive that originally envisioned. The alternate is using tcp and creating tls certs and keys for a local connection.

The unix socket counts as a secure transport, but the determination of --connect without causing warnings required a connection to be successful. This is why the check of SELECT @@skip_networking exists. To ensure that this isn't a install/upgrade instance starting.