WriteFreely

Reader

Read the latest posts from WriteFreely.

from ben

After three years, the old bytetower.social server has reached the end of its life.

A friend gave us the server in 2021 for Mastodon and has been running it since then. In the meantime, technology has advanced and the availability of cheaper ARM-based computers has increased.

When this friend decided to retire from hosting the server, it was the perfect opportunity to finally do the long-planned upgrade of the system.

The biggest challenge (mainly due to a lack of experience in migrating Mastodon instances) was finding the right information on the internet...

This is the information dump I was looking for:

bytetower.social previously ran on a system managed by Cloudron and was now to be moved to a server running Debian Linux.

The essential steps for such a move can be found in the documentation for Mastodon.

What you won't find there, of course, are the little stumbling blocks on the way to a working replica of an instance when changing any part of the automated hosting.

Removing the created tables on the new system

The new server uses yunohost for administration. Plus, it comes with an installation package for Mastodon.

To use this as a basis for migration and to benefit from yunohost's automatic updates, you will need to deviate slightly from the official migration instructions.

Once the installation is complete, you need to remove the default tables and their contents before you can successfully import the backup from the old server:

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

It is important to use the correct user with the necessary privileges to make these changes to the database. In the case of the yunohost installation, this is the postgres user.

After that, update the password of the DB. You want to use the DB_PASSWORD from you .env.production

ALTER USER mastodon WITH PASSWORD '<DB_PASSWORD>';
\q

Modifying the database dump

The backup of the Postgres DB can be found in the Cloudron's backup as postgresqldump. This is a text file containing the migrations required to completely recreate the Mastodon database on the new server.

However, some entries in this file refer to the user that Cloudron has created for the database. The name can be found in the .env.production configuration (DB_USER).

Since the installation of yunohost also relies on certain naming conventions, and I don't want to have to make manual corrections every time I update, the postgresqldump has to be changed.

The references to the old username need to be replaced with the username from the new .env.production:

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

pg_restore or psql?

If you want to restore the Postgres DB, the choice of tool also depends on the format in which the dump was created.

In the case of Cloudron, a text file is created with the plsql statements, which is incompatible with pg_restore.

In addition, the versions of postgres differ by one major release, which cannot be changed for yunohost.

For this reason, you must use psql for the import. To do this, send the contents of the dump to psql:

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

Depending on the size of the file, this step may take some time.

The subsequent copying of the `system' directory takes some time, but does not deviate from the Mastodon documentation.

Precompiling the assets and rebuilding the feeds

Before the instance can be restarted, the assets should be precompiled and the users' feeds regenerated according to the instructions.

Both is done by Ruby scripts, which will fail if called as described in the official documentation.

Debian 11 ships with Ruby 2.x, but the scripts require a 3.x version to work.

The trick here is to access the newer version installed by yunohost during the installation of Mastodon:

> 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

The same should be done for the script executions for the user feeds. After that, all you need to do is start the services, and the Mastodon instance should be back to its former glory.

I really hope I can avoid another server move in the next few years.

 
Read more...

from 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.

 
Read more...

from ben

Migrating bytetower.social to a new server was more exciting than expected. It took several dry runs to get everything working...

I'm tired now. But I'll write more about what I learned tomorrow. I have a feeling I will need a cheat sheet for next time.

 
Read more...