[chef] Re: Re: RE: Re: RE: RE: mysql cookbook flushes /etc/my.cnf, breaks local socket access

[Sean OMeara < >]

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 
<
 >
 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
> <
 >
>  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
>>
>> 
 
>>
>>
>>
>>
>>
>> From: Greg Barker 
>> [mailto:
 
>> Sent: Thursday, March 26, 2015 2:52 AM
>> To: 
>> 
 
>> 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
>> <
 >
>>  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
>>
>> 
 
>>
>>
>>
>>
>>
>> From: Kevin Keane Subscription 
>> [mailto:
 
>> Sent: Thursday, March 19, 2015 5:30 PM
>> To: 
>> 
 
>> 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 
>> <
 >
>> Sent: Thursday 19th March 2015 9:41
>> To: 
>> 
 
>> 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
>> 
 
>>
>>
>
>