[mythtv-users] DB Backup Issues

[Michael T. Dean]

On 04/23/2012 07:21 AM, Chuck Peters wrote:
> On Mon, Apr 23, 2012 at 6:39 AM, Michael T. Dean
> <mtdean at thirdcontact.com>  wrote:
>> On 04/23/2012 06:22 AM, Chuck Peters wrote:
>>> I was about to upgrade my Ubuntu 10.04 Mythtv backend to .25 and manually
>>> running the mythconverg_backup.pl isn't working. The script says access
>>> denied, but I haven't changed the password and everything else appears to
>>> be working.  The frontends all work, and I had an old file saved from
>>> 2009-03-19 that shows the same mythconverg_backup.pl --verbose command
>>> working.  If I run the backup via mysqldump without the username and host
>>> parameters it seems to work fine.  I am running a bind server with a lan
>>> zone and the error message shows the hostname io.lan rather than the IP,
>>> could this be the cause?
>>>
>>> I would like to get this cleared up before I upgrade the Mythtv. Any
>>> suggestions?
>>>
>> First step I'd recommend is to verify your DB password/connection
>> information in ~/.mythtv/backuprc .
> Yes I did that. At least according to the wiki page the backuprc only
> needs to contain the DBBackupDirectory.  See
> http://www.mythtv.org/wiki/Database_Backup_and_Restore

Right.  That's the case if your config.xml contains correct 
information--but wanted to make sure there were no "overrides" in the 
backuprc.

> And to add another point to hopefully solve this issue, the
> mythconverg_backup.pl works from one of the frontends.

This implies that your MySQL server configuration provides different 
permissions (and/or different passwords) for different "users".  In 
MySQL a "user" is a combination of username, hostname (used to connect) 
and password.  MySQL will always choose the most-restrictive of the user 
definitions when the information matches multiple (i.e. an actual IP 
address or an actual hostname rather than a wildcard definition).  
Though your user table implies that the password for mythtv at localhost is 
identical to the password for mythtv@% (where localhost would be chosen 
in preference to % on the host that's running the database server), it's 
possible that the configuration didn't "take"--i.e. some distros seem to 
have broken MySQL auth so that a GRANT/FLUSH PRIVILEGES doesn't actually 
work on its own--it must be followed by a:

SET PASSWORD FOR 'mythtv'@'localhost' = PASSWORD('mythtv');
SET PASSWORD FOR 'mythtv'@'%' = PASSWORD('mythtv');

Mike