💾 Archived View for talon.computer › log › migrating-forgejo captured on 2023-09-08 at 15:56:18. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
2023-09-01
So I recently setup a public Forgejo instance on the cheapest VPS I could get from Vultr and unsurprisingly it would fall over all the time. At first because the disk space was very low and the Forgejo cron for deleting repo archives wasn't running. I'm still not totally sure why the repo archives popped off as hard as they did but once I explicitly enabled the cron in /etc/forgejo/app.ini that became less of a problem.
But I also have a decent amount of mirrors from other FOSS projects (a cron task that was working just fine the whole time, mysteriously...) and that's my best guess as to why still sometimes the box would get overwhelmed and fall over from CPU/RAM limitations.
Fortunately I share another VPS with @swaggboi that runs an instance of Lemmy. Lemmy requires a miniscule amount of CPU and RAM so having Forgejo move in, we agreed, wouldn't be a problem. The only sad part is now I had a migration on my hands. Ultimately though it went smoothly and wasn't so painful.
The journey was two parts: installation on the target VPS and migration from the deprecated VPS.
I followed the "Installation from binary guide" on the Forgejo website.
The guide is concise but complete which I like. It helps that the actual steps are super simple. You download the latest binary and move it to /usr/local/bin/forgejo. Then ensure git is installed and there's a git user and group for use.
The previous VPS was Arch linux and forgejo is packaged for you over there however one thing that always bothered me was that it runs as the user forgejo which makes all the repository SSH urls forgejo@<url>. I was happy that the "offical" guide uses the git user so that the urls are git@<url>... it just looks better. Also what if Forgejo has a hostile takeover and I have to switch to a new fork!
read about Codeberg forking Gitea to create Forgejo
So anyway /etc/forgejo and /var/lib/forgejo are owned by git on the new VPS. I created those manually and used chown and what not.
I also created a new database in the already existing postgresql (from the Lemmy install) for Forgejo. Again following the official guide which has copy and pasteable commands for this. I am not good with databases (YET!) so that was nice. In postgres, the forgejo user is used. This is reflected in the pg_hba.conf and I'm mostly just noting it cause it's not the git user from the system. It's the forgejo user in postgres.
Finally the guide has a downloadable template for the /etc/systemd/system/forgejo.service file. I just had to, as noted in the guide, go and uncomment the postgres specific lines.
Now I could run Forgejo on the new VPS but it would be totally empty! The next move was to go get the data from the old VPS to fill up the new one!
The /etc/forgejo/app.ini file is simple enough to copy to the new host. I changed the RUN_AS user to git and added a forgejo DB password, the Arch package didn't have a password. The new password is nothing strong.
For now the target VPS still just has one /etc/caddy/Caddyfile but the forgejo config to point at the socket file is about three lines so I simply appended it. The most notable thing is that I had to add the caddy user to the git group so it could read the socket. That took like an hour to debug.
/var/lib/forgejo required patience only because it was 6Gb and I accidentally did that from my PBP which has a max WiFi transfer rate of 433Mbps... otherwise it was rsync down from the old VPS and rsync up to the target VPS.
And finally pg_dump got me a .sql backup from the old VPS and pgsql on the new host was able to gobble that up into the database lickity split.
Amazingly the first time I used systemctl enable --now forgejo it worked! And I was logged in to Forgejo like nothing had happened except now it lived on a faster host!
But then another thing that took awhile was figuring out I needed /etc/tmpfiles.d/forgejo.conf which I didn't question too much (@swaggboi sent a link about /etc/tmpfiles.d) but with the right spell inside, that file will ensure /run/forgejo exists across reboots with the correct permissions. The spell I used is this:
D /run/forgejo 0770 git git
That should have been an installation step but I discovered it later, post reboot. After that resolve the service runs fine and I look forward to using it successfully until the next odd maintenance need! Until then ✌️
