[lug] face plant into glass door...

Bear Giles bgiles at coyotesong.com
Mon Dec 9 09:59:46 MST 2019


An embarrassing story to warn others....

Like many people my home test bench is composed of current desktops/laptops
that I use and older desktops that have been repurposed as servers. For
various reasons I've decided that it makes a lot more sense to install the
server version on these systems and treat them as true servers - nothing
under /home, etc.

Since they're tucked in various corners I don't want to use full-disk
encryption - that requires finding them, hooking up a monitor and keyboard
when they're booting, etc.. In many cases it's not a problem since they do
their thing using a database on a server that does have full-disk
encryption.

The file server holding backups is an exception. The OS can be unencrypted
but I want the partition containing the files to be encrypted. No problem...

... until I actually rebooted. The system started but blocked until I
entered the encryption password. The problem was the LVM volume group
holding the encrypted files - it's marked as 'active' so the system tried
to open it and that requires decryption.

Grrr... so much for "I'll still have to ssh in and manually 'cryptsetup'
the partition but that's better than digging out a monitor and keyboard.)

I haven't decided what to do. I could probably reformat the encrypted
partition as a regular partition, not LVM, but I really wanted to be able
to isolate the usage. E.g., a different LV for backups for each system
instead of one large partition that contains all of them. I could add a
shutdown script that de-activates the VG but I don't know if the nfsd
daemon would prevent that - and it wouldn't matter if there's a prolonged
power hit and the UPS dies.

The main thing I know is that I don't want to push the encryption onto the
file. My home brew software can directly read the encrypted files but it's
a lot slower.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20191209/bad1b19d/attachment.html>


More information about the LUG mailing list