| reply to ekiM
Re: MySQL SSL and local-infile settings said by ekiM:
Are the versions of MySQL the same across machines (and what is it)?
On the testing servers yes
Server version: 5.5.24-0ubuntu0.12.04.1 (Ubuntu)
For offisite/current production, 5.0.96-community
But since SSL is not enabled there is no way to test that part of replication.
said by ekiM:
The second link you provided (the "Howto" site) is good/detailed.
Where in that process do you have failure?
SSL is NOT enabled, thus no SSL connections can be made server to server for replication or for remote clients ie: MySQL Query Browser etc..
root@LAMPServer:~# mysql -u -p
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 166
Server version: 5.5.24-0ubuntu0.12.04.1 (Ubuntu)
Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show variables like "%ssl%";
+---------------+-------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------+
| have_openssl | DISABLED |
| have_ssl | DISABLED |
| ssl_ca | /etc/mysql/newcerts/ca-cert.pem |
| ssl_capath | |
| ssl_cert | /etc/mysql/newcerts/server-cert.pem |
| ssl_cipher | |
| ssl_key | /etc/mysql/newcerts/server-key.pem |
+---------------+-------------------------------------+
7 rows in set (0.19 sec)
mysql> ^CCtrl-C -- exit!
Aborted
root@LAMPServer:~#
quote:
Disabled means mysql has ssl support but it's just not enabled (if you have 'NO' instead of 'DISABLED' then you don't have ssl support)
said by ekiM:
Message in mysql errorlog is?
No
said by ekiM:
PHP/Mysql connectivity libraries are an inconsistent world between versions.
I do not understand why this can not be done via a shell script (scp and load).
For current development doing the upload via scp, is an option for one file is an option, but phpMyADMIN is better as I am not really too thrilled with too many people accessing the server via shell. I prefer to have shell access pretty limited to maybe myself and a couple of others regardless of security setup etc.. No access is the best security. They have to do it via phpMyAdmin or some other way... Just because your a developer doesn't mean you get free access to stuff.
For PRODUCTION.. no dice.
There is EXISTING PHP code which should be and would be 1:1 replacement if this change in MySQL was not made. I need to be able to undo this "security enhancement."
The listed options for doing so are being ignored for some reason.
said by ekiM:
I would use tried and true *nix and mysql tools. Another software layer doesn't help IMHO.
Software that runs to check the import file, kick out bad lines of the improt file, ie: CR/LF in fields, etc.. exists already and would not need to be re-developed if it were not for this change in MySQL setup.
--
1311393600 - Back to Black.....Black....Black.... |
