ben

Nach drei Jahren hat der alte Server von bytetower.social ausgedient.

Ein Freund hatte uns den Server 2021 für Mastodon zur Verfügung gestellt und sich seitdem auch um den Betrieb gekümmert. In der Zwischenzeit ist die Technik weiter und die Verfügbarkeit von günstigeren ARM-basierten Rechnern größer.

Als dieser besagte Freund sich nun aus dem Hosting des Servers zurückziehen wollte, war dies die richtige Gelegenheit, die lange geplante Modernisierung des Setups endlich durchzuführen.

Die größte Herausforderung hierbei war das (hauptsächlich durch die fehlende Erfahrung in der Migration von Mastodon Instanzen) notwendige Finden der richtigen Informationen im Internet …

bytetower.social lief bisher auf einem von Cloudron verwalteten System und sollte jetzt auf einen Server mit Debian Linux umziehen.

Die wesentlichen Schritte für solch einen Umzug findet man in der Dokumentation von Mastodon.

Was dort natürlich nicht zu finden ist, sind die kleinen Stolpersteine auf dem Weg zur lauffähigen Kopie einer Instanz, wenn sich ein Teil des automatisierten Hostings ändert.

Entfernen der angelegten Tabellen auf dem neuen System

Der neue Server verwendet yunohost für die Verwaltung und stellt auch eine Installation für Mastodon zur Verfügung.

Um die als Grundlage für die Migration zu verwenden, um danach von den automatischen Updates durch yunohost profitieren zu können, muss man ein wenig von der offiziellen Migrationsanleitung abweichen.

Wenn die Installation abgeschlossen ist, muss man die Tabellen und ihre Inhalte entfernen, bevor man das Backup vom alten Server erfolgreich einspielen kann:

> sudo -u postgres dropdb mastodon
> sudo -u postgres createdb -T template0 mastodon

Wichtig ist, dass man den korrektes Nutzer verwendet, der die notwendigen Rechte besitzt, um diese Änderungen an der Datenbank vornehmen zu dürfen. Im Fall der yunohost Installation ist das der Nutzer postgres.

Anpassen des Datenbank Dumps

Im Cloudrons Backup von Mastodon findet sich das Backup der Postgres DB in der Datei postgresqldump. Es handelt sich dabei um eine Textdatei, die die notwendigen Migrationen beinhaltet, um die Datenbank von Mastodon auf dem neuen Server vollständig zu regenerieren.

Einige Einträge in dieser Datei nehmen aber Bezug auf den Nutzer, den Cloudron für die Datenbank angelegt hat. Den Namen findet man in den .env.production Konfiguration (DB_USER).

Da die Installation von yunohost auch auf bestimmte Namenskonventionen setzt und ich nicht jedes Mal händische Korrekturen durchführen möchte bei jedem Update, muss die postgresqldump verändert werden.

Die Referenzen auf den alten Nutzernamen müssen durch den Nutzernamen aus der neuen .env.production ersetzt werden:

> sed -i 's/<old DB_USER>/<new DB_USER>/g' postgresqldump

pg_restore oder psql?

Wenn man die Postgres DB wiederherstellen will, dann hängt die Wahl von dem Tool auch von dem Format ab, in dem der Dump erstellt wurde.

Im Fall von Cloudron wird eine Textdatei mit den plsql Anweisungen erstellt, die inkompatibel mit pg_restore ist.

Dazu kommt noch, dass die Versionen von postgres sich um einen Major Release unterscheiden, was man im Fall von yunohost auch nicht ändern kann.

Aus diesem Grund muss auf psql gesetzt werden für die Wiederherstellung. Dafür sendet man den Inhalt des Dumps an psql:

> psql -vcC -U <mastodon user name> -h localhost -d <DB_NAME> < postgresqldump

Je nach Größe der Datei kann dieser Schritt einige Zeit in Anspruch nehmen.

Das anschließende Kopieren des system Verzeichnisses dauert zwar einige Zeit, aber weicht nicht von der Dokumentation von Mastodon ab.

Precompiling der Assets und Regenerieren der Feeds

Bevor die Instanz wieder gestartet werden kann, sollen, laut Anleitung, noch die Assets vorkompiliert werden und die Feeds der Nutzer wiederhergestellt werden.

Beides wird über Rubyskripte gemacht, die zu einem Fehler führen, wenn sie wie in der Anleitung aufgerufen werden.

Debian stellt Ruby in Version 2.x zur Verfügung, die Skripte benötigen aber eine 3.x Version, damit sie funktionieren.

Der Trick ist hier, auf die neuere Version zuzugreifen, die während der Installation von Mastodon mit installiert wurde:

> RAILS_ENV=production PATH=/opt/rbenv/versions/mastodon/bin:/opt/node_n/n/versions/node/16/bin:/opt/node_n/bin:/opt/rbenv/shims:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so bin/bundle exec rails assets:precompile

Verwendet man, wie wir bei bytetower.social, einen ARM-basierten Server, dann sollte man das LD_PRELOAD entfernen.

Entsprechend geht man auch mit den Skiptaufrufen für die User Feeds vor.

Danach müssen nur noch die Services gestartet werden und die Mastodon Instanz sollte in neuem Glanz wieder zur Verfügung stehen.

Ich hoffe, dass ich mich in den nächsten Jahren vor einem weiteren Serverumzug drücken kann.

Mastodon