Andrew wrote:
In the last episode (Mar 26), Andrew said:

What could ever be the problem with the failing Perl DBI (C->B)
connection, if everything is OK with a C->A connection (with and
without Perl), and, in addition, a command-line C->B connection
works?

The password on B is a new-style password, and perl on C was built with
old mysqlclient libraries?

That is the most likely explanation, I think.

I'm sorry, this seems to be getting overlooked, each time i attempt to
convey it:

For BOTH A and B, the Operating System, the Mysql server and client
versions & configurations, and (apparently) everything else relevant to
mysql, IS IDENTICAL! (including firewall, etc.etc.)

No. They are *supposed* to be identical, but clearly they are not. I think you're asking the wrong question. You are asking why two identical instances would behave differently. Well, they wouldn't. I think a better question is, what's different?

Yet, C connects to A, but not to B (within the SAME script and loop)!

Right. The exact same client works for A, but not for B. Thus, A and B are different.

If it /is/ a matter of new-style vs. old-style password, PLEASE tell me
where else to look.  On both A and B, the files /etc/my.cnf are identical
(with "old_passwords=1" in each).  Where else should I look for a
difference in configurations?

First, the global configuration file, /etc/my.cnf, can be overridden by a server-specific option file and/or command line options. You can verify what the server on B is doing with

  SHOW VARIABLES LIKE 'old_passwords';

One possibility is that this will return "OFF" for server B. I would *guess* that this is not your problem, but it is worth checking.

Second, the difference in authentication is that before 4.1, mysql used a 16-byte password hash, while 4.1.1 and up use a 41 byte hash. Hence, the password column of the user table is 41 bytes long for both server A and B. Now, the old_passwords setting causes mysql to create *new* passwords as 16 byte hashes by default, *but it has no effect on pre-existing passwords*. One likely possibility is simply that the user's password was created on A *after* setting old_passwords to ON, but was created on B *before* setting old_passwords to ON. That would yield a password hash that is 16 bytes on server A, but 41 bytes on server B. As a result, old-style clients can connect to A, but not to B. In that case, you can fix this by resetting the user's password on server B.

If C (with MySQL 4.0.25-standard-log) connects to A (5.1.7-beta), as it
is now (WITHOUT any upgrading), doesn't that indicate that C is capable
of connecting to B as well (B being identical to A)?  (Something akin to
transitivity here...)

It would, if A and B were identical.  Hence A and B are not identical.

completely stumped.

TIA

andrew

If neither of my suggestions helps, let us know. Someone will surely come up with another suggestion.

Michael

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to