Zugschlusbeobachtungen

Daraus entstand dann ein Thread im Serendipity-Forum, aus dem ich mit Isotopps wie immer umwerfender IRC-Hilfe viel lernen konnte.

In MySQL und Derivaten gibt es viele Möglichkeiten, Zeichensätze einzustellen. So hat jede einzelne Tabelle einen eigenen Zeichensatz, während die "collation order" an der Datenbank klebt. Zusätzlich kann man für jede Verbindung mit dem Datenbankserver angeben, welcher Zeichensatz für diese Verbindung verwendet werden soll ("set names"). Der Datenbankserver rechnet das dann entsprechend um.

Mein Blog hat ja schon einiges Alter, und so wurden die Tabellen mit Charset latin1 angelegt. Als ich dann irgendwann das Blog selbst auf UTF-8 umgestellt habe, sind die Tabellen trotzdem latin1-codiert geblieben und MySQL hatte eine Menge zu konvertieren.

Bis einschließlich Debian Jessie hat das sogar ohne Konvertierung der Datenbank selbst funktioniert, alles war fein. Seit Debian stretch jedoch hat der Webserver doppelt UTF-8 codierte Daten an den Browser ausgeliefert, und zwar unabhängig davon, ob in serendipity "set names" eingeschaltet war (das verbirgt sich hinter der Option "Enable DB-charset conversion" in der Konfiguration) oder nicht. Im Gegensatz dazu waren die Umlaute in Jessie bei abgeschalteter DB-charset conversion in Ordnung, bei eingeschalteter conversion jedoch doppel-UTF-8.

In Stretch konnte ich mich also zwischen "falsch", "falsch" und "reparieren" entscheiden, und nachdem Isotopp sich zehn Minuten lang abgemüht hat, mir die Interna von MySQL zu erklären, hatte ich ein hinreichend schlechtes Gewissen um mich wirklich an die Arbeit zu machen.

Nach dem anfertigen eines (1,3 GB großen) MySQL-Dumps, der in seinem header ein "set names latin1" beinhaltete, habe ich diesen in "set names utf8" geändert und bei dieser Gelegenheit auch den Charset der eigentlichen Tabellen in utf8 geändert. Eine weitere Konvertierung war nicht notwendig.

Da MySQL keine "rename database" Option beherrscht, habe ich die alten Tabellen mit der phpMyAdmin-Option "Replace Table Prefix" innerhalb der Datenbank in einen anderen Namensraum verschoben und im nächsten Schritt versucht, den Dump zurückzuspielen. Das versagt mit "Specified key was too long; max key length is 1000 bytes", was mich postwendend zu diesem Forumsthread führt. Dort wird postuliert, die Datenbank würde mit UTF16 betrieben, was bei der Bildung eines Indexes aus einem 200 und einem 255 Zeichen langen Feld für einen Überlauf sorgt.

Das ist aber nicht so. Laut Doku geht MySQL schon bei UTF8 davon aus, dass ein Zeichen im Worst Case drei Bytes lang ist, und (200+255)*3 ist satt größer als 1000. Und in der Tat, nach Kürzung der Felder lässt sich die Tabelle anlegen. Das Spiel wiederholt sich zu Glück nur bei einer weiteren Tabelle, bevor es in den nächsten Level ging.

Dieser manifestiert sich in Form der (großen) Tabelle serendipity_spamblock_bayes, bei der MariaDB an mehreren Stellen das "primary key must be unique" constraint verletzt sieht. Entweder war die Tabelle vorher schon beschädigt (was die bekannten Probleme mit Kommentaren und dem Spamfilter erklären könnte), oder durch die Änderung des Zeichensatzes sind nun Schlüsselwerte, die früher unterschiedlich waren, gleich. Ich lösche kurzerhand den kompletten Tabelleninhalt aus dem Dump.

Schließlich ist das Blog nun wieder im Geschäft. Darüber freue ich mich sehr. Und die Trackbackspammer freuen sich auch, dass der Bayes-Filter so schön leer ist und beglücken mich mit hunderten von Trackbacks.

Es bleibt zu tun:

• Update auf aktuelles serendipity (was schwieriger ist als erwartet, da beim git pull / git merge hunderte von Dateikonflikten in Dateien auftauchen, die ich ganz sicher nicht in der working copy bearbeitet habe)
• Der schon lange geplante Umzug auf ein Neusystem
• Prüfen, ob die Kommentarfunktion wieder tut (bitte fleißig kommentieren!)
• Schauen, warum alle Kommentare und Trackbacks trotz installiertem mod_rpaf (das auch funktioniert, im access.log werden die vom vorgeschalteten Reverse Proxy mitgegebenen Original-IP-Adressen ordentilch gelogged) alle von 127.0.0.1 zu kommen scheinen
• Schauen, warum im Admin-Frontend trotz aktueller Plugins die Seite Spamblock (Bayes) leer ausgeliefert wird und eine Smarty-Fehlermeldung ins error.log wirft.