[lug] face plant into glass door...

[Jonathan Eidsness]

You can run FreeNAS from a USB stick if you want. That would leave your bay
free for storage.

https://www.ixsystems.com/documentation/freenas/11.2-U7/intro.html#the-operating-system-device


On Mon, Dec 9, 2019, 3:38 PM Bear Giles <bgiles at coyotesong.com> wrote:

> 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
>
> _______________________________________________
> 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/7a7cc4ce/attachment-0001.html>