Migrating servers, leaving Fosstodon, moving to my own GoToSocial

During the last few days I did two migrations, the first one I had been planning for some time, the second one was more spontaneous, and they were directly related to one another.

First I migrated the VPS hosting my GoToSocial instance from RackNerd to Hetzner. After that I migrated one of my main Fediverse accounts from Fosstodon to my GoToSocial instance, fedi.stfn.pl/.

Moving from RackNerd to Hetzner

The VPS migration had been on my mind for quite some time. It fits into my ongoing plans to reduce my dependence on large corporations (see my On Degoogling post), and especially the ones that are based in the United States. With the latest changes that the US is undergoing, I just do not want to have my data and services running there. Europe is a place that takes matter such as data privacy and sovereignty much more seriously, and what is also very important to me is that Europe is a place which I feel a part of. And I strongly believe that the European Union and the agends that it is pushing are the best things that have happened to Europe in all of its history.

And so I chose the German company Hetzner as my new VPS service provider. They have datacenters in Eastern Germany, which is physically very close to me, and I’ve been already using their other service for months. Their Storage Box is very good in my opinion, and while it has a non-zero entry level, the pricing is hard to beat in the area of cloud storage. Also, RackNerd’s VPS services are very barebones, while Hetzner provides additional tools for managing servers, like regular backups and snapshots.

Here I need to stress that I have never had any issues with RackNerd, no downtime at all, and their pricing is very good, but well, I want to have my Internet stuff close to me, in Europe. Yes, I know that RackNerd has datacenters in the Netherlands, but all in all, they are a company from California.

Moving from Fosstodon to fedi.stfn.pl

I do not want to elaborate on the reasons I left Fosstodon, already a lot of people said a lot of words of varying intensity about the whole affair. Let me just say that apart from the, let’s say, social aspects, the want to move to my own place and handle the technical parts myself was an important factor.

The Migrations

Now let’s talk about the technical stuff. I wanted to have my VPS situation sorted out before moving my large Fosstodon account to my VPS, so first I went with the server migration.

Moving GoToSocial instances between servers

The first migration I went with was migrating my GoToSocial instance from my RackNerd VPS to my new Hetzner one. This does not mean I already left RackNerd, as I have more services running on their servers. Eventually I will move all of them.

As in many previous of my blog posts, I am writing about a thing I did, but I try to talk about it in the form of a tutorial, so that anyone can do the same. That’s why the way the next paragraphs are written is funky at times, jumping between my “memoirs” are instructions what to do. Anyway…

The whole process is rather straightforward. The crucial thing is to have good backups and do each step slowly and making sure it succeeded.

The following steps are assuming you have an already running GTS instance on server A (called source from now on) and you want to move it on a bare, just bought Linux server B (called target). I am running GTS as a systemd service with SQLite and nginx as a separate reverse proxy. HTTPS is being handled by Certbot. As you can see, there is a lot of variables here, and you setup may be very different, but the general ideas should be similar.

The very first thing to do when migrating services between servers, is to go to the domain provider you are using, open the settings of the domain of the service being migrate, and change its TTL to a very small number, like 5 seconds. This should be done preferably a few hours in advance of the migration, the most correct way is to wait the time the domain’s TTL was set to in the first place. For example, if you domain TTL was set to 24 hours, it would be best to change the TTL to 5 seconds and wait those 24 hours before the migration. This clears the caches of browsers and any downstream DNS servers, and so when clients will try to reach you service after the migration, the DNS cache will not take them to the IP address of the old server.

Once the waiting is done, it’s time to do the actual migration.

The first step to do is to go through the typical initial server config and hardening, Initial Server setup with Ubuntu by DigitalOcean. is a great article and I refer to it every time I set up a new server

After that, an optional but useful step is to set up the monitoring stack for the new server: Prometheus, Node Exporter and nginx-prometheus-exporter. I also make sure that nginx is installed. If you are using a database other than SQLite, now it would also be the time to install it.

A few useful resources on monitoring:

• install Prometheus as systemd service
• set up basic auth for Prometheus

Once this is done, the actual GoToSocial migration can happen.

Nginx migration

• stop nginx on target
• copy /etc/ngix/sites-available from source to target and in the target server symlink the GTS server config to sites-enabled in a typical nginx fashion.

TLS certificates migration

• copy /etc/letsencrypt from source to target. If there is no such folder, check in the nginx site config where the TLS certs are stored in you case.

GoToSocial migration

This is the actual migration. Begin it with stopping the GTS service on the source server.

sudo systemctl stop gotosocial.service

At this moment the downtime of your instance begins. If you have more than one user, I hope you warned them in advance :)

• copy /etc/system/system/gotosocial.service from source to target
• pack /gotosocial on source to gotosocial.tar.gaz.

sudo tar -czvf gotosocial.tar.gz /gotosocial

I followed the steps from the GTS docs when doing the initial installation, so in my case, GTS data lives in the /gotosocial top level directory, and is owned by the user gotosocial

• create gotosocial user and group on the target server

sudo useradd -r gotosocial 
sudo groupadd gotosocial 
sudo usermod -a -G gotosocial gotosocial

• copy the gotosocial.tar.gz tar archive to target and unpack
• chown the whole /gotosocial folder to the user gotosocial

sudo chown gotosocial:gotosocial -R /gotosocial

If you are using a db other than SQLite, now would be the time to migrate it. I’ve never done it, so I would not be of much help here.

• on target enable and start gotosocial.service

sudo systemctl enable --now gotosocial.service

At this moment, GoToSocial should start cleanly on the target server. But it won’t be available yet to the outside world, as nginx is not running yet. The simplest way to confirm that GTS is indeed working is to curl it from the same server it is running on

curl http://localhost:8000

The response should be welcome web page. If it is not working, time to start debugging. A good place to start are the system logs:

sudo journalctl -xeu gotosocial.service

This should show the cause of the problem. One common problem is file permissions, make sure /gotosocial belongs to the right user, the one that is mentioned in the gotosocial.service systemd file.

Once we are sure that GTS is running on the server, the last steps are to switch the DNS so that the domain points to the target server, and start the nginx service on the target. It’s also a good practice to test the nginx config before starting it:

sudo nginx -t
sudo systemctl enable --now nginx.service

nginx should start without issues, but as always should is the key here. If it does not want to start, consult the logs as described above.

And done! Your GoToSocial instance should be back online, working from the new server.

If that is correct, the final final setp is to reinstall certbot, so that the certificate renewal hooks are in place. Just do the same steps from Certbot’s page as you would install it. Certbot is smart enough to find that the certs already exist on the target server and will reuse them, and configure its new service around them.

Migrating my Fosstodon account to my GoToSocial instance

With my Gotosocial instance fedi.stfn.pl/ working nicely on new hardware, it was time to migrate my Fosstodon account to it. Thanks to the creators of the Activity Pub protocol, Mastodon, and GoToSocial, it was a very simple task.

I already had an account stfn on my GTS instance, rarely used and with almost no followers/following, so the first step in the migration was done in advance.

In its settings, I added https://fosstodon/users/stfn as an alias, to prove Fosstodon that this account indeed belongs to me.

Then, in Fosstodon’s account settings, I first requested an archive of all my data. It took a few hours to generate it. I also downloaded all of the CSV lists of people I followed, muted, blocked. Turned out I only blocked three users, and looking at their usernames, I had no recollection why I did it.

Once I had all the data backed up, again in the Fosstodon account settings, I initiated the migration of the account, providing my GTS account url as the target.

On one screen I had my VPS nginx logs opened, on the second screen it was Firefox, with Fosstodon in one tab, fedi.stfn.pl in the second tab, and Grafana VPS stats in the third. I clicked the magic button and the migration begun.

During the migration, only the people who follow you are automatically migrated. It looked like the followers were being migrated in batches of several tens, and all in all it took maybe two hours for the migration to finish. In Fosstodon I had arround 1140 followers, in fedi.stfn.pl I ended up with around 900. I don’t know what is the reason for that, but I am guessing that maybe some of those 1000+ followers I had were defunct accounts that could not be found by the new instance.

Having migrated the followers, I went to migrate the people I follow. In the GoToSocial account settings I went to the Import tab, and uploaded the corresponding CSV file from the ones I downloaded from Fosstodon. That also took quite some time, but almost all follows migrated without issues.

I decided not to migrate my toots, start with a clean slate, but it is possible to do so, with a tool aptly called slurp, available on GitHub.

Backups

As I mentioned at the beginning of the post, Hetzner provides better tooling than my previous VPS provider, and because of that I stopped using Borg for backups, instead I switched to doing snapshots of the whole server. For now I am doing it manually from time to time, but my plan is to find a way to automate it, maybe using Ansible or some similar tools.

Bottom Line

And that’s it, I am happy I did those two migrations, I feel that it gave me renewed joy in learning the more technical aspects of the Fediverse. And whenever I mentioned the topic of migrating both servers and accounts on the Fediverse I received so many words of encourangement, of good tips, of wishing me luck. The Fediverse has the best crowd of any social medium I’ve ever been on, you people are awesome!

And it looks like Fosstodon will be having a new team of admins and moderators, led by Gina @ fosstodon.org. I wish them all the best and hope they will lead Fosstodon to a bright future as an imporant part of the Fediverse.

As of writing this post, my instance is federating with 8288 other instances. I find it incredible that the number of instances in the Fediverse is in the thousand or tens of thousands!

Thanks for reading!

If you enjoyed this post, please consider helping me make new projects by supporting me on the following crowdfunding sites: