MariaDB 1.3.27 overwrites customized my.cnf

[Bernard Spil]

On 2020-12-04 12:29, Miroslav Lachman wrote:

> Am I the only one who sees this (critical) problem after upgrade from 
> MariaDB 10.3.23 to newer version (10.3.25 or 10.3.27)?
> 
> There is our customized fine-tuned /usr/local/etc/my.cnf for years 
> untouched by pkg install or pkg upgrade. After the last pkg upgrade 
> MariaDB cannot (re)start because my.cnf was replaced with some generic 
> file which contains this:
> 
> #
> # This group is read both by the client and the server
> # use it for options that affect everything
> #
> [client-server]
> 
> #
> # include *.cnf from the config directory
> #
> !includedir /usr/local/etc/mysql/conf.d
> 
> But the directory /usr/local/etc/mysql/conf.d is empty. If something 
> silently replaces my config file I would expect it to move my file to 
> proper location which is not the case. My file is simply replaced and 
> configuration of MariaDB is lost and daemon cannot be (re)started any 
> more. I think this is POLA, should be mentioned in UPDATING and 
> pkg-message.
> The only way to make it work again is restore my.cnf from backup.
> 
> I filled  bug report as PR 251550
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251550
> 
> It seems really critical to me but I am surprised nobody else reported 
> this.
> 
> This is on FreeBSD 11.4 amd64 with packages built in our Poudriere
> 
> Options        :
> CONNECT_EXTRA  : off
> DOCS           : off
> GSSAPI_BASE    : off
> GSSAPI_HEIMDAL : off
> GSSAPI_MIT     : off
> GSSAPI_NONE    : on
> INNOBASE       : on
> LZ4            : on
> LZO            : on
> MROONGA        : off
> MSGPACK        : off
> OQGRAPH        : off
> ROCKSDB        : off
> SNAPPY         : off
> SPHINX         : on
> SPIDER         : on
> TOKUDB         : off
> WSREP          : on
> ZMQ            : off
> ZSTD           : off
> 
> Kind regards
> Miroslav Lachman

Fixed in mariadb103-client-10.3.27_1

Very sorry for this, that was very bad. I hope you have a backup of your 
my.cnf!