nixos-config/machines/okarin/README.md
Simon Bruder d93d724b9f
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-06-01 13:57:33 +02:00

72 lines
2.4 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!--
SPDX-FileCopyrightText: 2023-2024 Simon Bruder <simon@sbruder.de>
SPDX-License-Identifier: CC-BY-SA-4.0
-->
# okarin
## Hardware
[Ionos VPS Linux XS](https://www.ionos.de/server/vps) 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 `rsync`ing 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:
```nix
{ pkgs, ... }:
{
boot.initrd.preLVMCommands = ''
${pkgs.bashInteractive}/bin/bash
'';
}
```