[lug] face plant into glass door...

[Orion Poplawski]

On 12/9/19 9:59 AM, Bear Giles wrote:
> 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.

You could look into clevis/tang to automatically unlock the system via a
network server.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20191209/60e7bc64/attachment.bin>