You probably want to try "debian-cloud-images" from Sid, which has the necessary depends. Simply run "debian-cloud-images" as root to build. The git repo for it is here: https://urldefense.proofpoint.com/v2/url?u=https-3A__salsa.debian.org_cloud-2Dteam_debian-2Dcloud-2Dimages&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=ZscEEr9nw3LSVvXoPtSeEPOB99CD0eOeziaYFoP_AX8&m=-34uL1oDIDf-Qk7EraeGZWpkAsqHzDKp639xZeJzYh8&s=M3gsAFhrzgsHFJBt-kSP5nruFyjaDZLxqHQR7A-8u8A&e=
That worked perfectly, thank you.
Off the top of my head, the changes for distributions so far are pretty straightforward: * UEFI * a few iscsid configuration parameter changes (a few tweaks we've found improve reliability and performance) * specific firewall configuration (iscsi root without CHAP would enable anyone to modify iSCSI drives, so we lock it down via iptables) * NTP config (we're looking to get details in to metadata shortly, so may not be necessary)All of the above seems to either already be there (ie: UEFI), possible to contribute (specific iscsid configuration enhancement), or needed to be executed at runtime (firewall config IMO shouldn't be part of the standard image, neither NTP).
Based on comments in that debian-cloud-images repository, it looks like you're favouring Chrony these days instead of NTP, which is good with me, particularly from a security perspective.
I may be misunderstanding your comment, but so far as runtime vs baked-in, we've been attempting to make everything as secure as possible from the get-go, and assume that customers ignore any good practices or suggestions we document. Given the security risk of the iSCSI endpoint, we don't want to be taking risks there. Putting it in via cloud-init isn't entirely straightforward, and then introduces the possibility of unintentionally nuking what customers have done to an instance before taking a custom image, that they then use to provision other instances.
There's nothing too onerous in there. We're starting to offer our own instance agent for emitting metrics, which we're just in the process of open sourcing.It's IMO best if there's no intrusive agent in an image.
It's not all that much different from Google's instance agent that comes installed on their instances. From a personal perspective, I tend to favour "do as little as possible", and I'm firmly in the "If it ain't there, it can't be compromised" camp. With the images we produce, we've been definitely trying to avoid doing anything beyond the default as much as possible. From a pragmatic perspective, Oracle's primary customers are enterprise ones that tend to expect things to "just work", correctly, straight out of the box. They don't want to be configuring NTP/chrony themselves, they don't want to be installing instance agents etc.
With bare metal instances in the picture, and being a particular desire for our customers, we can't just take hypervisor metrics, like Amazon does, yet we need to also provide auto-scaling and similar services that rely on metrics being emitted. Putting an instance agent on the box gives the customers the power and control to make their own decisions. Being installed via normal package mechanisms, if they don't want it, it's an easy uninstall.
We do provide a launch options via the API (and in the web console) that allow customers to enable or disable features in the instance agent, with the configuration spit out via a metadata endpoint that the agent checks on start-up.
In reference to "runtime" configuration above, and in keeping with "do as little as possible", part of the intent with the instance agent is to have the agent become responsible for initial run-time configuration for features outside of cloud-init.
We've been installing this direct via RPMs (and soon via snaps for Ubuntu), but we can certainly look in to getting it in to the debian repositories.If it is mandatory to have one, then it *must* be in Debian. Buster is soon frozen, so you don't have time to loose here. It would not be acceptable to push Snaps in the official Debian image.
Thanks for the heads up. I've pointed co-workers towards the maintainers documentation, https://www.debian.org/doc/manuals/maint-guide/, that seems to be the right place to start getting to grips with the process. We'll get working on it.
Would it be acceptable to be installing the instance-agent as a deb package via cloud-init, on start-up?
I've tried the official openstack image, but I'm having a littledifficulty getting it to boot. I haven't spent much time investigating there. At first blush it looks like lack of UEFI (maybe there is an alternate image that already supports UEFI?).There's indeed no UEFI support in the image, even though the tool that creates the image could do it. The problem was, at the time, that we had no way to produce an image with Grub working with both UEFI and regular BIOS. My understanding is that "grub-cloud", produced by Waldi (Bastian in this list) fixes the issue. Though of course, that's not yet available in Stretch, and we hope to fix this for Buster. Cheers, Thomas Goirand (zigo)
I see various references to grub-efi in the debian-cloud-images repository, I'll try spinning up some other images and see what I get.
I'd like to make sure we're singing from the same hymn sheet. What's the route forwards? Do we do the work and provide patches for review, do we need to be contracting with the Debian group to get the work done, or is the route forwards something else entirely?
Paul