Bug 999589 - Changes to make MySQL vs. MariaDB less confusing
Changes to make MySQL vs. MariaDB less confusing
Product: Fedora
Classification: Fedora
Component: mariadb (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Honza Horak
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-08-21 12:03 EDT by Honza Horak
Modified: 2013-09-02 12:00 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-30 02:10:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1003115 None None None Never

  None (edit)
Description Honza Horak 2013-08-21 12:03:12 EDT
Description of problem:
There is a confusion in using mariadb names somewhere and mysql somewhere else. For example package is named mariadb, but service file, daemon binary and a log file is called mysqld. On the other hand, some files like those in tmpfiles.d use mariadb. This is a proposal how to solve these confusions.

Let's use a simple rule when not sure -- what comes from upstream and is called mysql(d), it will be still called mysql*. What we provide downstream (systemd service file, log file), it will use mariadb, however we'll provide mysql alternatives for compatibility reasons when necessary.

Concrete steps (something was already done):
1) mariadb will start using /var/log/mariadb/mariadb.log by default since F20. It will solve problems with permissions when the log file is missing.
mariadb.service will be the main service file, mysqld.service will be a symlink to it (compatibility)

2) both mariadb and mysql will provide mysql-compat-server symbols, which should be used in case we don't care which package will be installed
mysql symbols shouldn't be used and they can be removed in the future (not sooner than F21)

3) mysql user will be created with /sbin/nologin as a login shell (since F20) - done
Comment 1 Honza Horak 2013-08-29 10:05:52 EDT
The above changes can introduce some issues which could be noticed by admins after upgrading to F20 in particular cases:

1) When /etc/my.cnf was edited by admin, it won't be updated by rpm after upgrading to F20 and only /etc/my.cnf.rpmnew file will be created. This will result in logging still into /var/log/mysqld.log.

In order to start to log into /var/log/mariadb/mariadb.log, admins should change log-error settings in /etc/my.cnf manually to /var/log/mariadb/mariadb.log.

2) In case logrotate script was enabled before upgrading (i.e. lines in /etc/logrotate.d/mysqld were un-commented), the logrotate script won't be removed after upgrade to F20 and logrotate will still want to rotate /var/log/mysqld.log file, which won't have to be necessary used for logging after upgrading any more (depending on log-error setting in /etc/my.cnf)

Instead, admins are advised to remove /etc/logrotate.d/mysqld and/or un-comment lines in the newly created logrotate script /etc/logrotate.d/mariadb.

Generally, admins should make sure that the logrotate script uses the same path as it is defined in /etc/my.cnf.
Comment 2 Honza Horak 2013-08-30 02:10:50 EDT
Changes above applied to F20/F21.

Note You need to log in before you can comment on or make changes to this bug.