Prosody Downgrade von 0.10 Nightly auf 0.9.10 Stable

Bis gestern habe ich meinen trashserver.net XMPP Server unter Prosody Version 0.10 (Nightly) laufen lassen, um einige neue Module nutzen zu können, die zu früheren Zeitpunkten nur für die Nightly-Version verfügbar waren. Alle von mir verwendeten Module gibt es mittlerweile auch für die stabile Prosody Version 0.9.10, sodass ich ein Downgrade durchführen wollte, um von der stabileren Version (und weniger Updates!) profitieren zu können. Letzte Woche hatte ich bereits einen Versuch gewagt, auf die stabile Version umzusteigen. Dabei kam es jedoch zu Problemen mit der UTF-8 Codierung der Datenbank.

Im XMPP Gruppenchat mit den Entwicklern habe ich mir erklären lassen, dass Prosody Version 0.9.10 die Daten zwar mit UTF-8 codiere – beim Aufbau der Verbindung zur Datenbank jedoch die Verbindung nicht explizit auf UTF-8-Codierung setze, sondern den DB-Standard (Latin1) verwende. Prosody Version 0.10 hingegen verwende auch für die Datenbankverbindung UTF-8. Es könne also zu Codierungsproblemen kommen, wenn ich einfach auf die ältere Version umsteigen würde. Mein erster Migrationsversuch lief so ab:

• MySQL-Datenbank sichern
• Mit dem Prosody Migrator unter v0.10 von MySQL zu  „prosody_files“ umwandeln
• Prosody 0.10 entfernen
• Prosody 0.9.10 installieren
• Mit dem Prosody Migrator von „prosody_files“ wieder auf MySQL konvertieren

Ich hoffte, durch den Umweg über das Datenformat „prosody_files“ würden die Codierungsunterschiede umgangen (Vorschlag aus dem Chat). Leider brachte das nicht den erhofften Erfolg: Pidgin und Gajim konnten überhaupt nicht mehr mit dem Server zusammenarbeiten (Codierungsfehler) und Conversations zeigte bei Umlauten merkwürdige Symbole an. Ich habe den Umstieg dann abgebrochen, habe v0.10 wieder installiert und das DB-Backup zurückgespielt.

Gestern habe ich dann einen neuen Versuch gewagt: Wieder über den Umweg über das Dateisytem-Format. Diesmal habe ich den Datenbank-Server aber zusätzlich dazu gezwungen, zu den Clients nur noch UTF-8-Codierte Verbindungen zuzulassen. Mit MariaDB als DB-Server erreicht man das, indem man in der Konfigurationsdatei „/etc/mysql/my.cnf“ im [mysqld]-Abschnitt folgende Zeile ergänzt:

init-connect='SET NAMES utf8'

So erreiche ich, dass Prosody 0.9.10 (genauso wie die neuere Version 0.10) eine UTF-8-codierte Verbindung zum DB-Server herstellt, und somit die Daten der Nightly-Version problemlos verwenden kann. Tatsächlich ging die Rechnung auf, und alle Clients konnten sich ohne Codierungsfehler zum Server verbinden.

Abschließend lässt sich sagen, dass eine Rückmigration machbar ist, weil das Datenbank-Schema zwischen den beiden Prosody-Versionen nicht geändert wurde. Die Codierung der Verbindung wurde zwischen den Versionen aber geändert: Von Latin1 auf UTF-8. Indem man nur noch UTF-8-codierte Verbindungen zum Server zulässt (das ist sowieso zu empfehlen), kann auch Prosody 0.9.10 auf den Daten von Prosody 0.10 arbeiten. Der Umweg über das „prosody_files“-Format wäre wahrscheinlich nicht nötig gewesen. Vermutlich hätte ich die Datenbank einfach bestehen lassen können.