💾 Archived View for thfr.info › gemini › migrating-servers.gmi captured on 2023-06-14 at 14:03:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Self-link; subscribe for updates to this page.
I'm in the process of preparing to migrate Gemini servers. This is a journey for me to learn how to do this, so I'm chronicling some things that I learned here. When all is ready, playonbsd.com will move from the current Vultr server to OpenBSD Amsterdam - for more storage space and more "OpenBSD-ness" of the whole project.
What is a server without content? Not much, if you ask me. Moving the files from the current server is therefore an early priority.
The static files are the easy part - I just used rsync(1) from ports to move files:
$ rsync -avH [source] [destination]
The dynamic content, mainly the use of shell scripts and cron jobs to update the content will be trickier.
The fundamental question is whether to attempt to reuse the certificate of the old server. This has some philosophical problems. I also want to switch to a smaller elliptic curve key, so that's another reason for a certificate change.
I would love to use Ed25519. As a crypto amateur, I can't really speak to any specifics, but its usage and promotion has become significant. It is said to avoid some ot the concerns with other elliptic curve keys where concerns about possible backdoors have been voiced.
A more qualified discussion of Ed25519 than I will ever be able to give
One big reason for me to switch keys is the significant smaller secure key size compared to RSA. It just feels wrong to use a 4096 bit RSA key with every gemini page request to the server. Many pages are smaller than such a key, which is just wasteful if you think about it, especially if you run a capsule that doesn't include very sensitive content.
Sadly, the latest OpenBSD 7.2 that I'm running on the new server doesn't have the capability in libcrypto to handle Ed25519 yet.
OpenBSD src commit enabling Ed25519 in libcrypto
I'm still in the process of figuring out my approach; maybe I'll use ECDSA or a smaller RSA key as a temporary solution until the OpenBSD 7.3 update in spring.
Testing my server proved more difficult than expected. After moving the files onto the new server, installing and running gmid from ports, I found myself running into SNI errors when trying to have the content served to my laptop. Error 53, to be specific.
This kept happening with different gemini clients. Fortunately, ew0k on #gemini IRC pointed me in the right direction. Thanks to his advice, the following helped me to test the gmid client of the new server:
1. On the _client_ computer, edit /etc/hosts
2. Add a line with your IP and planned web address:
xxx.xxx.xxx.xxx playonbsd.com
3. Open playonbsd.com in a client - this will be resolved to the IP xxx.xxx.xxx.xxx without going through the DNS.
4. DO NOT FORGET TO REMOVE THE LINE AGAIN when done with testing!
Here is another source that describes this approach for other use cases:
Using an /etc/hosts file for custom domains during development