| tomreyn | the "green bar" requires EV (class 2), which LE doesn't provide | 00:49 |
|---|---|---|
| tomreyn | also, chrome plans to remove all indications of "secure" anyways, since their take is that (properly done) HTTPS must be the default, anything else is insecure. | 00:50 |
| tomreyn | and in te past mozilla has usually followed up on their lead with some delay. often IE, too, but that's no longer relevant since they'll use chromium anyways. | 00:51 |
| tomreyn | https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html | 00:51 |
| tomreyn | Checkmate, mybalzitch: ^ | 01:07 |
| bindi | is it possible to create encrypted raid1 for system disk with the installer? | 10:21 |
| tomreyn | bindi: yes, but you need to use the alternative server installer or mini.iso. | 11:26 |
| bindi | yeah i got that far | 11:27 |
| bindi | now i'm not sure how I should continue, testing out in a VM atm | 11:27 |
| tomreyn | bindi: dpends a bit on whether you're UEFI or BIOS booting. also the order of crypt layer and raid (and maybe lvm) is something to consider | 11:28 |
| bindi | bios | 11:28 |
| bindi | well my test failed :P | 11:28 |
| tomreyn | in the end it all boils down to how many crypto containers you want to end up with (and how many passwords / keys you'll want to have to provide) | 11:29 |
| bindi | https://i.imgur.com/GNOZ0pK.png | 11:29 |
| tomreyn | for a desktop like computer you probably want just one, maximum 2 crypto containers. | 11:29 |
| bindi | ideally 1 key for all of it | 11:29 |
| tomreyn | then you want raid, then crypto on top, then lvm on top. | 11:29 |
| tomreyn | you may want to have another, smaller raid, just for boot | 11:30 |
| bindi | x_x | 11:31 |
| tomreyn | how large are you storages? | 11:31 |
| bindi | 2x 120GB | 11:31 |
| tomreyn | on the final system, too? | 11:31 |
| bindi | hmm? 2x 20GB i'm testing with in the VM, the final system has two 120GB SSDs I want the system to be installed on | 11:31 |
| tomreyn | i assume lack of separate /boot is what caused your failure here, but i can only guess since i dont know how you partitioned | 11:32 |
| bindi | yeah probably | 11:32 |
| tomreyn | in case you have more than just those two disks on this computer (i.e. separate storages for data), now is the time to think about whether you want 1 crypto container for everything, or one for the Os, and maybe another later for data (or unencrypted there) | 11:34 |
| bindi | I have 8x 2TB but I'm gonna use zfs for those | 11:34 |
| bindi | and I don't feel like zfs on root :P | 11:34 |
| tomreyn | okay, then its just the OS now. | 11:34 |
| tomreyn | take a screen shot of how you partitioned on the next go. | 11:35 |
| bindi | you want me to try and fail again? :D | 11:35 |
| TJ- | bindi: you've got access to the shell haven't you? | 11:36 |
| bindi | sure | 11:36 |
| tomreyn | in the end it's my more and more my impression that you are actually faster if you boot from a live system, do the parititoning with gparted, create and mount all block storage layers (raid and crypto and lvm), then debootstrap, chroot into it, install the kernel. | 11:37 |
| TJ- | bindi: so you can fix-up manually. What layout are you using? | 11:37 |
| bindi | i don't understand the question, i don't know how I should mix lvm+mdadm+whatever to make this work :P | 11:38 |
| bindi | previously I just used the guided FDE with LVM, but now I'd raid1 as well so it can survive a disk failure | 11:39 |
| TJ- | Why not use LVM's own RAID support rather than adding it on top of MD RAID? | 11:41 |
| bindi | I read that that's just mdadm in disguise, but sure | 11:41 |
| bindi | anything that works and anything that *I* can get to work :D | 11:41 |
| bindi | if you could point me to a guide or perhaps do some handholding and guide me through this :P | 11:42 |
| TJ- | You want LUKS to protect the OS root file-system? | 11:43 |
| bindi | yes | 11:43 |
| TJ- | Do you also want LUKS to protect GRUB's /boot/ file-system (prevents someone tampering with the kernel and initrd.img) | 11:43 |
| bindi | nah | 11:43 |
| TJ- | So that leave it vulnerable to a man-in-the-middle attack, you realise? | 11:44 |
| bindi | if its not too complex, could use it | 11:44 |
| bindi | i'm just mostly interested protecting my data against physical attacks | 11:44 |
| TJ- | right, but if you're needing encryption you need to be clear about the attack scenarios you're protecting against. If someone could get physical access to the system, even when powered off, without /boot/ being encrypted they could trivially install a MITM that could log the LUKS passphrase/key-file | 11:47 |
| bindi | sure, encrypted /boot/ it is then, if it doesn't get too complex (in terms of stability and surviving updates :D) | 11:48 |
| TJ- | There's a single setting added to /etc/default/grub "GRUB_ENABLE_CRYPTODISK=y" | 11:49 |
| TJ- | Because of your mirrors I'm trying to figure out the simplest way to arrange things. Are you going to have some LVs/file-systems that won't be encrypted? | 11:50 |
| bindi | no, full disk encryption | 11:50 |
| TJ- | e.g. I have an LV for SourceCode (F/OSS projects I clone/pull in) so I don't bother encrypting that | 11:50 |
| TJ- | bindi: considering easiest first, it'd be LVM first, encryption second so there is only one set of logical volumes to unlock. If it were encryption first, you'd need to arrange for each disk to be unlocked before gaining access to the LVM | 11:53 |
| TJ- | bindi: but that exposes the LVM metadata so is not strictly FDE | 11:53 |
| TJ- | bindi: but if you're only after protecting data (in LVs) then it doesn't sound like you need FDE in its fullest sense | 11:54 |
| TJ- | I'd describe it as needing F.BD.E (Full Block-Device Encryption) | 11:54 |
| bindi | how does the metadata look like? | 11:55 |
| bindi | i probably don't care if anyone sees that :P | 11:55 |
| TJ- | it's the stuff needed by GRUB/OS to discover the LVM PVs VGs and LVs | 11:56 |
| bindi | well as long as it doesnt expose directory structures, i guess its ok | 11:57 |
| bindi | other than maybe /home and / and so on | 11:57 |
| bindi | if you're not 100% sure about how to do this I have a VM I can test everything in before | 11:58 |
| TJ- | so, thinking about OS only (not data) you could do minimal partitioning ( 3 partitions = BIOS Boot, /boot/ file-system, and LVM PV) | 11:58 |
| TJ- | bindi: I've been doing this stuff for 10 years :) It's just a case of thinking of the simplest way to do it including the RAID-1 | 11:59 |
| bindi | btw I don't even necessarily need LVM. I just want raid-1 and FDE :p I never used the features that LVM gives you | 12:00 |
| bindi | if it makes things simpler :D | 12:00 |
| bindi | not 100% sure if its possible without LVM | 12:00 |
| TJ- | I've got a diagram for an arragement like this I wrote 10 years ago, for RAID-5, but it's on a domain I no longer operate; Trying to see if I can jury-rig it so you can see it | 12:01 |
| TJ- | Too much trouble to get that accessible. | 12:18 |
| bindi | :p | 12:18 |
| TJ- | There are pros and cons to using mdadm or pure LVM for the mirror facility. In terms of ease of management if something goes wrong I /think/ mdadm is probably the way to go | 12:20 |
| bindi | so what's next | 12:34 |
| TJ- | I think what you need is something like disks > GPT > partitions (3 of: 1=BIOS Boot, 2=/boot/ for GRUB, 3=LVM) > 3 x RAID-1 (md0=sda1+sdb1, md1=sda2+sdb2, md2=sda3+sdb3), then LUKS encrypt: md1=LUKS_BOOT, md2=LUKS_LVM, then create the LVM with 'pvcreate /dev/mapper/LUKS_LVM' and 'vgcreate VG_OS /dev/mapper/LUKS_LVM' then e.g. 'lvcreate -L 12G -n rootfs VG_OS' | 12:53 |
| bindi | GPT? isn't that related to EFI | 12:56 |
| TJ- | once those are configured and ready the installer partitioner can be used to select the /dev/mapper/LUKS_BOOT for /boot/ FS and /dev/mapper/VG_OS-rootfs for / and at the boot-loader stage dpkg configure step should pop up a dialog asking which devices to install GRUB to, and you choose the two native disk partitions (/dev/sda1, /dev/sdb1) | 12:56 |
| TJ- | GPT makes sense since for your larger disks you'll likely need it anyhow | 12:56 |
| TJ- | so may as well use it across all disks | 12:56 |
| bindi | 120GB? :P | 12:56 |
| TJ- | So? | 12:56 |
| TJ- | I thought you had a bunch of other disks? | 12:57 |
| bindi | they're handled by ZFS | 12:57 |
| TJ- | OK, well still, no reason not to use GPT | 12:58 |
| bindi | but can my BIOS system use that to boot? | 12:59 |
| TJ- | I've not met any that don't in the last decade but you can obviously easily test that with a quick GPT partitioning and grub-install to a USB storage device, for example - doesn't need any OS, just prove BIOS loads GRUB | 13:00 |
| TJ- | benefit of GPT is the secondary back-up table, and you can also create a hybrid MBR if necessary | 13:01 |
| bindi | ok well I don't know how to translate everything you said into actual commands :P | 13:02 |
| TJ- | I have to go out now, if you're still wondering when I get back I can drop a script into a pastebin to help | 13:05 |
| bindi | ok then | 13:24 |
| bindi | TJ-: got my VM to install without errors | 15:23 |
| TJ- | bindi: oh, great, you don't need me then :) | 15:25 |
| bindi | im not just sure if i did it "right". one thing that caused confusion was that "bios boot" partition, as it seems to be a GPT only thing | 15:25 |
| bindi | my VM was Gen1 (BIOS) so there's no such option | 15:26 |
| bindi | I checked an Gen2 VMs have that | 15:26 |
| bindi | but I won't see that in the ubuntu installer then anyway on my bios pc | 15:26 |
| bindi | https://imgur.com/a/7c8DmuC | 15:26 |
| TJ- | Yes, it is where GRUB writes its core image, instead of in the possibly-spare sectors before partition #1 for msdos/MBR partitioning | 15:26 |
| bindi | not sure how I should have named the LV and VG :D | 15:27 |
| bindi | i'm gonna see if this survives a disk failure | 15:27 |
| TJ- | bindi: any way you prefer :) | 15:27 |
| bindi | hm | 15:28 |
| TJ- | bindi: I use LVM extensively so typically I have at least 2 VGs, VG_OS and VG_DATA. VG_OS will have LVs for rootfs, /var/ and /usr/local/, VG_DATA will have an LV for /home/ + several others (I have a generalised mount-point at /home/all/ for things like SourceCode, Projects, Hacking all in their own LVs and with their own /home/all/XXXX mountppoint | 15:29 |
| bindi | looks like it doesnt survive a reboot | 15:29 |
| bindi | err | 15:29 |
| bindi | disk failure | 15:29 |
| bindi | https://i.imgur.com/AewxMlE.png | 15:29 |
| bindi | so my process was flawed :p | 15:29 |
| TJ- | you many not have configured mdadm for boot-degraded, assuming you've got LVM inside MD RAID | 15:30 |
| bindi | check my first imgur link album, 2nd picture 'lsblk' | 15:31 |
| bindi | well I reattached the disk but its not happy | 15:32 |
| bindi | :-D | 15:32 |
| bindi | not sure what went wrong | 15:34 |
| bindi | yeah i think my process is wrong, i dunno how but just removing the disk = no go | 15:50 |
| bindi | i added boot_degraded=true if it even is supported anymore | 15:53 |
| bindi | in /etc/initramfs-tools/conf.d/mdadm | 15:53 |
| bindi | https://ubuntuforums.org/showthread.php?t=2401615 | 15:53 |
| TJ- | Thinking hard about that, I seem to recall it was supposedly made the default, although reading /usr/share/initramfs-tools/scripts/local-block/mdadm the initial assemble command there uses --no-degraded | 15:55 |
| bindi | i just tried to remove --no-degraded from there and update-initramfs, no go | 16:03 |
| bindi | sigh :P | 16:03 |
| bindi | guess i'm not gonna use raid1 then | 16:03 |
| TJ- | bindi: I have servers with mdadm RAID-1 by default and they boot degraded fine, so it's not a general problem. | 16:22 |
| bindi | its the encrypted part | 16:23 |
| TJ- | Yes, LUKS encrypted | 16:24 |
| bindi | well if you can tell me how to get this working it would be neat | 16:25 |
| bindi | if not, im gonna start configuring the server with single disk install | 16:25 |
| TJ- | bindi: well, I have a script that is building a test/demo but just started getting cryptic I/O errors for a non-existent device :s | 19:28 |
| === phunyguy is now known as phunysanta | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
