netboot.xyz VS cloudinit

I learned about https://netboot.xyz/ the other day. Worked fantastic when I didn't have a big enough thumb drive. Not exactly the same though.

I replied to a reply of yours with this same info, but since you’re both sorta asking the same thing, I’ll post it here for you also.

https://netboot.xyz/

https://github.com/netbootxyz/netboot.xyz

Knew about http://netboot.xyz, but had no idea iVentoy existed. Good to know.

Set the computer to PXE boot, or use a boot image with iPXE (such as netboot.xyz). That would quickly rule out a problem with Debian or the Linux kernel (at least until you download and boot one). I don't know anything about your network setup, but making sure DHCP is enabled on your router and there are enough unreserved IP addresses would probably help.

Hey thanks for the detailed response. You're saying you boot FCOS on bare metal over PXE, correct? I've thought about trying that approach, but have little experience with PXE and TFTP. I just checked out netboot.xyz and it looks surprisingly easy to get going. Last time I played around with PXE I used Synology's TFTP server and, while I got it working, I was more confused by the end than when I started. I think actually learning PXE end-to-end and understanding what I am doing there would be a solid foundation for building my environment the right way.

For netbooting we rely on a netboot.xyz inspired ipxe based setup.

[[UPDATE]]: The fix was as 'simple' as going into the 'bios', and selecting 'add a boot option', which automatically came up with the correct EFI file/path, then putting it at the top of the boot order. 'Simple' it wasn't, many new and temporary instances brought online while digging my way through it all, and finally just going with a brand new Debian Bookworm and migrating my data over from the old disk file. At least I learned a lot about recovering from this weird circumstance. The incorrect EFI file/path must be an artifact of using netboot.xyz to install Deb Bookworm over a previously provisioned Ubuntu instance. Makes sense I guess. Still loving netboot.xyz as a super fast way to spin up an unsupported OS.

I learned about GRML only a few years ago. Absolutely love the mixture of power and minimalism. Here is the only ISO which increases my mileage even more: https://netboot.xyz

Newer versions of OS use cloud init -> https://cloud-init.io/

Overall, I think in an article that focuses on cloud computing (specifically AWS) there's too much time being spent in the local command line of a server.

It's an especially revealing sentence when the authors says that "Most attacks won’t be against what we’ve covered in this guide, but against the applications you install next. Properly done, containers can limit the impact."

If we are running containerized applications and we are already in the cloud, why are we futzing around on the command line of a Linux box? Why are we not using a cload orchestrator that abstracts the OS from the equation entirely?

If we do have a need to be on a bare Linux box, all of this OS configuration is better handled with cloud init [1], a configuration management tool like Ansible, and/or by building an image with Packer.

I know that seems like overkill for a small hobby reluctant sysadmin project type of deal but it's very little extra effort once you get used to the workflow. I would even recommend putting this infrastructure in Terraform even though, again, it seems like overkill at first.

Someone else in the comments mentioned that it's easier to just start with a hardened image from the AWS Marketplace, and I also agree with that idea. Find a free hardened image and make that the base for your system.

[1] https://cloud-init.io

Found this related article: "cloud-init re-generates network config every reboot overwriting manual admin changes on CentOS." https://github.com/canonical/cloud-init/issues/2983

You can just lift and shift an exisiting project into the cloud, but let's say you're using AWS's CFT's to define an EC2 instance. Great! throw in some cloud-init ( https://cloud-init.io/ ) script for your ubuntu cloud image for some automated-ness in provisioning and you're off to the races!

You can run an os that has a cloudinit setup. This will on boot do whatever you have in the cloud init file. Check out https://cloud-init.io/ its becoming a standard in operating systems that aren't desktop oriented.

Oh, and as a big bonus, Xen Orchestra supports cloud-init which is a really nice way to customize VMs from a baseline.

Since this is the standard Ubuntu image it's presumably cloud-init which is interpreting your user_data, in which case there are two other possible techniques to use to get this key registered.

Most Linux distribution images in EC2 include cloud-init which runs on startup and retrieves the user data. If you are using a standard Linux distribution AMI then it's probably cloud-init that is taking actions based on your user data, and so cloud-init's documentation on User Data Formats is the relevant reference for you.

Yup. There are several options.