Käferjagd – MySQL, Roundcube und die Zeichenkodierung

Schei? Encoding

Das trifft meine Beschäftigung in den letzten Tagen ganz gut. Ich habe bereits länger auf meinem Mailserver sieve im Zusammenspiel mit Dovecot im Einsatz. Als Frontend ist nach vim und dem ThunderbirdPlugin schlussendlich ein (inzwischen integriertes) Plugin für meinen Webmailer Roundcube zum Einsatz gekommen. Im Gegensatz zu den vorherigen Lösungen ist es hier über eine GUI möglich sich einfache Regeln, wie aus vielen Mailprogrammen bekannt, zusammen zu klicken. Inzwischen gibt es eine Weiterentwicklung, welche einige lang erwartete Features mitbringt. Leider verlief mein Test nicht ganz wie geplant.

Erste Beobachtung: Immer wenn man ein Sonderzeichen verwendet ist der Webmailer nicht mehr nutzbar. Die aktuelle Sitzung wird beendet, versucht man sich neu einzuloggen kann man Mails lesen, ein Klick auf die Filterseite führt aber zu einem neuen Absturz. Einzige Lösung: Das Filterscript mit einem anderen Editor löschen. Nicht ganz was ich wollte, aber eine Nachfrage beim Entwickler verheißt nichts Gutes: Kein Fehler in der Richtung bekannt. So weit so schlecht.

Sinnvollste Möglichkeit: Testserver hochziehen (LVM-Snapshots ftw) und Problem einschränken. Schnell war klar: Es muss wohl an der Config liegen. Auf einem frischen Server ließ sich die aktuelle Roundcube mit Plugin nutzen, auf der Kopie des Produktivservers tritt immer wieder der Fehler auf. Etwas hin und her – ratlosigkeit. Der Testserver konnte auf dem Filterserver des Testservers problemlos arbeiten, also kann es nicht am Mail-/Filterserver. Auch die Kopie des Programmverzeichnisses vom Produktiv auf den frischen Testserver arbeitete dort problemlos. Doch die Konfiguration? Also nahezu das komplette /etc vom frischen Testserver auf die Produktivkopie gezogen, PHP-FCGI auf mod_apache, etc, etc – nada. Einziger Unterschied, der mir auffiel war 64< ->32Bit – das wirds ja wohl kaum sein.

Hilft nichts – der Holzhammer muss her: Das komplette Plugin mit echos durchsetzt und huh – der Abbruch passiert beim Speichern der Session. OK, generell würde ich ja sagen nicht korrekt escaped, aber warum tritt es dann nur auf einem Server auf?!

Stunden später war mir dann meine eigene Blindheit auch klar: Ich hatte zwar alle Daten kopiert, aber nicht die Datenbank. Die hatte ich zwar kurz verglichen, aber ein kleines aber verhängnisvolles habe ich übersehen. Roundcube nutzte in den ersten Versionen ASCII als Zeichencodierung für die in MySQL gespeicherte Session-Table. Dies wurde irgendwann auf UTF8 umgestellt, jedoch nur in den Scripten für Neuinstallationen – die Update-Datei enthält keine entsprechende Konvertierung. Da mein RC schon lange läuft hing die Tabelle entsprechend auf ASCII und machte bei UTF8-Zeichen in der Session die Fliege. 3 Tage gebastel und ein ALTER TABLE später funktioniert nun alles – so kann man sich auch beschäftigen…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert