Demi Nix:
- build1 + build2 vms
- Reduce bare-metal code to something very small, perhaps just vagrant
- That probably means no vagrant for demi1 + demi2
- Reduce bare-metal code to something very small, perhaps just vagrant
- Build the whole VM with nix
- Split the VM image/OS build, and the Demi build
- Perhaps split the VM image build and OS build as well, somehow
- E.g. build grub/initrd into the image, but the rootfs outside
- This will allow rebuilding Demi stuff without rebuilding the OS
- Likely using an external mount
- Or collecting modules into mini-disk-drives
- Perhaps split the VM image build and OS build as well, somehow
- Updates are runtime data, not buildtime
- That means the VM image can be deterministically built from a setup .iso file
- It means OSes should regularly update (unattended)
- It also means rebuilds will be rare
- Alternative: store1 + store2 vms
- All builds happen here, no builds allowed on demi1 + demi2
- demi1 + demi2 can still install, but with store1 + store2 as stores/build
- Alternative (sketchy): build1 + build2 are used for short-lived scripts in qemu
- Alternative: keys1 + keys2 vms
- What if the private CA keys were behind a signing API server?
- Gunicorn+Flask: receives CSR, returns signed certificate
- What are the disadvantages?
- Alternative: short-lived microvm
- Perhaps using the host kernel + Debian image
Debian Cloud image:
- Source: https://www.debian.org/distrib/
Necessary:
- Cron job to query http://192.168.15.1/cgi-bin/public-ip and update demi-ns.dynv6.net
Workflow:
- Install something on metal hosts (manually)
- Ansible, or qemu, or make, or vagrant
- Generate secret SSH/SSL keys (perhaps on both hosts)
- This cannot be done with Nix, but Ansible should be okay
- Generate public SSH/SSL keys basd on secret keys
- This cannot be done with Nix, but Ansible should likewise be okay
- Wait... what? Do I put private SSH host keys in the Nix store?
- Do I mount the private SSH host keys from the actual host?
- Do I make a .qcow2 of the private SSH host keys?
- Do I pass it through cloud-init metadata (top-level ssh_keys, sibling to users)
- That won't work for SSL keys; but is that important?
- Create a VM
- Set up ansible user with sudo and local .ssh/id_rsa.pub in authorized_hosts
- Set up /etc/hosts
- Does it need /mnt/persistent?
- Set up SSH CAs
- config.programs.ssh.knownHosts.cert-authority (this is ssh (global), not sshd)
- https://git.sr.ht/~mchrist/dotfiles/tree/master/item/nixos/modules/ssh.nix