RE: mysql cookbook flushes /etc/my.cnf, breaks local socket access

Yet another alternative fix is to create a symbolic link for the socket file, from /var/run/mysql-default/mysql.sock to the default location /var/lib/mysql/mysql.sock (CentOS location - might be different in other distros). This, too, will only work with a single instance. I don’t consider this a problem, since that’s the nature of default values.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: Nico Kadel-Garcia nkadel@skyhookwireless.com
Sent: Thursday 19th March 2015 9:41
To: chef@lists.opscode.com
Subject: [chef] mysql cookbook flushes /etc/my.cnf, breaks local socket access

I was just working with the latest ‘mysql’ cookbook, and note that it is now insisting on creating individual mysql instances. That’s fine, but it’s relatively new behavior for those of us who used older major revisions of the cookbook. And one notable result is that it now deletes, and insists on deleting, /etc/my.cnf.

That it breaks local access is documented in the README.md, but how to restore or use socket based access is not. I’ve done a pull request some suggested updates to the README.md at https://github.com/chef-cookbooks/mysql/issues/314, and put in a ticket there. Basically, you have to read /etc/mysql-default/my.cnf or whatever new config file and use the socket setting from there.

The alternative fix, which I hesitate to put in a README.md, is to put a symlink from the single instance “/etc/mysql-default/my.cnf” to “/etc/my.cnf”. That’s a bit nasty, and I’d only use it on hosts with only one MySQL instance. But it works quite well.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

PID location is a configuration option, and I’m aware of some people who prefer to put it in all sorts of odd places to keep it out of /var/lib/mysql content mirroring setups. Coupled with anything locally configured in /etc/mysql-default/conf.d/, just dropping individual symlinks rather than restoring the old “/etc/my.cnf for everyone” behavior seems asking for trouble.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

From: Kevin Keane Subscription [mailto:subscription@kkeane.com]
Sent: Thursday, March 19, 2015 5:30 PM
To: chef@lists.opscode.com
Subject: [chef] RE: mysql cookbook flushes /etc/my.cnf, breaks local socket access

Yet another alternative fix is to create a symbolic link for the socket file, from /var/run/mysql-default/mysql.sock to the default location /var/lib/mysql/mysql.sock (CentOS location - might be different in other distros). This, too, will only work with a single instance. I don’t consider this a problem, since that’s the nature of default values.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: Nico Kadel-Garcia <nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com>
Sent: Thursday 19th March 2015 9:41
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] mysql cookbook flushes /etc/my.cnf, breaks local socket access

I was just working with the latest ‘mysql’ cookbook, and note that it is now insisting on creating individual mysql instances. That’s fine, but it’s relatively new behavior for those of us who used older major revisions of the cookbook. And one notable result is that it now deletes, and insists on deleting, /etc/my.cnf.

That it breaks local access is documented in the README.md, but how to restore or use socket based access is not. I’ve done a pull request some suggested updates to the README.md at https://github.com/chef-cookbooks/mysql/issues/314, and put in a ticket there. Basically, you have to read /etc/mysql-default/my.cnf or whatever new config file and use the socket setting from there.

The alternative fix, which I hesitate to put in a README.md, is to put a symlink from the single instance “/etc/mysql-default/my.cnf” to “/etc/my.cnf”. That’s a bit nasty, and I’d only use it on hosts with only one MySQL instance. But it works quite well.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

How does one migrate from the old attribute driven mysql cookbook to the
new LWRP version?

On Mon, Mar 23, 2015 at 9:39 AM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

PID location is a configuration option, and I’m aware of some people who
prefer to put it in all sorts of odd places to keep it out of
/var/lib/mysql content mirroring setups. Coupled with anything locally
configured in /etc/mysql-default/conf.d/, just dropping individual symlinks
rather than restoring the old “/etc/my.cnf for everyone” behavior seems
asking for trouble.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Kevin Keane Subscription [mailto:subscription@kkeane.com]
Sent: Thursday, March 19, 2015 5:30 PM
To: chef@lists.opscode.com
Subject: [chef] RE: mysql cookbook flushes /etc/my.cnf, breaks local
socket access

Yet another alternative fix is to create a symbolic link for the socket
file, from /var/run/mysql-default/mysql.sock to the default location
/var/lib/mysql/mysql.sock (CentOS location - might be different in other
distros). This, too, will only work with a single instance. I don't
consider this a problem, since that's the nature of default values.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: Nico Kadel-Garcia nkadel@skyhookwireless.com
Sent: Thursday 19th March 2015 9:41
To: chef@lists.opscode.com
Subject: [chef] mysql cookbook flushes /etc/my.cnf, breaks local socket
access

I was just working with the latest 'mysql' cookbook, and note that it is now insisting on creating individual mysql instances. That's fine, but it's relatively new behavior for those of us who used older major revisions of the cookbook. And one notable result is that it now deletes, and insists on deleting, /etc/my.cnf.

That it breaks local access is documented in the README.md, but how to restore or use socket based access is not. I've done a pull request some suggested updates to the README.md at Broken local MySQL access notes are unclear · Issue #314 · sous-chefs/mysql · GitHub, and put in a ticket there. Basically, you have to read /etc/mysql-default/my.cnf or whatever new config file and use the socket setting from there.

The alternative fix, which I hesitate to put in a README.md, is to put a symlink from the single instance "/etc/mysql-default/my.cnf" to "/etc/my.cnf". That's a bit nasty, and I'd only use it on hosts with only one MySQL instance. But it works quite well.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

One writes a new wrapper cookbook. I’m afraid that mine is customized for my internal local environment, and I’m reluctant to publish it as is, but I might be able to publish a sanitized version.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

From: Greg Barker [mailto:fletch@fletchowns.net]
Sent: Thursday, March 26, 2015 2:52 AM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: RE: mysql cookbook flushes /etc/my.cnf, breaks local socket access

How does one migrate from the old attribute driven mysql cookbook to the new LWRP version?

On Mon, Mar 23, 2015 at 9:39 AM, Nico Kadel-Garcia <nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com> wrote:
PID location is a configuration option, and I’m aware of some people who prefer to put it in all sorts of odd places to keep it out of /var/lib/mysql content mirroring setups. Coupled with anything locally configured in /etc/mysql-default/conf.d/, just dropping individual symlinks rather than restoring the old “/etc/my.cnf for everyone” behavior seems asking for trouble.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

From: Kevin Keane Subscription [mailto:subscription@kkeane.commailto:subscription@kkeane.com]
Sent: Thursday, March 19, 2015 5:30 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] RE: mysql cookbook flushes /etc/my.cnf, breaks local socket access

Yet another alternative fix is to create a symbolic link for the socket file, from /var/run/mysql-default/mysql.sock to the default location /var/lib/mysql/mysql.sock (CentOS location - might be different in other distros). This, too, will only work with a single instance. I don’t consider this a problem, since that’s the nature of default values.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: Nico Kadel-Garcia <nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com>
Sent: Thursday 19th March 2015 9:41
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] mysql cookbook flushes /etc/my.cnf, breaks local socket access

I was just working with the latest ‘mysql’ cookbook, and note that it is now insisting on creating individual mysql instances. That’s fine, but it’s relatively new behavior for those of us who used older major revisions of the cookbook. And one notable result is that it now deletes, and insists on deleting, /etc/my.cnf.

That it breaks local access is documented in the README.md, but how to restore or use socket based access is not. I’ve done a pull request some suggested updates to the README.md at https://github.com/chef-cookbooks/mysql/issues/314, and put in a ticket there. Basically, you have to read /etc/mysql-default/my.cnf or whatever new config file and use the socket setting from there.

The alternative fix, which I hesitate to put in a README.md, is to put a symlink from the single instance “/etc/mysql-default/my.cnf” to “/etc/my.cnf”. That’s a bit nasty, and I’d only use it on hosts with only one MySQL instance. But it works quite well.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

I've got the wrapper cookbook going already, I'm more wondering about what
happens to the old mysqld service that was installed and is currently
running. Should my wrapper cookbook also be responsible for shutting that
down and disabling it? Then the new mysql-default or whatever service that
is installed just uses the same datadir and takes over from there?

On Thu, Mar 26, 2015 at 2:29 PM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

One writes a new wrapper cookbook. I’m afraid that mine is customized for
my internal local environment, and I’m reluctant to publish it as is, but I
might be able to publish a sanitized version.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Greg Barker [mailto:fletch@fletchowns.net]
Sent: Thursday, March 26, 2015 2:52 AM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: RE: mysql cookbook flushes /etc/my.cnf, breaks
local socket access

How does one migrate from the old attribute driven mysql cookbook to the
new LWRP version?

On Mon, Mar 23, 2015 at 9:39 AM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

PID location is a configuration option, and I’m aware of some people who
prefer to put it in all sorts of odd places to keep it out of
/var/lib/mysql content mirroring setups. Coupled with anything locally
configured in /etc/mysql-default/conf.d/, just dropping individual symlinks
rather than restoring the old “/etc/my.cnf for everyone” behavior seems
asking for trouble.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Kevin Keane Subscription [mailto:subscription@kkeane.com]
Sent: Thursday, March 19, 2015 5:30 PM
To: chef@lists.opscode.com
Subject: [chef] RE: mysql cookbook flushes /etc/my.cnf, breaks local
socket access

Yet another alternative fix is to create a symbolic link for the socket
file, from /var/run/mysql-default/mysql.sock to the default location
/var/lib/mysql/mysql.sock (CentOS location - might be different in other
distros). This, too, will only work with a single instance. I don't
consider this a problem, since that's the nature of default values.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: Nico Kadel-Garcia nkadel@skyhookwireless.com
Sent: Thursday 19th March 2015 9:41
To: chef@lists.opscode.com
Subject: [chef] mysql cookbook flushes /etc/my.cnf, breaks local socket
access

I was just working with the latest 'mysql' cookbook, and note that it is now insisting on creating individual mysql instances. That's fine, but it's relatively new behavior for those of us who used older major revisions of the cookbook. And one notable result is that it now deletes, and insists on deleting, /etc/my.cnf.

That it breaks local access is documented in the README.md, but how to restore or use socket based access is not. I've done a pull request some suggested updates to the README.md at Broken local MySQL access notes are unclear · Issue #314 · sous-chefs/mysql · GitHub, and put in a ticket there. Basically, you have to read /etc/mysql-default/my.cnf or whatever new config file and use the socket setting from there.

The alternative fix, which I hesitate to put in a README.md, is to put a symlink from the single instance "/etc/mysql-default/my.cnf" to "/etc/my.cnf". That's a bit nasty, and I'd only use it on hosts with only one MySQL instance. But it works quite well.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

mysql_service resources takes care of shutting down the "system" mysql service.
Just point it at the data_dir and you should be good to go.

-s

On Thu, Mar 26, 2015 at 8:19 PM, Greg Barker fletch@fletchowns.net wrote:

I've got the wrapper cookbook going already, I'm more wondering about what
happens to the old mysqld service that was installed and is currently
running. Should my wrapper cookbook also be responsible for shutting that
down and disabling it? Then the new mysql-default or whatever service that
is installed just uses the same datadir and takes over from there?

On Thu, Mar 26, 2015 at 2:29 PM, Nico Kadel-Garcia
nkadel@skyhookwireless.com wrote:

One writes a new wrapper cookbook. I’m afraid that mine is customized for
my internal local environment, and I’m reluctant to publish it as is, but I
might be able to publish a sanitized version.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Greg Barker [mailto:fletch@fletchowns.net]
Sent: Thursday, March 26, 2015 2:52 AM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: RE: mysql cookbook flushes /etc/my.cnf, breaks
local socket access

How does one migrate from the old attribute driven mysql cookbook to the
new LWRP version?

On Mon, Mar 23, 2015 at 9:39 AM, Nico Kadel-Garcia
nkadel@skyhookwireless.com wrote:

PID location is a configuration option, and I’m aware of some people who
prefer to put it in all sorts of odd places to keep it out of /var/lib/mysql
content mirroring setups. Coupled with anything locally configured in
/etc/mysql-default/conf.d/, just dropping individual symlinks rather than
restoring the old “/etc/my.cnf for everyone” behavior seems asking for
trouble.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Kevin Keane Subscription [mailto:subscription@kkeane.com]
Sent: Thursday, March 19, 2015 5:30 PM
To: chef@lists.opscode.com
Subject: [chef] RE: mysql cookbook flushes /etc/my.cnf, breaks local
socket access

Yet another alternative fix is to create a symbolic link for the socket
file, from /var/run/mysql-default/mysql.sock to the default location
/var/lib/mysql/mysql.sock (CentOS location - might be different in other
distros). This, too, will only work with a single instance. I don't consider
this a problem, since that's the nature of default values.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: Nico Kadel-Garcia nkadel@skyhookwireless.com
Sent: Thursday 19th March 2015 9:41
To: chef@lists.opscode.com
Subject: [chef] mysql cookbook flushes /etc/my.cnf, breaks local socket
access

I was just working with the latest 'mysql' cookbook, and note that it is
now insisting on creating individual mysql instances. That's fine, but it's
relatively new behavior for those of us who used older major revisions of
the cookbook. And one notable result is that it now deletes, and insists on
deleting, /etc/my.cnf.

That it breaks local access is documented in the README.md, but how to
restore or use socket based access is not. I've done a pull request some
suggested updates to the README.md at
Broken local MySQL access notes are unclear · Issue #314 · sous-chefs/mysql · GitHub, and put in a ticket
there. Basically, you have to read /etc/mysql-default/my.cnf or whatever new
config file and use the socket setting from there.

The alternative fix, which I hesitate to put in a README.md, is to put a
symlink from the single instance "/etc/mysql-default/my.cnf" to
"/etc/my.cnf". That's a bit nasty, and I'd only use it on hosts with only
one MySQL instance. But it works quite well.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

Not that this can only work if your MySQL service is where the chef recipes expect to find it. Since different local MySQL setups may use different init script names, for all sorts of reasons, you'll still have to stop them yourself. (I just ran into this!)

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

-----Original Message-----
From: Sean OMeara [mailto:someara@chef.io]
Sent: Friday, March 27, 2015 10:18 AM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: RE: Re: RE: RE: mysql cookbook flushes /etc/my.cnf,
breaks local socket access

mysql_service resources takes care of shutting down the "system" mysql service.
Just point it at the data_dir and you should be good to go.

-s

On Thu, Mar 26, 2015 at 8:19 PM, Greg Barker fletch@fletchowns.net wrote:

I've got the wrapper cookbook going already, I'm more wondering about
what happens to the old mysqld service that was installed and is
currently running. Should my wrapper cookbook also be responsible for
shutting that down and disabling it? Then the new mysql-default or
whatever service that is installed just uses the same datadir and takes over
from there?

On Thu, Mar 26, 2015 at 2:29 PM, Nico Kadel-Garcia
nkadel@skyhookwireless.com wrote:

One writes a new wrapper cookbook. I’m afraid that mine is customized
for my internal local environment, and I’m reluctant to publish it as
is, but I might be able to publish a sanitized version.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Greg Barker [mailto:fletch@fletchowns.net]
Sent: Thursday, March 26, 2015 2:52 AM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: RE: mysql cookbook flushes /etc/my.cnf,
breaks local socket access

How does one migrate from the old attribute driven mysql cookbook to
the new LWRP version?

On Mon, Mar 23, 2015 at 9:39 AM, Nico Kadel-Garcia
nkadel@skyhookwireless.com wrote:

PID location is a configuration option, and I’m aware of some people
who prefer to put it in all sorts of odd places to keep it out of
/var/lib/mysql content mirroring setups. Coupled with anything
locally configured in /etc/mysql-default/conf.d/, just dropping
individual symlinks rather than restoring the old “/etc/my.cnf for
everyone” behavior seems asking for trouble.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Kevin Keane Subscription [mailto:subscription@kkeane.com]
Sent: Thursday, March 19, 2015 5:30 PM
To: chef@lists.opscode.com
Subject: [chef] RE: mysql cookbook flushes /etc/my.cnf, breaks local
socket access

Yet another alternative fix is to create a symbolic link for the
socket file, from /var/run/mysql-default/mysql.sock to the default
location /var/lib/mysql/mysql.sock (CentOS location - might be
different in other distros). This, too, will only work with a single
instance. I don't consider this a problem, since that's the nature of default
values.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: Nico Kadel-Garcia nkadel@skyhookwireless.com
Sent: Thursday 19th March 2015 9:41
To: chef@lists.opscode.com
Subject: [chef] mysql cookbook flushes /etc/my.cnf, breaks local
socket access

I was just working with the latest 'mysql' cookbook, and note that it
is now insisting on creating individual mysql instances. That's fine,
but it's relatively new behavior for those of us who used older major
revisions of the cookbook. And one notable result is that it now
deletes, and insists on deleting, /etc/my.cnf.

That it breaks local access is documented in the README.md, but how
to restore or use socket based access is not. I've done a pull
request some suggested updates to the README.md at
Broken local MySQL access notes are unclear · Issue #314 · sous-chefs/mysql · GitHub, and put in a
ticket there. Basically, you have to read /etc/mysql-default/my.cnf
or whatever new config file and use the socket setting from there.

The alternative fix, which I hesitate to put in a README.md, is to
put a symlink from the single instance "/etc/mysql-default/my.cnf" to
"/etc/my.cnf". That's a bit nasty, and I'd only use it on hosts with
only one MySQL instance. But it works quite well.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

Worked great! Thank you Sean and Nico!

On Tue, Mar 31, 2015 at 8:27 AM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

Not that this can only work if your MySQL service is where the chef
recipes expect to find it. Since different local MySQL setups may use
different init script names, for all sorts of reasons, you'll still have to
stop them yourself. (I just ran into this!)

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

-----Original Message-----
From: Sean OMeara [mailto:someara@chef.io]
Sent: Friday, March 27, 2015 10:18 AM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: RE: Re: RE: RE: mysql cookbook flushes
/etc/my.cnf,
breaks local socket access

mysql_service resources takes care of shutting down the "system" mysql
service.
Just point it at the data_dir and you should be good to go.

-s

On Thu, Mar 26, 2015 at 8:19 PM, Greg Barker fletch@fletchowns.net
wrote:

I've got the wrapper cookbook going already, I'm more wondering about
what happens to the old mysqld service that was installed and is
currently running. Should my wrapper cookbook also be responsible for
shutting that down and disabling it? Then the new mysql-default or
whatever service that is installed just uses the same datadir and
takes over
from there?

On Thu, Mar 26, 2015 at 2:29 PM, Nico Kadel-Garcia
nkadel@skyhookwireless.com wrote:

One writes a new wrapper cookbook. I’m afraid that mine is customized
for my internal local environment, and I’m reluctant to publish it as
is, but I might be able to publish a sanitized version.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Greg Barker [mailto:fletch@fletchowns.net]
Sent: Thursday, March 26, 2015 2:52 AM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: RE: mysql cookbook flushes /etc/my.cnf,
breaks local socket access

How does one migrate from the old attribute driven mysql cookbook to
the new LWRP version?

On Mon, Mar 23, 2015 at 9:39 AM, Nico Kadel-Garcia
nkadel@skyhookwireless.com wrote:

PID location is a configuration option, and I’m aware of some people
who prefer to put it in all sorts of odd places to keep it out of
/var/lib/mysql content mirroring setups. Coupled with anything
locally configured in /etc/mysql-default/conf.d/, just dropping
individual symlinks rather than restoring the old “/etc/my.cnf for
everyone” behavior seems asking for trouble.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Kevin Keane Subscription [mailto:subscription@kkeane.com]
Sent: Thursday, March 19, 2015 5:30 PM
To: chef@lists.opscode.com
Subject: [chef] RE: mysql cookbook flushes /etc/my.cnf, breaks local
socket access

Yet another alternative fix is to create a symbolic link for the
socket file, from /var/run/mysql-default/mysql.sock to the default
location /var/lib/mysql/mysql.sock (CentOS location - might be
different in other distros). This, too, will only work with a single
instance. I don't consider this a problem, since that's the nature of
default
values.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: Nico Kadel-Garcia nkadel@skyhookwireless.com
Sent: Thursday 19th March 2015 9:41
To: chef@lists.opscode.com
Subject: [chef] mysql cookbook flushes /etc/my.cnf, breaks local
socket access

I was just working with the latest 'mysql' cookbook, and note that it
is now insisting on creating individual mysql instances. That's fine,
but it's relatively new behavior for those of us who used older major
revisions of the cookbook. And one notable result is that it now
deletes, and insists on deleting, /etc/my.cnf.

That it breaks local access is documented in the README.md, but how
to restore or use socket based access is not. I've done a pull
request some suggested updates to the README.md at
Broken local MySQL access notes are unclear · Issue #314 · sous-chefs/mysql · GitHub, and put in a
ticket there. Basically, you have to read /etc/mysql-default/my.cnf
or whatever new config file and use the socket setting from there.

The alternative fix, which I hesitate to put in a README.md, is to
put a symlink from the single instance "/etc/mysql-default/my.cnf" to
"/etc/my.cnf". That's a bit nasty, and I'd only use it on hosts with
only one MySQL instance. But it works quite well.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com