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]
