MYSQL server, access denied

[Weidbrewer]

unutbu - I found the folders where you said they were, so that worked out. I realized that what I was looking for was a text file version of that...but now I remember that I got that through a back-up utility and is only needed for a certain set of situations...bottom line - I think I've got what I need as far as that goes now. Thanks!


DaithiF - On the master backend/frontend, things now seem to be working as they should. Mission accomplished there. However, I have three remote frontends that had all been working fine on the old system that are not able to connect now. All of them had been set up with an ip address (192.168.1.47) instead of a server name, and that had been working. The IP address has not changed at all, nor has the user name/password information.

Additionally, I was looking at the mysql.txt of the old (working) partition (I have it in a backup folder on this side, and the entire file consisted of:

DBHostName=<host name here>
DBUserName=mythtv
DBName=mythtv
DBPassword=<password here>

The one on this partition is:

DBHostName=localhost

# By default, Myth tries to ping the DB host to see if it exists.
# If your DB host or network doesn't accept pings, set this to no:
#
DBHostPing=no

DBUserName=mythtv
DBPassword=<passowrd here>
DBName=mythtv
DBType=QMYSQL3

# Set the following if you want to use something other than this
# machine's real hostname for is....etc, etc, etc....

I realize that the majority of that is just commented out info, but for giggles, I created a back-up of this partition's file and then edited it to be the same as the other...still no luck.

So, summary:
Masterbackend: groovy
Remote frontends: No settings changed, but they cannot connect.



(I appreciated everyone's help, BTW.)

[DaithiF]

Ok, good. For the remote frontends, theres likely 2 things you'll need to check/change
1. mysql may not be listening on the network for connections (by default a new install DOES NOT listen on the network, only on the local host). Therefore any connection attempts from remote frontends will fail.
To tell mysql to listen on the network, edit /etc/mysql/my.cnf, find the line bind-address = 127.0.0.1 and comment it out by prepending the line with a # character
you'll then need to restart mysql:

sudo /etc/init.d/mysql restart

2. the mythtv username that the frontends will be connecting from will be connecting from their hosts, rather than from localhost. So the mythtv@localhost user that you set up won't be enough to grant them access. You could add entries for specific IPs, ie. mythtv@xx.xx.xx.xx, or specific hostnames, or you can use the blanket mythtv@'%' wildcard to match any servers. So decide which you want, create the required user entries like you did before, grant them the same privileges, and again restart the mysql server.

fingers crossed.

[Weidbrewer]

Hmmm...the second one is one that I definitely didn't have to do before (like I said, I haven't touched the login information on the frontends - they're still set to what they were, and it was a working configuration.) The first one seems vaguely familiar, so I will give that a whirl and see what happens from there. After that, I'll move on to step two if need be.

Thanks for the input.

[DaithiF]

Hi,
I think maybe you've misunderstood what I was trying to say in #2. Its not about changing the details that the frontends log in with, those details can stay the same. Its about telling the server that its ok for mythtv@<some computer other than this one> to log in. If your only mythtv login on the server is mythtv@localhost then the only login attempts for mythtv that will succeed are those that come from localhost. If you add mythtv@'%' then mythtv connections from *any* computers will be allowed.

[Weidbrewer]

Yep...that's exactly what happened. (Misunderstanding, that is.) I didn't get a chance to do step one last night anyway, so I will try to get to that after work.

Sweet Jesus...my idiocy here has bumped my posts up to the next level of beans. That's not right...

[Weidbrewer]

Attention Ubuntuians:

DaithiF rocks the Casbah.

That is all.

[Weidbrewer]

Looks like I need to reopen this. For unrelated reasons, I needed to reboot the backend, and it seems to have reverted everything. (At least it can't find the Myth backend any longer, and the MySQL DB is locked back up. Didn't have time to muck with it farther than that.)

Assuming I can just retrace the above steps to get back in business, what do I need to do to not have it overwrite it again?

[DaithiF]

Hi,
a reboot shouldn't have affected any of these settings. only thing i can think of is if your mysql server isn't configured to start on boot.

can you check first if mysql is running on your mythtv server:

sudo /etc/init.d/mysql status

Note that trying to log in to a server that is not running will give an error message like 'access denied', which doesn't make it very obvious that the server just needs to be started.

To configure your system so that mysql starts on boot, do:

sudo update-rc.d mysql defaults

good luck

[Weidbrewer]

Thanks...it was not running, and when I tried to start it, it gave me an error stating that the partition was full...this connected to an issue that I had last week where a download directory had been set incorrectly, and I forgot to delete everything out of there...once I did that and rebooted, smooth sailing again.

[ktritty]

Hello. I have a similar problem, almost the exact in fact. I cannot get anything mysql to work. I am trying to work my way through the steps.

1. stop mysql
2. start it again in a special mode which doesn't require permissions
3. connect and change the root password
4. stop the server & restart it in normal mode

[/code]4. stop the server & restart it in normal mode

sudo /etc/init.d/mysqld stop
sudo /etc/init.d/mysqld restart

The first 3 steps went great.

My problem is step 4. I try to type the stop command (I have tried sudo /etc/init.d/mysql stop AND sudo /etc/init.d/mysqld stop). The former gives [fail] and the latter gives command not found.

Advice??