Bug 999589

Summary:	Changes to make MySQL vs. MariaDB less confusing
Product:	[Fedora] Fedora	Reporter:	Honza Horak <hhorak>
Component:	mariadb	Assignee:	Honza Horak <hhorak>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	hhorak
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-08-30 06:10:50 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Honza Horak 2013-08-21 16:03:12 UTC

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 14:05:52 UTC

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 06:10:50 UTC

Changes above applied to F20/F21.