[06:21] <lordievader> Good morning
[13:53] <TJ-> anyone think of a relatively painless way to have a server's LUKS-encrypted /boot/ content mirrored to another, TFTP, server, such that grub/kernel updates get replicated from the host to the remote so that this host can also do TFTP boot over the network - looking at using DRDB with onw half of the mirror on the localhost and the other on the TFTP server
[13:54] <TJ-> I *think* localhost would have to do e.g. /dev/sda3 > LUKS > DRDB > ext4 > /boot/ rather than /dev/sda3 > LUKS >ext4 > /boot/
[14:26] <sdeziel> TJ-: I'd probably use DRBD too but I don't know how easy it is to wire it into the boot logic
[14:26] <TJ-> it doesn't need to be. it just needs to be there when the OS is running so any updates get written to the TFTP server as well
[14:26] <TJ-> I'm almost finished configuring it now; will test shortly
[14:26] <sdeziel> TJ-: a possible alternative would be mdadm raid1 with a NBD disk as the mirror in (write-mostly)
[14:28] <TJ-> the idea is for a low power Raspi battery-backed survives a site power outage. The APU2 gateway (x86) doesn't and is LUKS encrypted and would require serial console to GRUB to unlock /boot/ ... the aim is to set the system to try a PXE boot first, and if a PXE server responds, then it'll boot over the network and not need GRUB unlocking.
[14:29] <TJ-> Raspi will monitor the state of the ethernet link between them and enable/disable dnsmasq when link goes down/up so it isn't always doing a TFTP boot
[14:30] <TJ-> so a regular APU2 reboot, with the switch remaining powered, won't cause raspi to start dnsmasq
[14:34] <rbasak> TJ-: this sounds awfully complicated and error-prone to me. Can you expand on the actual problem you're trying to solve here?
[14:38] <TJ-> rbasak: unlocking grub at boot time on an unattended gateway
[14:42] <rbasak> TJ-: what's your threat model?
[14:45] <TJ-> no gateway
[14:48] <rbasak> No - I mean why LUKS and also providing a method to bypass it? What's your threat model that requires LUKS but permits the bypass?
[14:48] <rbasak> Because there might be other solutions, but without understanding your threat model that leads you to that, it's difficult to suggest anything.
[14:51] <TJ->  literally, and figuratively. LUKS protects against there being no gateway (stolen). But device needs to be able to fully reboot since it is the gateway
[14:53] <rbasak> So don't use LUKS then? I'm playing devil's advocate here. What's the difference? You're OK with providing automatic unlocking if something has not had a power outage? In that case, won't Mandos work?
[14:53] <rbasak> Benefit is that it's less hackery.
[14:54] <TJ-> LUKS is protecting sensitive info
[14:54] <TJ-> no, LUKS is applied at the bootloader stage
[14:55] <rbasak> LUKS is protecting nothing if you happily hand over everything needed to unlock it over the LAN!
[14:56] <rbasak> If you consider "can get to the LAN" as "safe to unlock" under your threat model, then Mandos works without any less security.
[14:56] <leftyfb> TJ-: put the gateway on a UPS? ;)
[14:57] <TJ-> leftyfb: unfortunately not practical in this scenario
[14:58] <TJ-> Mandos doesn't protect against someone dropping a payload in the unencrypted /boot/ and collecting the data later. 
[14:59] <rbasak> Nor does PXE booting first, where anyone on the LAN can MITM whatever they want.
[15:00] <TJ-> rbasak: but we'll know if there is any other device on the LAN, that isn't a problem. 
[15:02] <rbasak> TJ-: that's a brave assumption.
[15:03] <rbasak> A switch with some MAC filtering will bypass that.
[16:15] <TJ-> seems that drbd cannot handle link-local addresses, despite recommending not to route and only connect on a local segment!
[16:19] <TJ-> rbasak: these things are outside, on top of very tall telegraph poles. 
[16:43] <TJ-> strange, drbd Changelog says for 8.3 Improved IPv6: link local addresses. Kernel has 8.4.11
[18:24] <TJ-> Turns out there's a bug in drbd-utils - cannot handle "fe80::" style addresses - have to expand the :: fully dso "fe80:0:0:0:..."