Petal's data directory (petal.db, uploaded images, and the TTS cache --
which is synthesized audio of her sentences) now lives on a LUKS volume.
LUKS-on-a-file rather than gocryptfs because Petal is SQLite in WAL mode:
WAL needs a shared-memory index mapped consistently across processes, and
FUSE has a long history of subtle mmap/locking differences. A block
device with ext4 behaves exactly like a disk to SQLite.
The key sits on the same host, which is a deliberate availability
tradeoff and is documented as such: it stops a decommissioned disk or a
raw block-device read, not anyone holding the whole VM image.
Two bugs found by rehearsing a reboot rather than trusting the setup:
- Mounting over a directory HIDES its contents, it does not remove them.
The first run left the original plaintext petal.db and WAL sitting on
the unencrypted root filesystem, invisible under the mount -- exactly
what the exercise was meant to eliminate. Now shredded before the
mount, with a refusal if the mountpoint will not come up empty.
- systemd-cryptsetup was not installed on the host, so /etc/crypttab was
being ignored entirely and the volume would never have unlocked at
boot. The script now refuses to run without the generator present.
