nixos-config/machines/okarin
Simon Bruder 16cf73afb9
okarin: Migrate to different VPS
Previously, it was hosted on Ionos’s VMware-based infrastructure. I
already had a VPS on their new KVM-based infrastructure, as I was
planning to migrate okarin to it eventually (as it is cheaper). However,
the new infrastructure does not offer PTR records for IPv6 addresses.
Therefore, I was waiting until they would implement that feature (as the
support promised me they would to in the near future).

However, they are now migrating the (at least my) guests from their
VMware hypervisors onto the KVM ones, assigning new IPv6 addresses to
them. This makes the old VPS essentially the same as the old one, but
with less memory and more expensive. So I decided to migrate now.
2024-04-17 12:40:46 +02:00
..
services okarin: Migrate to different VPS 2024-04-17 12:40:46 +02:00
README.md okarin: Migrate to different VPS 2024-04-17 12:40:46 +02:00
configuration.nix okarin: Migrate to different VPS 2024-04-17 12:40:46 +02:00
hardware-configuration.nix okarin: Migrate to different VPS 2024-04-17 12:40:46 +02:00
secrets.yaml okarin: Migrate to different VPS 2024-04-17 12:40:46 +02:00

README.md

okarin

Hardware

Ionos VPS Linux XS S (1 Xeon Skylake vCPU, 1GiB RAM, 10GB SSD).

Purpose

It will host services I want to have separated from the rest of my infrastructure.

Name

Okabe Rintaro is a mad scientist from Steins;Gate

Setup

Much like the namesake, this server requires a “mad scientist” approach to set up. However, it is much easier than setting up its predecessor, which had just above 400MiB usable memory.

Ionos does not offer any NixOS installation media. I could only choose between various installation media and rescue systems. Also, installing NixOS with a low amount of memory is problematic.

I therefore created a VM locally with a disk image exactly 10737418240 Bytes in size. On there, I installed NixOS. Because encryption with argon2id as PBKDF is quite memory intensive, I had to tune the parameters to ensure decryption was still possible on the target. This can be done quite easily by interactively running the following command on the build VM:

cryptsetup luksChangeKey --pbkdf-memory 100747 --pbkdf-parallel 1 --pbkdf-force-iterations 29 /dev/vda3

The memory size was obtained by a successful run of cryptsetup benchmark inside the initrd on the target.

However, since those parameters are not ideal, the following should later be run on the target host itself:

cryptsetup luksChangeKey --pbkdf-parallel 1 -i 10000 /dev/vda3

This will determine the memory usage automatically, use one thread and set the parameters so that decryption takes 10 seconds (10000ms). The memory usage will not be as high as it could, but it will be better.

Getting the disk image onto the server was done by first rsyncing the image to another server (to allow for incremental iterations), which then provided it via HTTP. Using the Debian installation media in rescue mode (as for some reason most other options tried to cache the file in memory and became very slow) it was possible to write the image to disk with wget -O /dev/sda http://server/okarin.img.

Because of all the pitfalls of this, you probably need more than one try. To make debugging easier on the target, the following option can be set:

{ pkgs, ... }:

{
  boot.initrd.preLVMCommands = ''
    ${pkgs.bashInteractive}/bin/bash
  '';
}