20-Mar-2006

MySQL issue?
Since MySQL seems to be up and running, and PHP is active already, the next step is obvious: management of the MySQL database using a PHP-based application - phpMyAdmin.
It runs on Athene already, to find out how it works, so on Diana I did the same: Got the latest version (2.8.0.2), and created a database schema (because there was a script to create a schema, and on Athene there is one as well).

It didn't work: no such user.

Rats - I should have read the installation manuals better on beforehand: I needed the user to be added in mysql. Did that, it accepted the username and password, but next signalled:

Client does not support authentication protocol requested by server; consider upgrading MySQL client

Ok, I know about that, I read about that on http://www.issinoho.com:8080/phpbb2/viewtopic.php?t=2

It seems that the latest PHP-on-VMS is built against an older MySQL version (3.x in stead against 4.0. Simple mismatch), but I can live with that - for the moment. (When will a new, really recent version of php_mysql be delivered, or is it available somewhere else?)

So I followed the advise, changed the password using OLD_PASSWORD, and retried, but got another surprising error:



MySQL's help wasn't very helpful either:



So I start searching and I found this string in some files within phpMyAdmin, and in the script creating the schema. Chnaged them to UTF8_bin - all - and recreated the database. No differece, but the same error mentioning utf8 now.

Reversed it all to the original, and behold:

I COULD LOG IN...

But the output was a bit different than I thought: I couldn't do on Diana what I can do on Athene (Ok, that one user MySQL5, but that's not a reason why I don't see the phpmyadmin database, cannot access mysql tables that I can see on Athene. Or is it?)

Anyway, I changed this user's privileges to be able to do everything from Diana's terminal, and started SWB to access phpMyAdmin again.

ALAS - the situation returned:

#1273 Unknown collation - utf8_unicode_ci

so back to the basic problem: something is definitely wrong. But the issue is how to get around this... (The same problem arises when accessing phpMyAdmin over the Internet)
Log cycle and publish
Log scan hasn't run last night - at least, it did run but didn't copy anything. Obvious - since the disk on which the webs are located has chnaged, I needed to adapt these procedures as well, and resubmitted. Secured the copies of apache's logs as well bij incorporating the version number in the filename so these would be unique and therefore cannot be purged away - and ran the copy-script and after that, recreated the index. See tomorrow if that's all done (Note: It is) so next to see how FTP can be handled likewise.