Monday, January 26, 2015

How to fix: ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)

If you have seen the follow message when  trying to shut down MySQL or Percona XTRADB Server and you see the following message:

 ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)

and the process did not shutdown, the problem is not a bug in MySQL or Percona, the problem is that the password stored on disk for that account doesn't match what is stored in the 'mysql.Users' table.

The following is all one line and should fix the problem temporarily.

 echo "update mysql.user set password = PASSWORD('`sudo cat /etc/mysql/debian.cnf | grep password | tail -1 | awk '{print $3}'`') where user = 'debian-sys-maint';flush privileges;" | mysql -uroot -p

The likely cause of this root cause problem is that one of two things:

1. You have moved the '/var/lib/mysql/' directory from one server to another server possibly with rsync/scp with downtime or with Percona's backup tools with out causing down time.

2. You have replication setup and any updates to the 'mysql.Users' table was propagated out to all the slaves.

If you think that the root cause is more like the first case, I would recommend the treatment at the beginning of this post. If your root cause is more like the second case, I would recommend simply synchronizing the 'debian.cnf' file across all the MySQL nodes.

Alternatively, I've seen some people trying to use a combination of settings to not replicate the updates to the 'mysql.Users' table and they seem to have varying success in that approach. Unless you have a need to have different users on each node, I would recommend against this as it does seem to be tricky especially if your using ROW based replication.

Tuesday, January 20, 2015

How to Create Shared Folders with LXC

If you have ever used Shared Folders in either VMWare or Virtual Box,  you might have come to enjoy the ability to access files seemlessly between the Host and the Guest operating systems.

With LXC we can achieve the same thing with a few simple steps.  This method does have some shortcomings that may or not be a show stopper depending on the use case. Personally, I don't like this method but it is handy to know how to do this.

In this example I going going to show how to share a directory between a host and a guest name guest01.

First create the shared folder on the host:

$ mkdir /home/justin/Documents/guest01/

Next, edit the guest's fstab  file to include the following line:

/home/justin/Documents/guest01  /var/lib/lxc/guest01/rootfs/home/justin/Documents/ none bind 0 0  

Next, reboot your container. 

You'll find that you can now share files between your host and guest.

Why I don't like this method

There is two reasons why I do not like this method.  The first problem is that it breaks the isolation the guest and host have to some degree.   One really awesome thing about LXC and the virtualization trend in general is that added layer of security we have by layering our software stack.

The second reason why I do not like this method is that the file ownership and permissions problems that arise because of this solution.   A few other blogs and forum threads recommended using 'chmod -R 7777 ~Documents/guest01' but this is a horrible approach to managing permissions.  This completely clobbers any sane file permissions and allows any user to read and delete those files.

This approach does have it's uses in the right circumstances, like read-only access to a set of files or as a simple way of moving files but please be careful when using this tactic.