Skip to content

Spaß mit serendipity beim Debian-Update

Das Update von Debian jessie auf Debian stretch hat im Umfeld meines Blogs die Migration von MariaDB 10.0 auf MariaDB 10.1 und von PHP 5.6 auf PHP 7.0 gebracht. Dazu musste ich natürlich in der Apache-Konfiguration das php5-Modul durch das php7-Modul ersetzen und noch einige andere kleine Änderungen durchführen.

Danach waren im Blog durchgängig die Umlaute kaputt; das sah so ähnlich aus, als würde man ein UTF-8 codiertes Dokument auf einem ASCII-Terminal betrachten. Insider nennen das auch Double-WTF8.

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.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

-thh on :

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)

Die klügste Idee ist es in der Regel - nach Anfertigung eines Backups - einfach das aktuelle Release drüberzubügeln.

Im konkreten Fall würde ich damit bis zum nächsten Patch-Release (2.1.2) warten oder direkt den 2.1-Branch aus dem Repo nehmen (github lässt ja auch daraus ein ZIP-File erzeugen), weil es noch ein paar ärgerliche Bugs gibt (die allerdings idR leicht zu beheben sind).

Der schon lange geplante Umzug auf ein Neusystem

Eine tolle Sache!

Ich habe das 2014 gemacht: alles neu, und dann nur die Einträge und Kommentare übernommen (Kopieren der entsprechenden Tabellen, samt entryproperties und Kategorien und so). Ist gar nicht so wild; vor allem muss man schauen, das wieder alle nötigen Plugins installiert werden, vor allem für alle verwendeten Formatierungen, aber das geht alles überraschend gut.

Und s9y 2.x ist wirklich ein großer Schritt voran; damit machte das Bloggen direkt wieder richtig Spaß. - Auf jeden Fall auch ein aktuelles Theme verwenden; 2k11 kann man eigentlich recht einfach anpassen.

Prüfen, ob die Kommentarfunktion wieder tut (bitte fleißig kommentieren!)

Noch nicht ganz fehlerfrei, aber das dürfte am nächsten Punkt liegen.

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

Ich passe ...

(Warum genau machst Du das nochmal mit einem Reverse Proxy? War das nur, damit PHP unter der UID des Benutzers läuft, oder hatte das noch andere Gründe? Ich meine mich zu erinnern, dass Du da vor Jahren mal drüber schriebst ... Falls es nur um die PHP-Rechtetrennung geht, wäre PHP-FPM vielleicht eine einfachere Lösung.)

Schauen, warum im Admin-Frontend trotz aktueller Plugins die Seite Spamblock (Bayes) leer ausgeliefert wird und eine Smarty-Fehlermeldung ins error.log wirft.

Ich würde nicht ausschließen wollen, dass das an der alten s9y-Version u.v.a. - wenn das zutrifft - einem alten Thema im Backend-Bereich liegt.

Marc 'Zugschlus' Haber on :

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) Die klügste Idee ist es in der Regel - nach Anfertigung eines Backups - einfach das aktuelle Release drüberzubügeln.

Früher[tm] wurde empfohlen, einfach einen git Checkout herzunehmen. Ist jetzt die empfohlene Vorgehensweise, einen git Checkout danebenzulegen und den auf den Live-Webspace zu kopieren? Schön find ich das nicht.

Muss mal Doku lesen.

Der schon lange geplante Umzug auf ein Neusystem Eine tolle Sache!

Ich liebe es. Nicht.

(Warum genau machst Du das nochmal mit einem Reverse Proxy? >War das nur, damit PHP unter der UID des Benutzers läuft

Jupp. Auf dem neuen System bekommt das Blog eine eigene VM, und die wird keine IPv4-Adresse bekommen. Sprich, über IPv4 muss da ein Reverse Proxy vornedran.

Schauen, warum im Admin-Frontend trotz aktueller Plugins die Seite Spamblock (Bayes) leer ausgeliefert wird und eine Smarty-Fehlermeldung ins error.log wirft. Ich würde nicht ausschließen wollen, dass das an der alten s9y-Version u.v.a. - wenn das zutrifft - einem alten Thema im Backend-Bereich liegt.

Der Backend-Bereich hat Themen? Wo schaltet man die um?

Und mit dem alten s9y geh ich nicht ins Forum...

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options