[debian-mysql] Bug#1026353: mariadb-server: mariadb does not start after bullseye point release 11.6

[Matt Zagrabelny]

Thanks for the reply Mika.


On Mon, Dec 19, 2022 at 4:02 AM Michael Prokop <mika at debian.org> wrote:

> * Matthew P Zagrabelny [Sun Dec 18, 2022 at 04:11:54PM -0600]:
> > Package: mariadb-server
> > Version: 1:10.5.18-0+deb11u1
> > Severity: important
> >
> > Unattended upgrade upgraded mariadb this morning and now the service
> does not
> > start:
> >
> [...]
>
> > Dec 18 15:25:36 mariadb-test-system systemd[1]: Starting MariaDB 10.5.18
> database server...
> > Dec 18 15:25:37 mariadb-test-system mariadbd[604]: 2022-12-18 15:25:37 0
> [Note] /usr/sbin/mariadbd (mysqld 10.5.18-MariaDB-0+deb11u1) starting as
> process 604 ...
> > Dec 18 15:25:38 mariadb-test-system systemd[1]: mariadb.service: Main
> process exited, code=exited, status=1/FAILURE
> > Dec 18 15:25:38 mariadb-test-system systemd[1]: mariadb.service: Failed
> with result 'exit-code'.
> > Dec 18 15:25:38 mariadb-test-system systemd[1]: Failed to start MariaDB
> 10.5.18 database server.
>
> Same here, check whether you have any non-existent SSL keys or alike
> referenced in your configuration, like:
>
> | [mysqld]
> | [...]
> | ssl = false
> | ssl-ca = /etc/mysql/cacert.pem
> | ssl-cert = /etc/mysql/server-cert.pem
> | ssl-key = /etc/mysql/server-key.pem
> | [...]
>
> So while it was even set to `ssl = false` on this system, it now
> fails with:
>
> | 2022-12-19 10:33:24 0 [ERROR] Failed to setup SSL
> | 2022-12-19 10:33:24 0 [ERROR] SSL error:
> SSL_CTX_set_default_verify_paths failed
> | 2022-12-19 10:33:24 0 [ERROR] Aborting
>
> (FTR, removing the ssl-ca/ssl-cert/ssl-key settings fixed it for me,
> those settings came from defaults of
> https://github.com/puppetlabs/puppetlabs-mysql so I'm sure more
> folks will be affected.)
>

Exactly. We're using that module. A potential fix is to set:

'ssl-disable' => true

in the puppet manifest, but that generates spurious warnings and mysqld
refreshes:

# puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for apps-db2-test.d.umn.edu
Info: Applying configuration version '1671460837'
Notice: Disabling SSL is evil! You should never ever do this except
                if you are forced to use a mysql version compiled without
SSL support
Notice: /Stage[main]/Mysql::Server::Config/Notify[ssl-disable]/message:
defined 'message' as "Disabling SSL is evil! You should never ever do this
except\n                if you are forced to use a mysql version compiled
without SSL support"
Info: Class[Mysql::Server::Config]: Scheduling refresh of
Class[Mysql::Server::Service]
Info: Class[Mysql::Server::Service]: Scheduling refresh of Service[mysqld]
Info: Class[Mysql::Server::Service]: Scheduling refresh of
Exec[wait_for_mysql_socket_to_open]
Notice: /Stage[main]/Mysql::Server::Service/Service[mysqld]: Triggered
'refresh' from 1 event
Notice:
/Stage[main]/Mysql::Server::Service/Exec[wait_for_mysql_socket_to_open]:
Triggered 'refresh' from 1 event
Notice: Applied catalog in 10.70 seconds

So... I'm not sure what the best way forward is.

I've just removed the puppet code that generates the notify:

--- /root/config.pp.HOLD        2022-12-19 08:46:59.114451680 -0600
+++
/usr/share/puppet/modules.available/puppetlabs-mysql/manifests/server/config.pp
    2022-12-19 08:47:27.070698800 -0600
@@ -48,11 +48,4 @@ class mysql::server::config {
       }
     }
   }
-
-  if $options['mysqld']['ssl-disable'] {
-    notify {'ssl-disable':
-      message =>'Disabling SSL is evil! You should never ever do this
except
-                if you are forced to use a mysql version compiled without
SSL support'
-    }
-  }
 }

Things seem to run cleanly now. However, this is starting to feel a bit
hacky.

Thanks again for the pointers, Mika.

-m
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-mysql-maint/attachments/20221219/6eccf361/attachment.htm>