Red Hat Bugzilla – Bug 848903
Any chance of moving /etc/my.cnf to /etc/mysql/my.cnf?
Last modified: 2012-08-20 10:30:24 EDT
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.
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?
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.
(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!"