[mythtv-users] Mythtv mysql question

[Michael T. Dean]

On 03/28/2008 12:50 PM, Norm wrote:
> I can never get mythv at % to work for me and whenever I add a front-end
> or boot mythbuntu I have to go edit the privileges for that IP address.
>
> Why does it not work in mysql with the user mythtv and the host as % ?
> Any suggestions as to what I'm doing wrong?

http://dev.mysql.com/doc/refman/5.0/en/access-denied.html

Mike

Perhaps:

If the following error occurs when you try to connect from a host other
than the one on which the MySQL server is running, it means that there
is no row in the user table with a Host value that matches the client host:

Host ... is not allowed to connect to this MySQL server

You can fix this by setting up an account for the combination of client
hostname and username that you are using when trying to connect.

If you do not know the IP number or hostname of the machine from which
you are connecting, you should put a row with '%' as the Host column
value in the user table. After trying to connect from the client
machine, use a SELECT USER() query to see how you really did connect.
(Then change the '%' in the user table row to the actual hostname that
shows up in the log. Otherwise, your system is left insecure because it
allows connections from any host for the given username.)

On Linux, another reason that this error might occur is that you are
using a binary MySQL version that is compiled with a different version
of the glibc library than the one you are using. In this case, you
should either upgrade your operating system or glibc, or download a
source distribution of MySQL version and compile it yourself. A source
RPM is normally trivial to compile and install, so this is not a big
problem.

Or:

If you cannot figure out why you get Access denied, remove from the user
table all entries that have Host values containing wildcards (entries
that contain “%” or “_”). A very common error is to insert a new entry
with Host='%' and User='some_user', thinking that this allows you to
specify localhost to connect from the same machine. The reason that this
does not work is that the default privileges include an entry with
Host='localhost' and User=''. Because that entry has a Host value
'localhost' that is more specific than '%', it is used in preference to
the new entry when connecting from localhost! The correct procedure is
to insert a second entry with Host='localhost' and User='some_user', or
to delete the entry with Host='localhost' and User=''. After deleting
the entry, remember to issue a FLUSH PRIVILEGES statement to reload the
grant tables.