[lug] face plant into glass door...

Wed Dec 11 11:50:06 MST 2019

For 3.5" drives this might be interesting:
[    https://store.pine64.org/?product=rockpro64-metal-desktopnas-casing](https://store.pine64.org/?product=rockpro64-metal-desktopnas-casing)
Looks like you need to add a PCIe SATA board:
[    https://store.pine64.org/?product=rockpro64-pci-e-to-dual-sata-ii-interface-card](https://store.pine64.org/?product=rockpro64-pci-e-to-dual-sata-ii-interface-card)

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, December 11, 2019 11:29 AM, David L. Willson <dlwillson at thegeek.nu> wrote:

> That's cool. I wish the case was 3.5". I have a bunch of drives sitting here, waiting for a cozy home like that.
>
> ---------------------------------------------------------------
>
> From: "Stephen Kraus" <ub3ratl4sf00 at gmail.com>
> To: "duboulder" <blug-mail at duboulder.com>, "BLUG" <lug at lug.boulder.co.us>
> Sent: Monday, December 9, 2019 5:48:52 PM
> Subject: Re: [lug] face plant into glass door...
>
> 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
>
> _______________________________________________
> 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/20191211/efb1b928/attachment.html>