I solved the problem. Basically, the [EMAIL PROTECTED] mysql wildcards just don't work. However, when I properly add each IP address to the grane (mysql.user) table, everything works.
grant all on mythconverg.* to mythtv@'192.168.100.30' identified by 'mythtv'; Repeat for each FE, including the FE/BE. Thanks for all the feedback. On Sun, August 12, 2007 7:36 am, Lan Barnes wrote: > > On Sun, August 12, 2007 1:06 am, David Campbell wrote: >> Lan Barnes wrote: >>> I have diagnosed this and am convinced it is strictly a mysql >>> configuration problem. >>> >>> I have a mythtv BE/FE one one box in working order. I want to put >>> remote >>> FEs on other machines. I had this working before but reinstalled my >>> myth >>> box. Of course I've forgotten how. >>> >>> I have granted all on mythconverg.* to mythtv at >>> "192.168.1.0/255.255.255.0". I have selected from the mysql.user table >>> and >>> those privileges are in there. >>> >>> I change my database ip in mythsetup from localhost to either the ip >>> addr >>> or the BE's name. myth loses its connection when I do this and gets OK >>> when I change it back to localhost. >>> >>> But here's the interesting thing. Consider the results when I try >>> connecting with mysql from three machines: >>> >>> Connection command line was the same from each test host: >>> >>> mysql -h xena -u mythtv -p mythconverg >>> >>> 1. From the myth FE/BE (xena) newly upgraded: failure to connect to >>> 'localhost' >>> >>> 2. from my laptop (gypsy) never configured to be a remote FE: failure >>> to >>> connect to 'gypsy' >>> >>> 3. from a workstation previously successfully configured to be a remote >>> FE >>> to the old mythtv installation: success! >>> >>> I've compared the /etc/my.cnf from the successful machine and the >>> others. >>> No difference. Also, nothing special in the environment variables on >>> the >>> working machine. >>> >>> So I'm thinking, there is some configuration on the client machine that >>> makes this connection possible over tcp/ip, even if the client is on >>> the >>> same machine as the backend. >>> >>> OR something broke in mysql between mythdora 3.2 and 4.0, which is >>> unlikely because the mythdora mailing list would be awash in >>> complaints, >>> which it isn't. >>> >>> Does anyone know what I need to do to make the FE/BE mysql see itself >>> over >>> tcp/ip? >> >> what is thhe out put of >> >> ps auxww | grep mysql >> > > [EMAIL PROTECTED] ~]$ ps auxww | grep mysql > root 2358 0.0 0.2 4484 1196 ? S Aug11 0:00 /bin/sh > /usr/bin/mysqld_safe --defaults-file=/etc/my.cnf > --pid-file=/var/run/mysqld/mysqld.pid --log-error=/var/log/mysqld.log > mysql 2394 0.1 4.7 139976 24384 ? Sl Aug11 0:40 > /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/usr > --datadir=/var/lib/mysql --user=mysql > --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking > --socket=/var/lib/mysql/mysql.sock > lbarnes 8339 0.0 0.1 3884 664 pts/0 R+ 07:32 0:00 grep > mysql > > >> and >> >> netstat -an | grep 3306 >> > > tcp 0 0 0.0.0.0:3306 0.0.0.0:* > LISTEN >> Have you got port = defined in my.cnf? >> > > [EMAIL PROTECTED] ~]$ cat /etc/my.cnf > [mysqld] > datadir=/var/lib/mysql > socket=/var/lib/mysql/mysql.sock > # Default to using old password format for compatibility with mysql 3.x > # clients (those using the mysqlclient10 compatibility package). > old_passwords=1 > > [mysql.server] > user=mysql > basedir=/var/lib > > [mysqld_safe] > log-error=/var/log/mysqld.log > pid-file=/var/run/mysqld/mysqld.pid > > > >> Dave >> >> > -- > Lan Barnes > > SCM Analyst Linux Guy > Tcl/Tk Enthusiast Biodiesel Brewer > > _______________________________________________ > mythtv-users mailing list > [EMAIL PROTECTED] > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users > -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- KPLUG-List@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
