• 8 Posts
  • 13 Comments
Joined 2 年前
cake
Cake day: 2024年3月14日

help-circle

  • I’ll go first - I’m working on the reliability of some migration patterns between a couple managed cloud implementations. A bring-your-own-account model underpinned the legacy setup, while the newer cloud offering allows us to retain it all in our accounts.

    This is on top of generally sussing out the reliability of the newer product with some chaos testing.

    The unfortunate bit is that my OPS workload is so high that I struggle to get much traction on the above. Not to mention that this new product moves so fast that it’s hard to get any sort of week-to-week consistency. Often requiring environment re-provisioning. Not exactly stuff that the community can really help with, but hey, that’s what’s on my plate.



  • Definitely not that lucky. We have customers who seem to watch dashboards and create a Sev1 anytime latency degrades by 10%. They explain to their account manager that they need to have perfect performance all the time. The AM then comes to us demanding that we increase the sensitivity of the alert. Management agrees. And then, voila, just like that we have an alert that flaps all day and all night that we aren’t “allowed” to remove until someone can show that the noise is literally stopping us from catching other stuff.

    It’s insanity.

    EDIT: I only stay because new leadership seems like they want to fix it earnestly. And things are headed in the right direction, but it takes a long time to turn a ship.



  • The real kicker is that I’m fairly sure we aren’t really using them at any real scale - if we do it’s to demo our product within the context of AI development. So if anything, they get a lot of free press when we do that. If they’re gonna throw a fit over it, I’m sure we can work with some other “AI” company (that’s what they bill themselves as) that wants the free marketing. Heck, I can’t imagine the anaconda ecosystem working out if they keep threatening the developers that enrich that ecosystem.








  • This sounds like a lenovo machine. Or something with a similar MOK enrollment process.

    I forget the exact process, but I recall needing to reset the secureboot keys in “install mode” or something, then it would allow me to perform the MOK enrollment. If secureboot is greyed out in the BIOS it is never linux’s fault. That’s a manufacturer issue.

    Apparently, some models of Lenovo don’t even enable MOK enrolment and lock it down entirely. Meaning that you’d need to sign with Microsofts keys, not your own. The only way to do this is to be a high-up microsoft employee OR use a pre-provided SHIM from the distribution.

    https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_a_signed_boot_loader

    For that case, Ubuntu and Fedora are better because, per the Ubuntu documentation they do this by default.

    On Ubuntu, all pre-built binaries intended to be loaded as part of the boot process, with the exception of the initrd image, are signed by Canonical’s UEFI certificate, which itself is implicitly trusted by being embedded in the shim loader, itself signed by Microsoft.

    Once you have secureboot working on Ubuntu or Fedora, you could likely follow these steps to enable TPM+PIN - https://wiki.archlinux.org/title/Systemd-cryptenroll#Trusted_Platform_Module

    There might be some differences as far as kernel module loading and ensuring you’re using the right tooling for your distro, but most importantly, the bones of the process are the same.

    OH! And if you aren’t getting the secureboot option in the installer UI, that could be due to booting the install media in “legacy” or “MBR” mode. Gotta ensure it’s in UEFI mode.

    EDIT: One more important bit, you’ll need to be using the latest nvidia drivers with the nvidia-open modules. Otherwise you’ll need to additionally sign your driver blobs and taint your kernel. Nvidia-Open is finally “default” as of the latest driver, but this might differ on a per-distro basis.


  • Yeah, no kidding. The same systemd that enables the very things OP is trying to enable…

    systemdboot + sbctl + systemd-cryptenroll and voila. TPM backed disk encryption with a PIN or FIDO2 token.

    AFAIK this should be doable in Ubuntu, it just requires some command-line-fu.

    Last I heard the Fedora installer was aiming to better support this type of thing - not so sure about Ubuntu.