[lug] face plant into glass door...

Mon Dec 9 17:48:52 MST 2019

https://www.cnx-software.com/2019/12/08/rock-pi-sata-hat-targets-rock-pi-4-raspberry-pi-4-nas/

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

> I've seen Seagate 5TB USB3 2.5" backup drives for ~$90. Might be useful as
> the data drives.
>
> If you have enough free sata ports, you might be able to install 3
> internal 2.5" drives by using a 2x2.5" carrier that fits in a 3.5" bay. The
> ones we have take 7mm thick drives.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, December 9, 2019 4:22 PM, Stephen Kraus <ub3ratl4sf00 at gmail.com>
> wrote:
>
> 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
>>
>
> _______________________________________________
> 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/d49df4ac/attachment-0001.html>