[lug] face plant into glass door...

Mon Dec 9 16:22:16 MST 2019

FreeNAS will also let you setup a mirror between multiple USB sticks for
the OS.

On Mon, Dec 9, 2019 at 6:18 PM Jonathan Eidsness <
jonathan.eidsness at gmail.com> wrote:

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