[lug] face plant into glass door...

[Maxwell Spangler]

Hi,
Can you provide more technical details on your configuration?
I run three headless NAS units that have unencrypted OS but definitely
multiple encrypted data filesystems.
Rebooting for me requires blindly rebooting them as they don't have
keyboard/video/mouse connected at all, waiting for SSH availability,
then logging in and manually running a script that does 'cryptsetup
luksOpen' to make encrypted volumes available and mount the
filesystems.
The peace of mind this brings -- knowing that if they were stolen my
data is fairly protected -- is completely worth the effort to configure
and boot.
I'm running CentOS 7, with an LVM volume group for the OS only, so
booting is simple and straightforward.
My encrypted filesystems are either mdadm based RAID 1 mirrors or
straight encrypted partitions on specific drives. I open the encrypted
devices with cryptsetup then mount as a normal block device.
This has worked really well for about 8 years now, so I'd encourage you
to stay on the right track, just adjust the OS installation so its more
isolated from the data.
On Mon, 2019-12-09 at 09:59 -0700, 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.
> 
> _______________________________________________Web Page:  
> http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667
> channel=#hackingsociety
-- 
Maxwell Spangler

===================================================================
Denver, Colorado, USA

maxwellspangler.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20191209/051e65c5/attachment.html>