linuxschutz.de

Ich hasse Plesk, das ist der letzte Kinderkram -klickibunti und mit Null Funktionen – aber egal. Ein Kunde von uns ist endlich auf einen eigene Server umgestiegen, so dass wir dringend eine benötigte Höheneinheit bei Keyweb in Erfurt frei bekamen. Allerdings versprachen wir in geistiger Umnachtung, sein System auf einen 1&1 Dedicated Server zu migrieren. Dort läuft das tolle Plesk in der buntesten Version 9.0.1 – aber na gut.

Die Domain war bereits drüben und es mussten nur die Daten per SSH rumkopiert werden, dank der superflotten 1&1 Anbindung ja kein Problem, schließlich pegelt sich ja der Transfer irgendwann bei sagenhaften 4 Mbit / sec ein … also Bilder in Tar.gz Archive gepackt und los ….

Dann legten wir eine neue Datenbank via Plesk an sowie den dazugehörigen Benutzer, auch erstmal kein Problem. Die Anwendung bekam die DB Logins mitgeteilt und es sollte gehen, denkste. Wir transferieren Stammdaten aus Warenwirtschaftssystemen üblicherweise in die Anwendungen via gezippten und verschlüsselten CSV Dateien, so also auch hier – und wollten einfach per “LOAD DATA INFILE” den Krempel wieder in die neue Datenbank einlesen, was aber netterweise auf Anhieb aus der PHP Anwendung heraus per Programmcode nicht klappte. Also loggte ich mich auf dem MYSQL DB SERVER dieser Maschine per “mysql -uBenutzer -pPasswort” ein, machte ein connect auf die betreffende frisch angelegte Datenbank und probierte den ganzen Kram händisch per “LOAD DATA INFILE ‘/srv/www/vhosts/DOMAINVERZEICHNIS/httpdocs/importdatei.csv’ INTO TABLE irgendwas FIELDS TERMINATED BY ‘;’ (Feld1, Feld2);” … was zu dem lustigen Error 13 (HY00) führte – “Can’t get stat of DeinebekloppteImportdatei”. Ok, Google meinte, Plesk kennt kein LOAD DATA INFILE, hier muss ein LOAD DATA LOCAL INFILE denselben Zweck erfüllen. OK, aber nun wurde es ganz interessant,denn nach Eingabe von “LOAD DATA LOCAL INFILE ‘/srv/www/vhosts/DOMAINVERZEICHNIS/httpdocs/importdatei.csv’ INTO TABLE irgendwas FIELDS TERMINATED BY ‘;’ (Feld1, Feld2);” verweigerte der DB SERver mir vollends die Zusammenarbeit und meinte nur trocken: ERROR 1148 (42000): The used command is not allowed with this MySQL version!

Na gut, irgendwo las ich dann was von “mysql -uBenutzer -pPasswort –local-infile=1″, was schonmal in die richtige Richtung ging, aber da wir nicht wissen, ob der DB Server oder der Client betroffen ist, kann das zwar auf der Shell funktionieren, aber nicht unbedingt in der Anwendung.

Na Super, und nun? Eine komplett neuen MYSQL Server auf die Kiste zu kompilieren, darauf hatte ich keine Lust, da sind locker 3 Stunden weg. Aber da wir keine Angst vor der Shell haben, nahm ich mir die my.cnf vor, welche in /etc/ liegt und änderte kurzerhand die Konfiguration, damit die gesamte Ausgangssituation des Servers geändert wird, kann ja nix passieren . Aus set-variable=local-infile=0 in der Abteilung des MYSQL SERVERS ( [mysqld] ) wurde ein set-variable=local-infile=1 und denselben Eintrag legte ich zusätzlich im MYSQL-CLIENT Konfigurationsbereich an ( [mysql] )!

# The MySQL server
[mysqld]
set-variable=local-infile=1

[mysql]
set-variable=local-infile=1

Um auf Nummer sicher zu gehen, loggte ich mich auf den DB SERVER per admin und Masterpasswort ein und machte ein Connect auf die Rechte-Datenbank “mysql”. Hier änderte ich per manuellem Update  in der Tabelle “user” für den DB Benutzer, welchen wir zu Beginn mit der neuen Datenbank angelegt hatten, alle Rechte von “N” auf “Y” und erklärte ihm am Ende per FLUSH PRIVILEGES, dass ich es ernst meine.

So, wieder händischer Test per “LOAD DATA LOCAL INFILE ‘/srv/www/vhosts/DOMAINVERZEICHNIS/httpdocs/importdatei.csv’ INTO TABLE irgendwas FIELDS TERMINATED BY ‘;’ (Feld1, Feld2);” und er las mir den Krempel korrekt ein, soweit so gut.

Ok, Anwendung aufgemacht und das ganze per PHP Script versucht – ohne Erfolg, wie sollte es anders sein, also lag hier ein Problem mit dem PHP MYSQL Connect vor, denn der DB SERVER selber und der MYSQL Client auf der Konsole habe ja ihren Job eben korrekt gemacht, also kann es nur noch am PHP liegen. Und da der Connect auf die DB per PHP regulär durch “mysql_connect($db_host, $db_user, $db_password)” erfolgt, war hier anzusetzen … google befragt …. und siehe da, an kann dem mysql_connect noch ein paar mehr Infos mit geben, wie etwa die Fehlerausgabe an Stelle 4 und optionale Parameter an Position 5. Ein erweitertes “mysql_connect($db_host, $db_user, $db_password, FALSE, 128) erlaubt nun auch der PHP Klasse, welche den mysql Client spielt, LOAD DATA LOCAL INFILE zu akzeptieren.  Die Zauberzahl ist die 128 am Ende, welche das benötigte Importrecht zu Verfügung stellt. Gefunden habe ich das unter diesem Link, aber auch unter mysql.com findet man Hinweise und weitere Wunderzahlen.

Ich hoffe, das war etwas hilfreich, ich sitze dafür seit 07:50 Uhr heute früh und kann nun endlich um 13:15 Uhr ohne Mittagessen und mit kaltem Kaffee die Anwendung umschreiben, so dass der Import der CSV Datein auch auf einem 1&1 Server mit Plesk korrekt funktioniert.