[MDEV-19934] Replacing MySQL's mysql-common can further break MariaDB configuration Created: 2019-07-02  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: Configuration, Packaging, Platform Debian
Affects Version/s: 10.2, 10.3, 10.4
Fix Version/s: 10.4

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Unresolved Votes: 0
Labels: None


 Description   

As noted in MDEV-19933, modern Debians/Ubuntus have MySQL's my.cnf installed via alternatives:

drwxr-xr-x 2 root root 4096 May 15  2018 conf.d
lrwxrwxrwx 1 root root   24 May 15  2018 my.cnf -> /etc/alternatives/my.cnf
-rw-r--r-- 1 root root  839 Aug  3  2016 my.cnf.fallback

The following admittedly convoluted chain of events can break MariaDB configuration:

  • while MySQL's mysql-common is still there, install MariaDB's mysql-common instead – explicitly, because it doesn't get pulled as a dependency:

    ii  mysql-common                  1:10.3.16+maria~stretch        all          MariaDB database common files (e.g. /etc/mysql/my.cnf)
    

    The cnf file remains as it was, both the alternative and the symlink:

    drwxr-xr-x 2 root root 4096 Jun 20  2017 conf.d
    lrwxrwxrwx 1 root root   24 Jun 20  2017 my.cnf -> /etc/alternatives/my.cnf
    -rw-r--r-- 1 root root 5264 Jun 14 18:25 my.cnf.dpkg-new
    -rw-r--r-- 1 root root  839 Jul  9  2016 my.cnf.fallback
    

  • Remove and purge mysql-common. It removes the alternative, but keeps the symlink:

    buildbot@debian-9-stretch-amd64:~$ ls -l /etc/mysql/
    total 8
    lrwxrwxrwx 1 root root   24 Jun 20  2017 my.cnf -> /etc/alternatives/my.cnf
    -rw-r--r-- 1 root root 5264 Jun 14 18:25 my.cnf.dpkg-new
    buildbot@debian-9-stretch-amd64:~$ ls -l /etc/alternatives/my.cnf 
    lrwxrwxrwx 1 root root 26 Jun 20  2017 /etc/alternatives/my.cnf -> /etc/mysql/my.cnf.fallback
    buildbot@debian-9-stretch-amd64:~$ ls -l /etc/mysql/my.cnf.fallback
    ls: cannot access '/etc/mysql/my.cnf.fallback': No such file or directory
    

  • install mariadb-server. It installs mysql-common again as a dependency, but doesn't replace the broken symlink

    buildbot@debian-9-stretch-amd64:~$ ls -l /etc/mysql/
    total 28
    drwxr-xr-x 2 root root 4096 Jul  2 18:30 conf.d
    -rw------- 1 root root  333 Jul  2 18:30 debian.cnf
    -rwxr-xr-x 1 root root 1525 Jun 14 18:25 debian-start
    -rw-r--r-- 1 root root  527 Jun 14 18:25 mariadb.cnf
    drwxr-xr-x 2 root root 4096 Jun 14 22:41 mariadb.conf.d
    lrwxrwxrwx 1 root root   24 Jun 20  2017 my.cnf -> /etc/alternatives/my.cnf
    -rw-r--r-- 1 root root 5264 Jun 14 18:25 my.cnf.dpkg-new
    buildbot@debian-9-stretch-amd64:~$ ls -l /etc/alternatives/my.cnf
    lrwxrwxrwx 1 root root 26 Jun 20  2017 /etc/alternatives/my.cnf -> /etc/mysql/my.cnf.fallback
    buildbot@debian-9-stretch-amd64:~$ ls -l /etc/mysql/my.cnf.fallback
    ls: cannot access '/etc/mysql/my.cnf.fallback': No such file or directory
    

    So, no configuration is enabled at all – neither the contents of mariadb.conf.d nor conf.d, thus no plugins etc.



 Comments   
Comment by Elena Stepanova [ 2019-07-24 ]

Here is another strange effect of having pre-installed config files on Debians, e.g. on the final Buster.
It has this by default

ii  libmariadb3:amd64             1:10.3.15-1                 amd64        MariaDB database client library
ii  mariadb-common                1:10.3.15-1                 all          MariaDB common metapackage
ii  mysql-common                  5.8+1.0.5                   all          MySQL database common files, e.g. /etc/mysql/my.cnf

The packages belong to Debian, they are not built by MariaDB.

Upon installation of MariaDB packages, if we install mariadb-common and mysql-common at once, it falls into interactive mode, even with DEBIAN_FRONTEND=noninteractive and apt-get install -y:

$ sudo sh -c 'DEBIAN_FRONTEND=noninteractive MYSQLD_STARTUP_TIMEOUT=180 apt-get install --allow-unauthenticated -y mariadb-common mysql-common'
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  mariadb-common mysql-common
2 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 9,076 B of archives.
After this operation, 71.7 kB disk space will be freed.
Get:1 http://mirror.netinch.com/pub/mariadb/repo/10.3/debian buster/main amd64 mysql-common all 1:10.3.16+maria~buster [5,580 B]
Get:2 http://mirror.netinch.com/pub/mariadb/repo/10.3/debian buster/main amd64 mariadb-common all 1:10.3.16+maria~buster [3,496 B]
Fetched 9,076 B in 0s (19.4 kB/s)
apt-listchanges: Reading changelogs...
(Reading database ... 45456 files and directories currently installed.)
Preparing to unpack .../mysql-common_1%3a10.3.16+maria~buster_all.deb ...
Unpacking mysql-common (1:10.3.16+maria~buster) over (5.8+1.0.5) ...
Preparing to unpack .../mariadb-common_1%3a10.3.16+maria~buster_all.deb ...
Unpacking mariadb-common (1:10.3.16+maria~buster) over (1:10.3.15-1) ...
Setting up mysql-common (1:10.3.16+maria~buster) ...
 
Configuration file '/etc/mysql/my.cnf' (actually '/etc/mysql/mariadb.cnf')
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.

This currently causes a failure in minor-upgrade-all on Buster.
For now, I am going to use -o Dpkg::Options::="--force-confnew" as a workaround (if we are lucky and it will work on all debians), but it's not ideal.

Oddly, if the packages are installed separately, it works:

sudo sh -c 'DEBIAN_FRONTEND=noninteractive MYSQLD_STARTUP_TIMEOUT=180 apt-get install --allow-unauthenticated -y mariadb-common'
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  mariadb-common
1 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 3,496 B of archives.
After this operation, 58.4 kB disk space will be freed.
Get:1 http://mirror.netinch.com/pub/mariadb/repo/10.3/debian buster/main amd64 mariadb-common all 1:10.3.16+maria~buster [3,496 B]
Fetched 3,496 B in 0s (9,850 B/s)          
apt-listchanges: Reading changelogs...
(Reading database ... 45456 files and directories currently installed.)
Preparing to unpack .../mariadb-common_1%3a10.3.16+maria~buster_all.deb ...
Unpacking mariadb-common (1:10.3.16+maria~buster) over (1:10.3.15-1) ...
Setting up mariadb-common (1:10.3.16+maria~buster) ...
Installing new version of config file /etc/mysql/mariadb.cnf ...
$

$ sudo sh -c 'DEBIAN_FRONTEND=noninteractive MYSQLD_STARTUP_TIMEOUT=180 apt-get install --allow-unauthenticated -y mysql-common'
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  mysql-common
1 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 5,580 B of archives.
After this operation, 13.3 kB disk space will be freed.
Get:1 http://mirror.netinch.com/pub/mariadb/repo/10.3/debian buster/main amd64 mysql-common all 1:10.3.16+maria~buster [5,580 B]
Fetched 5,580 B in 0s (15.8 kB/s)       
apt-listchanges: Reading changelogs...
(Reading database ... 45456 files and directories currently installed.)
Preparing to unpack .../mysql-common_1%3a10.3.16+maria~buster_all.deb ...
Unpacking mysql-common (1:10.3.16+maria~buster) over (5.8+1.0.5) ...
Setting up mysql-common (1:10.3.16+maria~buster) ...
$

Comment by Otto Kekäläinen [ 2020-02-24 ]

Maybe we can stop shipping a separate mysql-common in MariaDB 10.5 and have the packaging less different from what is used in downstream Debian officially now.

Generated at Thu Feb 08 08:55:28 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.