Encrypted system configurations you can unlock with one password prompt

Note: native ZFS encryption supports a passphrase keyfile which contains a passphrase instead of random bytes. ZFS doesn’t support multiple key slots, but if you lose the passphrase keyfile, you can reconstruct it from your memory.

Note: I suppose raw-initrd allows you to use dropbear ssh server for remote password prompt.

root filesystem on one LUKS device

  • /dev/sda1
    • FAT32 /boot partition for grub and EFI
  • /dev/sdb2
    • btrfs on LUKS
    • It contains a keyfile for unlocking itself and other encrypted filesystems
  • Other disks
    • encrypted ZFS or ZFS on LUKS or btrfs on LUKS

root filesystem on two LUKS devices

  • /dev/sda1
    • small LUKS partition without file system
    • It is the keyfile for unlocking /dev/sdb2 and /dev/sdc2.
  • /dev/sda2
    • FAT32 /boot partition for grub and EFI
  • /dev/sdb1 & /dev/sdc1
    • unencrypted /gnu/store on btrfs raid1
  • /dev/sdb2 & /dev/sdc2
    • / on btrfs raid1 on LUKS
    • It contains a keyfile for unlocking other devices.
  • Other disks
    • encrypted ZFS or ZFS on LUKS or btrfs on LUKS

Is this implemented, or is there a Guix module for this ?

Thanks!

I haven’t implemented them, but according to my thought experiments, gnu guix should support those configurations without any extra module.

Read mapped devices section in the gnu guix manual.

To mount ZFS file systems outside /, /boot, and /home, you will have to write zfs services. Gnu guix doesn’t have zfs services, yet.

Oh, okay. I don’t care about ZFS, just being able to remotely unlock the hosts when they boot, something like this in NixOS.

I guess you will have to use dropbear ssh server in initrd.

You can also use IP KVM to avoid complex initrd setup.

IP KVM is going to be more robust than dropbear ssh server.

Thanks for the hint.