phpMyAdmin

On 08.12.2011 19:30, Timothy Madden wrote:
> Hello
>
> I have to mysql servers, ver 5.0.77, under a router, and I have ports
> forwarded on the router for both of them.
>
> I can access both of them with `mysql´ command line client.
>
> However with my phpmyadmin installation, ver 3.4.7 on Windows 7 SP1
> 64-bit, Apache/2.2.21 (Win32) PHP/5.3.8, I can access no mysql server,
> included localhost. Simply running `mysql´ on the command line works and
> connects to the localhost server.
>
> My config file is attached. Is there anything I am doing wrong ?
>
> How can I check the user Apache (phpmyadmin) runs with ? Does phpmyadmin
> have a log file ?

I found the cause, my php 5.3.8 uses the new mysqlnd driver (see 'mysql 
client api' in phpinfo() output), which uses 41-bit password hashes. 
However some older versions of mysql (I have 5.0.77) generate 16-bit 
password hashes from GRANT statements or PASSWORD('...') function 
invocations.

However for some strange reason mysql clients seem to be able to connect 
to such servers even if you generate the 41-bit password hash separately 
and use that in your GRANT statement. In my case I just used 
PASSWORD('...') function in a new version of mysql server on my local host.

Could phpmyadmin please detect this (frustrating) problem and output 
some helpful message (instead of 'could not login') like 'You may need 
to check for a 41-bytes password hash in mysql.user table' ?

Thank you,
Timothy Madden

Am 08.12.2011 21:11, schrieb Timothy Madden:
> On 08.12.2011 19:30, Timothy Madden wrote:
>> Hello
>>
>> I have to mysql servers, ver 5.0.77, under a router, and I have ports
>> forwarded on the router for both of them.
>>
>> I can access both of them with `mysql´ command line client.
>>
>> However with my phpmyadmin installation, ver 3.4.7 on Windows 7 SP1
>> 64-bit, Apache/2.2.21 (Win32) PHP/5.3.8, I can access no mysql server,
>> included localhost. Simply running `mysql´ on the command line works and
>> connects to the localhost server.
>>
>> My config file is attached. Is there anything I am doing wrong ?
>>
>> How can I check the user Apache (phpmyadmin) runs with ? Does phpmyadmin
>> have a log file ?
> 
> I found the cause, my php 5.3.8 uses the new mysqlnd driver (see 'mysql 
> client api' in phpinfo() output), which uses 41-bit password hashes. 
> However some older versions of mysql (I have 5.0.77) generate 16-bit 
> password hashes from GRANT statements or PASSWORD('...') function 
> invocations.
> 
> However for some strange reason mysql clients seem to be able to connect 
> to such servers even if you generate the 41-bit password hash separately 
> and use that in your GRANT statement. In my case I just used 
> PASSWORD('...') function in a new version of mysql server on my local host.
> 
> Could phpmyadmin please detect this (frustrating) problem and output 
> some helpful message (instead of 'could not login') like 'You may need 
> to check for a 41-bytes password hash in mysql.user table' ?

it is NOT the job of phpMyAdmin take car that you migrate
your passwords since they are deprecated SINCE YEARS

they are deprecated since 5.0, there was 5.1 between and now
mysql is on 5.5 - a long time to take care of this

On 08.12.2011 22:30, Reindl Harald wrote:
>
>
> Am 08.12.2011 21:11, schrieb Timothy Madden:
>> On 08.12.2011 19:30, Timothy Madden wrote:
[...]
>> I found the cause, my php 5.3.8 uses the new mysqlnd driver (see 'mysql
>> client api' in phpinfo() output), which uses 41-bit password hashes.
>> However some older versions of mysql (I have 5.0.77) generate 16-bit
>> password hashes from GRANT statements or PASSWORD('...') function
>> invocations.
>>
>> However for some strange reason mysql clients seem to be able to connect
>> to such servers even if you generate the 41-bit password hash separately
>> and use that in your GRANT statement. In my case I just used
>> PASSWORD('...') function in a new version of mysql server on my local host.
>>
>> Could phpmyadmin please detect this (frustrating) problem and output
>> some helpful message (instead of 'could not login') like 'You may need
>> to check for a 41-bytes password hash in mysql.user table' ?
>
> it is NOT the job of phpMyAdmin take car that you migrate
> your passwords since they are deprecated SINCE YEARS
>
> they are deprecated since 5.0, there was 5.1 between and now
> mysql is on 5.5 - a long time to take care of this

You may call it "deprecated for years", but I have an up-to-date CentOS 
x64 release 5.7 (Final), and mysql 5.0.77 is the current mysql server 
there. CentOS is an actively maintained Linux distribution with package 
updates every week. I believe there are other distributions too that 
prefer old versions for their packages for stability.

The problem in this case is there is little the user can do about this. 
(s)he only receives 'Can not login' from phpmyadmin, while the CLI 
client works.

phpmyadmin, on the other hand, *can* do something about it, at least it 
can display the warning message from php ...

Thank you,
Timothy Madden

Am 12.12.2011 12:39, schrieb Timothy Madden:
> On 08.12.2011 22:30, Reindl Harald wrote:
>>
>>
>> Am 08.12.2011 21:11, schrieb Timothy Madden:
>>> On 08.12.2011 19:30, Timothy Madden wrote:
> [...]
>>> I found the cause, my php 5.3.8 uses the new mysqlnd driver (see 'mysql
>>> client api' in phpinfo() output), which uses 41-bit password hashes.
>>> However some older versions of mysql (I have 5.0.77) generate 16-bit
>>> password hashes from GRANT statements or PASSWORD('...') function
>>> invocations.
>>>
>>> However for some strange reason mysql clients seem to be able to connect
>>> to such servers even if you generate the 41-bit password hash separately
>>> and use that in your GRANT statement. In my case I just used
>>> PASSWORD('...') function in a new version of mysql server on my local host.
>>>
>>> Could phpmyadmin please detect this (frustrating) problem and output
>>> some helpful message (instead of 'could not login') like 'You may need
>>> to check for a 41-bytes password hash in mysql.user table' ?
>>
>> it is NOT the job of phpMyAdmin take car that you migrate
>> your passwords since they are deprecated SINCE YEARS
>>
>> they are deprecated since 5.0, there was 5.1 between and now
>> mysql is on 5.5 - a long time to take care of this
> 
> You may call it "deprecated for years", but I have an up-to-date CentOS 
> x64 release 5.7 (Final), and mysql 5.0.77 is the current mysql server 
> there. CentOS is an actively maintained Linux distribution with package 
> updates every week. I believe there are other distributions too that 
> prefer old versions for their packages for stability.

and what does this change in the fact that "old_passwords=1" in my.cnf
is deprecated since MySQL 5.0 what you have installed?

Timothy Madden a écrit :
> On 08.12.2011 22:30, Reindl Harald wrote:
>>
>> Am 08.12.2011 21:11, schrieb Timothy Madden:
>>> On 08.12.2011 19:30, Timothy Madden wrote:
> [...]
>>> I found the cause, my php 5.3.8 uses the new mysqlnd driver (see 'mysql
>>> client api' in phpinfo() output), which uses 41-bit password hashes.
>>> However some older versions of mysql (I have 5.0.77) generate 16-bit
>>> password hashes from GRANT statements or PASSWORD('...') function
>>> invocations.
>>>
>>> However for some strange reason mysql clients seem to be able to connect
>>> to such servers even if you generate the 41-bit password hash separately
>>> and use that in your GRANT statement. In my case I just used
>>> PASSWORD('...') function in a new version of mysql server on my local host.
>>>
>>> Could phpmyadmin please detect this (frustrating) problem and output
>>> some helpful message (instead of 'could not login') like 'You may need
>>> to check for a 41-bytes password hash in mysql.user table' ?
>> it is NOT the job of phpMyAdmin take car that you migrate
>> your passwords since they are deprecated SINCE YEARS
>>
>> they are deprecated since 5.0, there was 5.1 between and now
>> mysql is on 5.5 - a long time to take care of this
> 
> You may call it "deprecated for years", but I have an up-to-date CentOS 
> x64 release 5.7 (Final), and mysql 5.0.77 is the current mysql server 
> there. CentOS is an actively maintained Linux distribution with package 
> updates every week. I believe there are other distributions too that 
> prefer old versions for their packages for stability.
> 
> The problem in this case is there is little the user can do about this. 
> (s)he only receives 'Can not login' from phpmyadmin, while the CLI 
> client works.
> 
> phpmyadmin, on the other hand, *can* do something about it, at least it 
> can display the warning message from php ...
> 
> Thank you,
> Timothy Madden

You can open a feature request at 
http://sourceforge.net/tracker/?group_id=23067&atid=377411

-- 
Marc Delisle
http://infomarc.info

On Mon, 12 Dec 2011 13:39:20 +0200
Timothy Madden articulated:

> You may call it "deprecated for years", but I have an up-to-date
> CentOS x64 release 5.7 (Final)

"CentOS-6.1 for i386 and x86_64 Architectures" has been released." While
I am a user of CentOS and quite frankly have heard horror stories
regarding their slow acceptance of newer program versions, is is
possible that updating your OS version might ease your problem?

As you are undoubtedly aware, MySQL is currently at "version 5.5.x".
Continued use of such an old version makes no sense at all.

-- 
Jerry ✌
gesbbb@...

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__________________________________________________________________

On 12.12.2011 14:57, Marc Delisle wrote:
> Timothy Madden a écrit :
>> On 08.12.2011 22:30, Reindl Harald wrote:
>>>
>>> Am 08.12.2011 21:11, schrieb Timothy Madden:
>>>> On 08.12.2011 19:30, Timothy Madden wrote:
[...]
>>>>
>>>> Could phpmyadmin please detect this (frustrating) problem and output
>>>> some helpful message (instead of 'could not login') like 'You may need
>>>> to check for a 41-bytes password hash in mysql.user table' ?
>>> it is NOT the job of phpMyAdmin take car that you migrate
>>> your passwords since they are deprecated SINCE YEARS
>>>
>>> they are deprecated since 5.0, there was 5.1 between and now
>>> mysql is on 5.5 - a long time to take care of this
>>
>> You may call it "deprecated for years", but I have an up-to-date CentOS
>> x64 release 5.7 (Final), and mysql 5.0.77 is the current mysql server
>> there. CentOS is an actively maintained Linux distribution with package
>> updates every week. I believe there are other distributions too that
>> prefer old versions for their packages for stability.
>>
>> The problem in this case is there is little the user can do about this.
>> (s)he only receives 'Can not login' from phpmyadmin, while the CLI
>> client works.
>>
>> phpmyadmin, on the other hand, *can* do something about it, at least it
>> can display the warning message from php ...
>>
>> Thank you,
>> Timothy Madden
>
> You can open a feature request at
> http://sourceforge.net/tracker/?group_id=23067&atid=377411

Thank you.
If anyone is interested, here it is: 
https://sourceforge.net/tracker/?func=detail&aid=3459102&group_id=23067&atid=377411

Timothy Madden

On 12.12.2011 13:45, Reindl Harald wrote:
>
>
> Am 12.12.2011 12:39, schrieb Timothy Madden:
>> On 08.12.2011 22:30, Reindl Harald wrote:
>>>
>>>
>>> Am 08.12.2011 21:11, schrieb Timothy Madden:
>>>> On 08.12.2011 19:30, Timothy Madden wrote:
>> [...]
>>>> I found the cause, my php 5.3.8 uses the new mysqlnd driver (see 'mysql
>>>> client api' in phpinfo() output), which uses 41-bit password hashes.
>>>> However some older versions of mysql (I have 5.0.77) generate 16-bit
>>>> password hashes from GRANT statements or PASSWORD('...') function
>>>> invocations.
>>>>
>>>> However for some strange reason mysql clients seem to be able to connect
>>>> to such servers even if you generate the 41-bit password hash separately
>>>> and use that in your GRANT statement. In my case I just used
>>>> PASSWORD('...') function in a new version of mysql server on my local host.
>>>>
>>>> Could phpmyadmin please detect this (frustrating) problem and output
>>>> some helpful message (instead of 'could not login') like 'You may need
>>>> to check for a 41-bytes password hash in mysql.user table' ?
>>>
>>> it is NOT the job of phpMyAdmin take car that you migrate
>>> your passwords since they are deprecated SINCE YEARS
>>>
>>> they are deprecated since 5.0, there was 5.1 between and now
>>> mysql is on 5.5 - a long time to take care of this
>>
>> You may call it "deprecated for years", but I have an up-to-date CentOS
>> x64 release 5.7 (Final), and mysql 5.0.77 is the current mysql server
>> there. CentOS is an actively maintained Linux distribution with package
>> updates every week. I believe there are other distributions too that
>> prefer old versions for their packages for stability.
>
> and what does this change in the fact that "old_passwords=1" in my.cnf
> is deprecated since MySQL 5.0 what you have installed?

This is not only about old_passwords. Setting the the value to 0 does 
not solve the login problem (I tried it).

The issue here is that phpmyadmin can not login to the database, when 
the command line client can, and the user gets no message about what the 
problem is.

Thank you,
Timothy Madden

On 12.12.2011 15:54, Jerry wrote:
> On Mon, 12 Dec 2011 13:39:20 +0200
> Timothy Madden articulated:
>
>> You may call it "deprecated for years", but I have an up-to-date
>> CentOS x64 release 5.7 (Final)
>
> "CentOS-6.1 for i386 and x86_64 Architectures" has been released." While
> I am a user of CentOS and quite frankly have heard horror stories
> regarding their slow acceptance of newer program versions, is is
> possible that updating your OS version might ease your problem?

I know, unfortunately a CentOS 5 installation can not be upgraded to 
CentOS 6; a new installation would be needed for that (as they say on 
the web page).

While I do not mind re-installing my product testing servers, I can not 
expect the same from my company clients. And until they upgrade their 
servers, my company can not do so either.

> As you are undoubtedly aware, MySQL is currently at "version 5.5.x".
> Continued use of such an old version makes no sense at all.
>

Le 2011-12-13 13:18, Timothy Madden a écrit :
> On 12.12.2011 13:45, Reindl Harald wrote:
>>
>>
>> Am 12.12.2011 12:39, schrieb Timothy Madden:
>>> On 08.12.2011 22:30, Reindl Harald wrote:
>>>>
>>>>
>>>> Am 08.12.2011 21:11, schrieb Timothy Madden:
>>>>> On 08.12.2011 19:30, Timothy Madden wrote:
>>> [...]
>>>>> I found the cause, my php 5.3.8 uses the new mysqlnd driver (see 'mysql
>>>>> client api' in phpinfo() output), which uses 41-bit password hashes.
>>>>> However some older versions of mysql (I have 5.0.77) generate 16-bit
>>>>> password hashes from GRANT statements or PASSWORD('...') function
>>>>> invocations.
>>>>>
>>>>> However for some strange reason mysql clients seem to be able to connect
>>>>> to such servers even if you generate the 41-bit password hash separately
>>>>> and use that in your GRANT statement. In my case I just used
>>>>> PASSWORD('...') function in a new version of mysql server on my local host.
>>>>>
>>>>> Could phpmyadmin please detect this (frustrating) problem and output
>>>>> some helpful message (instead of 'could not login') like 'You may need
>>>>> to check for a 41-bytes password hash in mysql.user table' ?
>>>>
>>>> it is NOT the job of phpMyAdmin take car that you migrate
>>>> your passwords since they are deprecated SINCE YEARS
>>>>
>>>> they are deprecated since 5.0, there was 5.1 between and now
>>>> mysql is on 5.5 - a long time to take care of this
>>>
>>> You may call it "deprecated for years", but I have an up-to-date CentOS
>>> x64 release 5.7 (Final), and mysql 5.0.77 is the current mysql server
>>> there. CentOS is an actively maintained Linux distribution with package
>>> updates every week. I believe there are other distributions too that
>>> prefer old versions for their packages for stability.
>>
>> and what does this change in the fact that "old_passwords=1" in my.cnf
>> is deprecated since MySQL 5.0 what you have installed?
>
> This is not only about old_passwords. Setting the the value to 0 does
> not solve the login problem (I tried it).
>
> The issue here is that phpmyadmin can not login to the database, when
> the command line client can, and the user gets no message about what the
> problem is.
>
> Thank you,
> Timothy Madden

Timothy,

The exact error I get is:

#2000 Cannot log in to the MySQL server

is it the same for you?




-- 
Marc Delisle
http://infomarc.info

Am 14.12.2011 11:42, schrieb Marc Delisle:
>>>> You may call it "deprecated for years", but I have an up-to-date CentOS
>>>> x64 release 5.7 (Final), and mysql 5.0.77 is the current mysql server
>>>> there. CentOS is an actively maintained Linux distribution with package
>>>> updates every week. I believe there are other distributions too that
>>>> prefer old versions for their packages for stability.
>>>
>>> and what does this change in the fact that "old_passwords=1" in my.cnf
>>> is deprecated since MySQL 5.0 what you have installed?
>>
>> This is not only about old_passwords. Setting the the value to 0 does
>> not solve the login problem (I tried it).

changing the setting does not magically generate new passwords in
the user table, you have to change this setting and set the passwords
for all users new - yes it is work, i did it for 200 users 3 years ago

On 14.12.2011 12:42, Marc Delisle wrote:
> Le 2011-12-13 13:18, Timothy Madden a écrit :
>> On 12.12.2011 13:45, Reindl Harald wrote:
>>>
>>>
>>> Am 12.12.2011 12:39, schrieb Timothy Madden:
>>>> On 08.12.2011 22:30, Reindl Harald wrote:
>>>>>
>>>>>
>>>>> Am 08.12.2011 21:11, schrieb Timothy Madden:
>>>>>> On 08.12.2011 19:30, Timothy Madden wrote:
>>>> [...]
>>>>>> I found the cause, my php 5.3.8 uses the new mysqlnd driver (see 'mysql
>>>>>> client api' in phpinfo() output), which uses 41-bit password hashes.
>>>>>> However some older versions of mysql (I have 5.0.77) generate 16-bit
>>>>>> password hashes from GRANT statements or PASSWORD('...') function
>>>>>> invocations.
>>>>>>
>>>>>> However for some strange reason mysql clients seem to be able to connect
>>>>>> to such servers even if you generate the 41-bit password hash separately
>>>>>> and use that in your GRANT statement. In my case I just used
>>>>>> PASSWORD('...') function in a new version of mysql server on my local host.
>>>>>>
>>>>>> Could phpmyadmin please detect this (frustrating) problem and output
>>>>>> some helpful message (instead of 'could not login') like 'You may need
>>>>>> to check for a 41-bytes password hash in mysql.user table' ?
>>>>>
>>>>> it is NOT the job of phpMyAdmin take car that you migrate
>>>>> your passwords since they are deprecated SINCE YEARS
>>>>>
>>>>> they are deprecated since 5.0, there was 5.1 between and now
>>>>> mysql is on 5.5 - a long time to take care of this
>>>>
>>>> You may call it "deprecated for years", but I have an up-to-date CentOS
>>>> x64 release 5.7 (Final), and mysql 5.0.77 is the current mysql server
>>>> there. CentOS is an actively maintained Linux distribution with package
>>>> updates every week. I believe there are other distributions too that
>>>> prefer old versions for their packages for stability.
>>>
>>> and what does this change in the fact that "old_passwords=1" in my.cnf
>>> is deprecated since MySQL 5.0 what you have installed?
>>
>> This is not only about old_passwords. Setting the the value to 0 does
>> not solve the login problem (I tried it).
>>
>> The issue here is that phpmyadmin can not login to the database, when
>> the command line client can, and the user gets no message about what the
>> problem is.
>>
>> Thank you,
>> Timothy Madden
>
> Timothy,
>
> The exact error I get is:
>
> #2000 Cannot log in to the MySQL server
>
> is it the same for you?

Yes, I placed screenshot with it on the feature request tracker.

Alternatively, a page with short descriptions for these codes (#2000) 
and a link, directly from the reported error message, to the description 
would be a nice solution to the issue, too. Even if not all the codes 
get to have a description...

Timothy Madden

On 14.12.2011 12:57, Reindl Harald wrote:
>
>
> Am 14.12.2011 11:42, schrieb Marc Delisle:
>>>>> You may call it "deprecated for years", but I have an up-to-date CentOS
>>>>> x64 release 5.7 (Final), and mysql 5.0.77 is the current mysql server
>>>>> there. CentOS is an actively maintained Linux distribution with package
>>>>> updates every week. I believe there are other distributions too that
>>>>> prefer old versions for their packages for stability.
>>>>
>>>> and what does this change in the fact that "old_passwords=1" in my.cnf
>>>> is deprecated since MySQL 5.0 what you have installed?
>>>
>>> This is not only about old_passwords. Setting the the value to 0 does
>>> not solve the login problem (I tried it).
>
> changing the setting does not magically generate new passwords in
> the user table, you have to change this setting and set the passwords
> for all users new - yes it is work, i did it for 200 users 3 years ago

Yes, you are right, if you know what to do and do it right, it works.

But somehow it did not work for me. Under some conditions the server 
insists on generating the short (old style) password hashes. I had to 
find a post, on stackoverflow.com, saying that in this case I can also 
use a password hash generated outside mysql, to set the right password.

When I tried it a second time, on a different server, I could get the 
server to generate the long, new style, password hashes. There I just 
used SET GLOBAL old_passwords=0 in SQL, and I did not even need to 
change /etc/my.cnf.

Thank you,
Timothy Madden