/var/lib/mysql/mysql.passwd no longer exist

IS this with the trusty MySQL or precise or both?

Checking the diff, the mysql.passwd file should be getting created, I will deploy the latest trusty to validate this

I noticed this in trusty charm: lp:charms/trusty/mysql

mysql.passwd is created fine but then it's wiped when db relations joins.

Also see related LP1423187

Oh, bother that's a problem.

On Wed Feb 18 2015 at 10:20:47 AM Jacek Nykis <email address hidden>
wrote:

> Also see related LP1423187
>
> --
> You received this bug notification because you are subscribed to mysql
> in Juju Charms Collection.
> Matching subscriptions: MySQL-Charm
> https://bugs.launchpad.net/bugs/1423153
>
> Title:
> /var/lib/mysql/mysql.passwd no longer exist
>
> Status in mysql package in Juju Charms Collection:
> New
>
> Bug description:
> The mysql charm changed the way root password is stored without
> providing backwards compatibility.
> Up until recently we always had root password available in
> /var/lib/mysql/mysql.passwd file, now it seems to be in the peer relation.
>
> I am pretty sure this problem was introduced in revision 137
>
> There are 2 problems with this change
> 1. Many scripts, wiki pages and users (myself included) depended on
> /var/lib/mysql/mysql.passwd. Removing it without notice causes confusion
> 2. With peer relation there is no easy way to retrieve the password from
> the unit itself. One use case is a sysadmin who needs to check database
> structure. It used to be possible to run " mysql -uroot -p`cat
> /var/lib/mysql/mysql.passwd`". Now the password can be retrieved using
> multiple juju run commands or by setting up environment on the unit and
> running relation-get but none of this methods are trivial
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charms/+source/mysql/+bug/
> 1423153/+subscriptions
>

The issue is that the MySQL Helper integrated a few commits ago switches to using peer storage as soon as the peer relation is up.

This results in the mysql.passwd file being removed from the filesystem - any subsequent config-changed hook execution fails as it tries to read the passwd file from disk.

Agreed, this is what I mentioned in my original bug report as well.

Unless juju grows easy way to retrieve the password from the unit itself I think move to the peer relation should be reverted. This unannounced change already caused problems to us.

Jacek

I agree with most of your comments - but I would comment that the use of /var/lib/mysql/mysql.passwd is internal to the charm so we should ensure that other charms don't depend on this file if that is the case.

I notice this is marked "Fix Released" but I can't determine the nature of the fix; when deploying mysql on the serverstack environment using the openstack-charm-testing framework, the mysql root password wasn't stored in the usual /var/lib/mysql/mysql.passwd location, I couldn't find it in relations, and all the online documentation I could find still references that specific file.

What is the nature of the fix that was released? Where should this fix be available? (e.g., should I have expected the openstack-charm-testing environment to have picked up this fix automatically?)

Thanks

In case anyone else faces this, my issue was the juju-deployer local cached charms; removing the series/charm cached directory structure allowed juju-deployer to grab a new version with the fix, that uses /var/lib/mysql/mysql.passwd again.

Thanks

According to the merge date this should have been shipped in 15.04

Doesn't look like it's working. I've just deployed a mysql charm and mysql.passwd has been removed from /var/lib/charm/${SERVICE_NAME}/mysql.passwd.