After finishing my exams, I started to look at the misc. tasks which were on my todo list. While messing around on my VM, I thought that it was probably a good time to upgrade to Ubuntu 20.04.
I first checked
For some reason, it listed
eoan instead of
focal as the release to upgrade to.
Because I didn’t have many services running on the VM (only Gitea and ZNC), I
thought that it wouldn’t be a bad idea to start fresh on a fresh VM.
After stopping all the running services,
I moved all the files which weren’t on the attached block storage volume
to the volume (misc files in
/etc/nginx, letsencrypt certificates from
Then, I swapped this volume from the old machine to the new one, and started
docker-compose. This went quite smoothly now
focal source respository for
docker is present.
After that, I disabled the
snap and Oracle related services which were on the
Because my domains pointed to the IP address of the original VM,
I reassigned the reserved IP of the old VM and to the new one.
This turned out to be a good decision, as it became possible to ProxyJump from
the new machine to the old machine using its internal IP address, and I used
this to double check some configuration files (e.g.
Then, it was just a matter of reconfiguring
gitea and the other
relevant pieces (e.g.
znc as an IRC bouncer for
Because I configured the old instance in a rush,
I didn’t bother investigating whether it had a docker image or not
and just let it run on the machine.
This time round, I thought that it would be a good idea to run it as a
container, if only to make the migration process easier the next time.
I referred to the reference for the official docker image and the compose file from linuxserver and adapted it into the following docker-compose file. Note that 6667 is the port which I originally chose.
I renamed the original
.znc folder to
data and ran
immediately running into the following error:
After playing around with the configuration files, I eventually realised that
znc.conf contains a reference to the original location of the
Therefore, I changed the corresponding line to reflect the new location, and
all was well.
Gitea with SSH passthrough
gitea for hosting some of my personal git repositories.
Because it is desirable to use SSH to perform operations on remote repositories,
it becomes necessary to use SSH passthrough to pass SSH from host to container.
Though the guide on Gitea provides a step by step process, it isn’t trivial to set it up correctly.
Here are some strategies for debugging such issues:
- Get the SSH client to output some logs when performing operations on remote repositories. e.g.
When having many SSH keys, use a
~/.ssh/config file to specify the keys that should be used.
- Check the SSH logs (e.g.
/var/log/auth.log). Often, you’ll find something intuitive, e.g.
- Change to the git user (e.g.
sudo su git) and see if the
authorized_keysfile is accessible.