bytetower.social – Learnings from the server migration: Cloudron to Debian
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.