On Mo, 04.07.22 15:59, Gerd Hoffmann (kraxel@xxxxxxxxxx) wrote: > Hi, > > > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf > > Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like > being at proof-of-concept state. mkosi going fetch stuff from the > internet to generate the initrd is clearly a non-starter (maybe not that > much of a problem when doing it in koji where the next fedora repo is > only one network hop away). Well, we didn't find any better tools, i.e. with all the verity stuff and signing in place. mkosi is just a wrapper around dnf, it's not really that smart... If it is fine building any kind of RPM-based image on fedora infra this shouldn't be any different... we tried to make rh image builder people inetreested in that, but they weren't interested in that at all. > I don't think mkosi is a hard requirement for unified kernel images > though. No, it's not. mkosi is just a python script gluing all the dnf, gpt, fdisk, verity, signing stuff together. You can reimplement that. > Once the local configuration issues are solved it should be > possible to run "dracut --no-hostonly" in koji + ship results instead > of doing it on the installed host, no? We want to build initrds from RPM, to make the reasonably reproducible and follow proper deps. It's a major facet of the project. magic build scripts trying to magically determine deps from ELF and config and whatnot is kind what we want to get away from. > > The credentials logic can also be used to for example pass a root pw > > for the initrd in a safe way. > > Does systemd-cryptenroll use this? Use what precisely? the root pw? no, why would it? or the credentials api? i mean, there's no direct hookup, but we don't really need it: from the service side credentials are just files in the file system, and we do support reading keys from that. > When getting the credentials for the encrypted root filesystem (or > something else) from somewhere else, i.e. some attestation server such > as https://keylime.dev/, how could that be integrated with systemd-creds > best? Simply have the agent write to /run/credentials? I don't know keylime. But note that service credentials can be read from a variety of sources: most prominently regular files on disk you specify via an fs path. Now one tweak here is that if you actually specify an AF_UNIX socket inode in the fs as fs path, then we'll connect to it, and read the credential data from it. This is a flexible way to plug anything you like into the service credential logic: all keylime has to do is bind a socket somewhere, with tight perms, and then whenever a connection comes in just write the credential data into the connection and close it right after. > > My expectation would be that by default we'd just use the GPT auto > > discovery stuff and for "pet" systems maybe also encode the root > > device with a credntial, but for "cattle" systems not bother. > > Yep. > > Is there some fallback mechanism btw? Most cloud images have just four > partitions: bios-boot, efi esp, boot and root. And the root filesystem > is simply the largest partition ... Actually, the implementation of the gpt auto logic (at least on some contexts) is somewhat tolerant: if the partitions are not properly tagged (i.e. use generic type uuids) but there's only a single one that would be a candidate, then it will be used as root fs. We refuse working that way though once you have two entirely generic partitions and we thus have no clue which it could be... But why not just fix the cloud images to just use descriptive type uuids? that has no drawbacks, just benefits. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
