Gentoo: PHP & MySQL-Updates machen Probleme
Sonntags hat man ja nichts zu tun, wir haben ja alle eine 40-Stunden-Woche und “Freitag ab eins macht jeder seins” :-D. Was macht man also? Während man die während der Woche liegengebliebene Arbeit nachholt und sich auf die nächste Arbeitswoche vorbereitet, kann man ja mal eben schnell seinen Server auf den neuesten Stand bringen.
Ich betreibe meine Rechner vorzugsweise unter Gentoo, nur zum Daddeln habe ich auf dem Laptop auch ein Windows. Das Schöne an Gentoo ist eigentlich, dass man sich darauf verlassen kann, dass alles so funktioniert, wie es soll. Es ist zwar manchmal ein bisschen Nachhilfe notwendig, aber das macht die Sache ja eher noch interessanter.
Aber was ist jetzt passiert? Ich habe gestern PHP und MySQL auf die neuesten stabilen(!) Versionen upgedated, und musste dann feststellen, dass sich sowohl Joomla! als auch phpBB2 beharrlich weigerten, Umlaute darzustellen. Stattdessen bekam man nur Multi-Byte-Sequenzen zu sehen. Die neuen Versionen ließen sich auch durch weitestgehende Anpassungen der /etc/mysql/my.cnf bzw. der /etc/apache2-php5/php.ini nicht dazu überreden, dass die Umlaute wieder korrekt angezeigt wurden.
Was war denn da kaputt? Schließlich ging es nur von MySQL 4.1.14 auf 4.1.14-r1, und auch bei PHP ging es nur um ein ähnlich kleines Update. Grund für die Probleme war es offensichtlich, dass die bereits existierenden Datenbanken in LATIN1-Kodierung vorlagen, das neue MySQL 4.1.14-r1 auf Gentoo aber UTF-8 verwendet. Stellt man das auf LATIN1 zurück, erscheinen zwar die Umlaute wieder, dann gibt es aber Probleme mit neuen Datenbanken, die man gerne in UTF-8 hätte.
Was passiert war: Zum ersten Mal seit langem haben die Betreuer des Package-Systems von Gentoo (portage) wohl etwas durchgewunken, was nicht hätte stable sein sollen. Das letzte Mal war mit das bei einem Update von apache-2.0.x-r39 auf apache-2.0.x-r40 untergekommen: bei diesem Update hatten sich die Maintainer des Portage-Trees dazu entschlossen, das Layout der Konfigurations-Dateien komplett zu ändern—bis dato wiesen die Konfigurationsdateien des httpd unter Gentoo eine gänzlich andere Struktur auf als von der Apache Foundation oder anderen Linux-Distributionen bekannt.
Was mich besonders ärgert: Wie kann man eine ernsthafte Linux-Distribution sein wollen und gleichzeitig Bindestrich-Updates (bumlux-x.y.z-r13 auf bumlux-x.y.z-r14) als stable releasen, die den Sysadmins die Konfiguration völlig zerhauen? Das darf einfach nicht passieren, schließlich gibt es ja nicht nur ein paar Privatanwender und Lehrstühle, die auf (Gentoo) Linux bauen—inzwischen gibt es auch Leute, die damit ihr Geld verdienen und die wichtige Applikationen betreiben.
Ach ja, der Work-around: Lokalisiert jeden Aufruf von mysql_connect() in Eurer Web-Applikation und schreibt direkt dahinter ein
mysql_query("SET CHARACTER SET xxx");
wobei xxx das gewünschte character set ist.
Umständlich und blöd, aber es funktioniert zumindest bei Joomla! und phpBB2.
Zum Schluss, und damit da keine Missverständnisse entstehen: Ich halte Gentoo nach wie vor für eine tolle Distribution und setze weiter darauf—ich hoffe aber, dass sich das Release Management zumindest bei den wichtigen Applikationen (LAMP, X, KDE, ...) noch weiter verbessert.
Update
- Bernd Wurst schreibt in seinem Blog auch über die oben beschriebene Problematik und erklärt auch noch ein bisschen besser, warum MySQL sich so benimmt, während ich ja hier nur eine Metabetrachtung vorgenommen habe und den Workaround beschreibe. Danke an Bernd für die Erklärung!
- Steffen Zieger schreibt in seinem Blog, dass es auch jetzt noch Probleme mit MySQL und PHP unter Gentoo gibt, die allerdings einfacher zu umschiffen sind. Inzwischen müssen nur noch die Zeichensätze der Datenbanken in der Konfigurationsdatei
my.cnfrichtig eingestellt werden – und das ist ja auch logisch.
Ähnliche Artikel in diesem Blog:
Am 19. Mai 2006 um 02:19 Uhr
Ich gehör nicht zwingend zu den Leuten, die jede Woche ein sync + update durchführen, aber einmal im Monat ist es dann doch soweit, dass ich mich um meinen kleinen Rechner kümmere, tja und das war gestern. Natürlich stapelt sich da Einiges. Normalerweise brauch ich da ja nicht so zuschauen, allerdings seit gut 4 Monaten muss ich das, da php immer wieder wegen USE=”recode” meckert, das will es nicht, aber gut, man gewöhnt sich dran.
Allerdings, ein leichter Schock durchfuhr mich heute, als eine Testseite, die mir allerdings recht wichtig ist, plötzlich keine Umlaute mehr kannte (ich weiß, eigentlich &_uml;t man, aber, doch nicht bei einer kleinen Seite für ein Hobby
). Jedenfalls hab ich die letzten 4 Stunden auf der Suche nach dem Fehler verbracht, hab meine httpd.conf auseinandergenommen, die php.ini’s modifiziert und was weiß ich nicht alles gegoogelt, gesucht (komplette Lokalisierungseinrichtung nochmal durchexerziert) und nichts änderte sich. Welch sinnlosen Hinweisen man nachgeht, wenn man verzweifelt einen Fehler sucht. Jedenfalls landete ich dann in deinem Block und stellte fest, dass auch die mysql-4.1.19 nach wie vor diesen Fehler hat. Allerdings, das empfohlenen mysql_query(“SET CHARACTER SET”) wirkt nach wie vor Wunder. Darum meinen Dank, dass du dies in deinem Blog veröffentlicht hast und mal eine kleine Schelle für das Release Management bei Gentoo, auch wenn ich sonst, bis auf einige andere Winzigkeiten, die manchmal riesige Fragezeichen in meine Augen malen – wegen jener oft simplen Lösungen, auf die man jedoch erst einmal kommen muss – ebenso, wie du, mit meinem Eselspinguin voll auf zufrieden bin.
Gruß ND
Am 2. Juni 2006 um 06:44 Uhr
Mich hat dieses Update die gestrige Nacht gekostet, dank den Spender dieses Tipps jetzt kann ich endlich ins Bett
Am 10. August 2006 um 13:13 Uhr
Wo genau muss ich den ”|mysql_query(“SET CHARACTER SET
> xxx”);” einfügen damit Joomla die Umlaute aus der DB wieder schluckt?
Am 11. August 2006 um 13:27 Uhr
Eine hoffentlich passende Beschreibung, wie Du die entsprechende Stelle in einer Joomla-Installation findest:
Wechsele in das Wurzelverzeichnis Deiner Joomla-Installation (z.B. /var/www/localhost/htdocs oder /var/www/localhost/vhosts/mein-joomla.example.com).
Führe in diesem Verzeichnis den Befehl
$> grep <del>R mysql_connect *
aus.
Dieses Kommando findet alle Files, in denen der String mysql_connect vorkommt und gibt bei meiner Installation Folgendes aus:
bkp.installation/index.php: < ?php echo
function_exists( 'mysql_connect' ) ? '<b><font color="green">Available</font>' : '<b><font color="red">Unavailable</font></b>';?>
includes/database.php: if (!function_exists( 'mysql_connect' )) {
includes/database.php: if (!($this</del>>_resource = @mysql_connect(
$host, $user, $pass ))) {
mambots/content/geshi/geshi/php-brief.php: 'session_start', 'session_destroy', 'session_unset', 'session_set_save_handler', 'session_cache_limiter', 'session_cache_expire', 'session_set_cookie_params', 'session_get_cookie_params', 'session_write_close', 'preg_match', 'preg_match_all', 'preg_replace', 'preg_replace_callback', 'preg_split', 'preg_quote', 'preg_grep', 'overload', 'ctype_alnum', 'ctype_alpha', 'ctype_cntrl', 'ctype_digit', 'ctype_lower', 'ctype_graph', 'ctype_print', 'ctype_punct', 'ctype_space', 'ctype_upper', 'ctype_xdigit', 'virtual', 'apache_request_headers', 'apache_note', 'apache_lookup_uri', 'apache_child_terminate', 'apache_setenv', 'apache_response_headers', 'apache_get_version', 'getallheaders', 'mysql_connect', 'mysql_pconnect', 'mysql_close', 'mysql_select_db', 'mysql_create_db', 'mysql_drop_db', 'mysql_query', 'mysql_unbuffered_query', 'mysql_db_query', 'mysql_list_dbs', 'mysql_list_tables', 'mysql_list_fields', 'mysql_list_processes', 'mysql_error', 'mysql_errno', 'mysql_affected_rows', 'mysql_insert_id', 'mysql_result', 'mysql_num_rows', 'mysql_num_fields', 'mysql_fetch_row', 'mysql_fetch_array', 'mysql_fetch_assoc', 'mysql_fetch_object', 'mysql_data_seek', 'mysql_fetch_lengths', 'mysql_fetch_field', 'mysql_field_seek', 'mysql_free_result', 'mysql_field_name', 'mysql_field_table', 'mysql_field_len', 'mysql_field_type', 'mysql_field_flags', 'mysql_escape_string', 'mysql_real_escape_string', 'mysql_stat',
mambots/content/geshi/geshi/php.php: 'mysql_db_query','mysql_db_name','mysql_data_seek','mysql_createdb','mysql_create_db','mysql_connect',
Für uns in erster Linie interessant ist die Datei includes/database.php. Öffne diese Datei zum Bearbeiten mit einem Texteditor Deiner Wahl:
$> vim includes/database.php
Finde dann den Bereich im Code, in dem die Verbindung mit der MySQL-Datenbank aufgebaut wird. Der sollte nach dem Einfügen unseres Fixes ungefähr so aussehen:
if (!($this->_resource = @mysql_connect( $host, $user, $pass))) {
$mosSystemError = 2;
if ($goOffline) {
$basePath = dirname( <i>FILE</i> );
include $basePath . '/../configuration.php';
include $basePath . '/../offline.php';
exit();
}
}
mysql_query("SET CHARACTER SET LATIN1", $this->_resource);
Wichtig ist, dass der Fix nach dem Ende des IF-Blocks eingefügt wird und nicht innerhalb des IF-Blocks, da dieser nur bei einem Fehlschlagen der Verbindung ausgeführt wird (z.B. wenn MySQL nicht läuft oder der DB-Server nicht erreichbar ist). In diesem Fall wäre uns das character set vermutlich ohnehin ziemlich egal.
Ich hoffe, Dir damit geholfen zu haben. Ansonsten frage bitte einfach noch
einmal nach.
Am 25. Oktober 2006 um 18:53 Uhr
[...] Bereits im April gab es Probleme mit einem MySQL-Upgrade, nun gibt es einen weiteren Fall, in dem die Maintainer für MySQL bei Gentoo offensichtlich etwas zu schnell geschossen haben. [...]