Bug 848903

Summary:	Any chance of moving /etc/my.cnf to /etc/mysql/my.cnf?
Product:	[Fedora] Fedora	Reporter:	Daniel Walsh <dwalsh>
Component:	mysql	Assignee:	Tom Lane <tgl>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	hhorak, tgl, thoger
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:	2012-08-20 10:20:47 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 Daniel Walsh 2012-08-16 18:28:04 UTC

Trying to build containes with a shared /etc, having configuration data in the /etc dir, gets very difficult.  If you left a symbolic link from /etc/my.cnf to /etc/mysql/my.cnf, that would give you back wards compatability.

The container code then could bind mount a chroot /etc/mysql over the real /etc/mysql and allow processes within the container to write their config.

Comment 1 Tom Lane 2012-08-19 18:03:27 UTC

Hm, not sure about that.  The scenario that worries me is that somebody edits /etc/my.cnf and his editor moves the symlink to /etc/my.cnf~ and writes a plain file at /etc/my.cnf.  Emacs seems to know enough to not do that, but I don't have a lot of confidence that all other editors do too.

In general, we do not expect mysql-related processes to ever write /etc/my.cnf: it's only meant to be edited by humans.  So I'm not sure exactly what scenario you're trying to cater to?

Comment 2 Daniel Walsh 2012-08-20 10:20:47 UTC

Well as I continued to play with containers, I was able to get mysql to work without having to make this change.  I think we can close this for now.  I am not sure what was complaining about.  If it starts happening in the F18 with containers, we can look at this again.

Currently I have all containers sharing the same /etc/my.cnf.  

Tom, do you know if postgresql will set itself up on the first service start like mysql does?  I am planning on attempting to create/start postgresql within a container.

Comment 3 Tom Lane 2012-08-20 14:30:24 UTC

(In reply to comment #2)
> Tom, do you know if postgresql will set itself up on the first service start
> like mysql does?  I am planning on attempting to create/start postgresql
> within a container.

It will not --- you need to issue an explicit database initialization command first.  Either "service postgresql initdb" or "postgresql-setup initdb" should do in the latest packages; before that you need one or the other depending on how old the package is.

The lack of an auto-initdb on first start is intentional, based on upstream practice and recommendation.  Many years ago, our initscript did have auto-initdb behavior, but then there were some high-profile cases of people losing their databases to it.  (IIRC the typical mechanism was to have the database on an NFS mount that was just a tad slow to come up, so that the mount point looked empty just before initdb was called, and then at some point initdb was overwriting existing catalog files.)  So now we insist on a manual action for that.

Personally I'd make the mysql initscript act the same way for the same reason, if I thought I could get away with it.  But I think mysql users are too used to "it just works!"