[lug] face plant into glass door...

[Bear Giles]

I can make nfsd is brought down before calling 'vgchange -an'. It won't
protect me from a power crash but can use this as motivation to actually
hood up aspd(?) - the daemon that listens to the USB port on a UPS and
sends a 'shutdown' message once the UPS kicks in, or at least after N
minutes.

It's a fairly straightforward setup. I had soft plans to set up FreeNAS but
my refurbished dell only supports one 3.5" drive or two 2.5" drives and
FreeNAS requires at least two drives since the data drives are dedicated
entirely for data. So for now I'm just running of the WD Red drive. It has
a moderately large standard partition containing Ubuntu 19.04 server and
the rest is an encrypted LVM partition containing a single VG. I've been
carving LVs out of it.

This system will also have an encrypted external drive attached to it but
that's not important here.

The first LV carved out are for my backup partitions. The system 'foo' has
a /backups directory that's actually NFS-mounted from /backups/foobar. When
I have my act together access is limited to that system - even if a system
is compromised the bad actor can't (easily) erase the backups for all
systems. They can't even fill the backups partition and prevent other
backups from being performed. The backup itself is a simple tar script.

In the past I've experimented with the script auto-mounting and -unmounting
the backup partition. I might try that again.

On Mon, Dec 9, 2019 at 2:08 PM duboulder <blug-mail at duboulder.com> wrote:

> Can your initramfs be configured to read the passphrase from a thumb
> drive? cryptsetup can read passphrases from a file. Or do you have
> decryption system-init scripts that can use keys on removable drives? In
> that case try using an empty passphrase for the initrd decryption prompts
> and then configure your system init decryption to run before LVM and local
> fs mounts. And if possible rebuild/configure the initramfs to skip
> encrypted devices.
>
> As you noted shutdown can be a problem. NFS exports prevent a filesystem
> from unmounting and thus the related VG from deactivating. But it takes
> more than deactivation of the VGs on the encrypted device to allow
> cryptsetup to close the partition. The PV must also release its reference.
> Not sure if pvchange -xn is enough to allow closing the encrypted block
> device. Then you might need to do pvchange -xy on the next boot.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, December 9, 2019 9:59 AM, Bear Giles <bgiles at coyotesong.com>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20191209/18d189dd/attachment.html>