Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-26850

Repository upgrade silently removes my.cnf

Details

    Description

      When we used MariaDB repository installations and upgraded from 10.3 to 10.5 the installation script silently removed our my.cnf file (does NO backup!).
      After the upgrade connection with clients was not possible any more (because bind_address was set back to 127.0.0.1) and replication was broken.
      After restoring my.cnf configuration file everything worked fine again. So keep a backup of your my.cnf!

      Before upgrade:

      root@ubuntu2004:/etc/mysql# ll
      drwxr-xr-x  2 root root 4096 Oct 18 16:01 conf.d/
      -rw-------  1 root root  333 Oct 18 16:01 debian.cnf
      -rwxr-xr-x  1 root root 1525 Aug  2 12:58 debian-start*
      -rw-r--r--  1 root root  527 Aug  2 12:58 mariadb.cnf
      drwxr-xr-x  2 root root 4096 Aug  2 15:38 mariadb.conf.d/
      -rw-r--r--  1 root root 5170 Aug  2 12:58 my.cnf
      

      after upgrade:

      drwxr-xr-x  2 root root 4096 Oct 18 16:01 conf.d/
      -rw-------  1 root root  333 Oct 18 16:01 debian.cnf
      -rwxr-xr-x  1 root root 1731 Aug  3 10:29 debian-start*
      -rw-r--r--  1 root root 1126 Aug  3 10:29 mariadb.cnf
      drwxr-xr-x  3 root root 4096 Oct 18 16:13 mariadb.conf.d/
      lrwxrwxrwx  1 root root   24 Oct 18 16:13 my.cnf -> /etc/alternatives/my.cnf
      

      It is pretty nasty that the file was removed at all and that it did not creates at least a backup and outputs a warning!!! At least!

      Attachments

        Issue Links

          Activity

            oli,

            as far as I know the design - you shouldn't think about the shipped config files, instead you have to create custom file under /etc/mariadb.conf.d.
            all additional options and overrides should go to custom config file which will survive any upgrade

            abychko Alexey Bychko (Inactive) added a comment - oli , as far as I know the design - you shouldn't think about the shipped config files, instead you have to create custom file under /etc/mariadb.conf.d. all additional options and overrides should go to custom config file which will survive any upgrade

            closing because those config files are just version-specific defaults and shouldn't be edited

            abychko Alexey Bychko (Inactive) added a comment - closing because those config files are just version-specific defaults and shouldn't be edited

            otto, is there something we can change in packaging so that when a new my.cnf/mariadb.conf is installed, the old is is preserved as a backup?

            Something like RPM's %config, but not like %config(noreplace).
            https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html

            serg Sergei Golubchik added a comment - otto , is there something we can change in packaging so that when a new my.cnf / mariadb.conf is installed, the old is is preserved as a backup? Something like RPM's %config , but not like %config(noreplace) . https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html

            Steps to reproduce according to you download page:
            https://mariadb.org/download/?tab=repo-config&distro=Debian+10+%22buster%22&ver=10.3&r_mirror=mva

            • Fresh Debian 10 minimal
            • apt-get install software-properties-common dirmngr apt-transport-https
            • apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
            • add-apt-repository 'deb [arch=amd64,arm64,ppc64el] https://mirror.mva-n.net/mariadb/repo/10.3/debian buster main'
            • apt-get update
            • apt-get install mariadb-server
            • Change file /etc/mysql/my.cnf
            1. ls -ald /etc/mysql/*
              drwxr-xr-x 2 root root 4096 Nov 4 12:05 /etc/mysql/conf.d
              rw------ 1 root root 333 Nov 4 12:05 /etc/mysql/debian.cnf
              -rwxr-xr-x 1 root root 1525 Aug 2 12:58 /etc/mysql/debian-start
              rw-rr- 1 root root 527 Aug 2 12:58 /etc/mysql/mariadb.cnf
              drwxr-xr-x 2 root root 4096 Aug 2 14:33 /etc/mysql/mariadb.conf.d
              rw-rr- 1 root root 5201 Nov 4 12:05 /etc/mysql/my.cnf
            • Change file /etc/apt/sources.list from 10.3 to 10.5
            • apt-get update
            • apt-get upgrade mariadb-server

            Reading package lists... Done
            Building dependency tree
            Reading state information... Done
            Calculating upgrade... Done
            The following packages will be REMOVED:
            galera-3 mariadb-client-10.3 mariadb-client-core-10.3 mariadb-server-10.3 mariadb-server-core-10.3
            The following NEW packages will be installed:
            galera-4 mariadb-client-10.5 mariadb-client-core-10.5 mariadb-server-10.5 mariadb-server-core-10.5
            The following packages have been kept back:
            linux-image-amd64
            The following packages will be upgraded:
            base-files bind9-host debconf debconf-i18n distro-info-data krb5-locales libbind9-161 libdns-export1104 libdns1104 libgssapi-krb5-2
            libisc-export1100 libisc1100 libisccc161 libisccfg163 libk5crypto3 libkrb5-3 libkrb5support0 liblwres161 libmariadb3 mariadb-common
            mariadb-server mysql-common python3-debconf tzdata
            24 upgraded, 5 newly installed, 5 to remove and 1 not upgraded.
            Need to get 31.6 MB of archives.
            After this operation, 15.4 MB of additional disk space will be used.

            1. ls -ald /etc/mysql/*

            drwxr-xr-x 2 root root 4096 Nov 4 12:05 /etc/mysql/conf.d
            rw------ 1 root root 333 Nov 4 12:05 /etc/mysql/debian.cnf
            -rwxr-xr-x 1 root root 1731 Aug 3 10:29 /etc/mysql/debian-start
            rw-rr- 1 root root 1126 Aug 3 10:29 /etc/mysql/mariadb.cnf
            drwxr-xr-x 3 root root 4096 Nov 4 12:09 /etc/mysql/mariadb.conf.d
            lrwxrwxrwx 1 root root 24 Nov 4 12:09 /etc/mysql/my.cnf -> /etc/alternatives/my.cnf

            --> My changes in my.cnf where gone!

            oli Oli Sennhauser added a comment - Steps to reproduce according to you download page: https://mariadb.org/download/?tab=repo-config&distro=Debian+10+%22buster%22&ver=10.3&r_mirror=mva Fresh Debian 10 minimal apt-get install software-properties-common dirmngr apt-transport-https apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc' add-apt-repository 'deb [arch=amd64,arm64,ppc64el] https://mirror.mva-n.net/mariadb/repo/10.3/debian buster main' apt-get update apt-get install mariadb-server Change file /etc/mysql/my.cnf ls -ald /etc/mysql/* drwxr-xr-x 2 root root 4096 Nov 4 12:05 /etc/mysql/conf.d rw ------ 1 root root 333 Nov 4 12:05 /etc/mysql/debian.cnf -rwxr-xr-x 1 root root 1525 Aug 2 12:58 /etc/mysql/debian-start rw-r r - 1 root root 527 Aug 2 12:58 /etc/mysql/mariadb.cnf drwxr-xr-x 2 root root 4096 Aug 2 14:33 /etc/mysql/mariadb.conf.d rw-r r - 1 root root 5201 Nov 4 12:05 /etc/mysql/my.cnf Change file /etc/apt/sources.list from 10.3 to 10.5 apt-get update apt-get upgrade mariadb-server Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be REMOVED: galera-3 mariadb-client-10.3 mariadb-client-core-10.3 mariadb-server-10.3 mariadb-server-core-10.3 The following NEW packages will be installed: galera-4 mariadb-client-10.5 mariadb-client-core-10.5 mariadb-server-10.5 mariadb-server-core-10.5 The following packages have been kept back: linux-image-amd64 The following packages will be upgraded: base-files bind9-host debconf debconf-i18n distro-info-data krb5-locales libbind9-161 libdns-export1104 libdns1104 libgssapi-krb5-2 libisc-export1100 libisc1100 libisccc161 libisccfg163 libk5crypto3 libkrb5-3 libkrb5support0 liblwres161 libmariadb3 mariadb-common mariadb-server mysql-common python3-debconf tzdata 24 upgraded, 5 newly installed, 5 to remove and 1 not upgraded. Need to get 31.6 MB of archives. After this operation, 15.4 MB of additional disk space will be used. ls -ald /etc/mysql/* drwxr-xr-x 2 root root 4096 Nov 4 12:05 /etc/mysql/conf.d rw ------ 1 root root 333 Nov 4 12:05 /etc/mysql/debian.cnf -rwxr-xr-x 1 root root 1731 Aug 3 10:29 /etc/mysql/debian-start rw-r r - 1 root root 1126 Aug 3 10:29 /etc/mysql/mariadb.cnf drwxr-xr-x 3 root root 4096 Nov 4 12:09 /etc/mysql/mariadb.conf.d lrwxrwxrwx 1 root root 24 Nov 4 12:09 /etc/mysql/my.cnf -> /etc/alternatives/my.cnf --> My changes in my.cnf where gone!
            faust Faustin Lammler added a comment - - edited

            Thanks oli, I have tested and I can confirm the same behavior in containers (Debian10 and Ubuntu20.04).

            I did some research and it seems that this was introduced by the following commit:
            https://github.com/MariaDB/server/commit/a3448b2395a4f7aff62f8bab70797a6f928d626f
            imported from:
            https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/13e3a7903e5c72e70c02b98a3e51a6de70b9b6ef

            I am not sure at this point how we could handle this because it seems that there are various options and I'll wait for otto to comment.

            Note that the upgrade from Debian 10.3 version (where /etc/mysql/my.cnf is already a symlink to /etc/alternatives/my.cnf) to MDBF 10.5 version seems to correctly handle this (at least the user receive a warning):

            Setting up mariadb-common (1:10.5.12+maria~buster) ...
             
            Configuration file '/etc/mysql/mariadb.cnf'
             ==> Modified (by you or by a script) since installation.
             ==> Package distributor has shipped an updated version.
               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.
            *** mariadb.cnf (Y/I/N/O/D/Z) [default=N] ? D
            

            Anyway this behavior is not only problematic for users (potential loose of previous configurations), it also does not respect the Debian policy.
            From https://www.debian.org/doc/debian-policy/ch-files.html#behavior:

            > Configuration file handling must conform to the following behavior:
            > - local changes must be preserved during a package upgrade, and
            > - configuration files must be preserved when the package is removed, and only deleted when the package is purged.
            >
            > Obsolete configuration files without local changes should be removed by the package during upgrade.

            faust Faustin Lammler added a comment - - edited Thanks oli , I have tested and I can confirm the same behavior in containers (Debian10 and Ubuntu20.04). I did some research and it seems that this was introduced by the following commit: https://github.com/MariaDB/server/commit/a3448b2395a4f7aff62f8bab70797a6f928d626f imported from: https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/13e3a7903e5c72e70c02b98a3e51a6de70b9b6ef I am not sure at this point how we could handle this because it seems that there are various options and I'll wait for otto to comment. Note that the upgrade from Debian 10.3 version (where /etc/mysql/my.cnf is already a symlink to /etc/alternatives/my.cnf) to MDBF 10.5 version seems to correctly handle this (at least the user receive a warning): Setting up mariadb-common (1:10.5.12+maria~buster) ...   Configuration file '/etc/mysql/mariadb.cnf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. 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. *** mariadb.cnf (Y/I/N/O/D/Z) [default=N] ? D Anyway this behavior is not only problematic for users (potential loose of previous configurations), it also does not respect the Debian policy. From https://www.debian.org/doc/debian-policy/ch-files.html#behavior: > Configuration file handling must conform to the following behavior: > - local changes must be preserved during a package upgrade, and > - configuration files must be preserved when the package is removed, and only deleted when the package is purged. > > Obsolete configuration files without local changes should be removed by the package during upgrade.
            danblack Daniel Black added a comment -

            I agree that a user's config change should be preserved. I don't want the crazy selection of Debian specific defaults partially fixed in 7c2079f600ba to propagate on upgrade. Moving a config file if its content doesn't match a set of hashes (corresponding to old defaults) is my preference at the moment.

            danblack Daniel Black added a comment - I agree that a user's config change should be preserved. I don't want the crazy selection of Debian specific defaults partially fixed in 7c2079f600ba to propagate on upgrade. Moving a config file if its content doesn't match a set of hashes (corresponding to old defaults) is my preference at the moment.

            Yes, naturally the config should be preserved. This is just a bug that is happening now. Thanks oli for supplying exact steps to reproduce. I will look into this now.

            otto Otto Kekäläinen added a comment - Yes, naturally the config should be preserved. This is just a bug that is happening now. Thanks oli for supplying exact steps to reproduce. I will look into this now.

            I have potentially found the root cause and have a fix in https://github.com/MariaDB/server/pull/1944, but I have not yet tested this. I will do that probably in the weekend.

            otto Otto Kekäläinen added a comment - I have potentially found the root cause and have a fix in https://github.com/MariaDB/server/pull/1944 , but I have not yet tested this. I will do that probably in the weekend.

            People

              otto Otto Kekäläinen
              oli Oli Sennhauser
              Votes:
              2 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.