After my first experience trying to install IncusOS ran into many difficulties - both self-inflicted and not - and required many many many re-installs I was thinking that being able to add a configuration URL for the boot configuration would be a real boon. You boot off the generated install img (or, PXE boot image - I know that has more challenges) and it has a configuration URL you’ve defined embedded in it. The URL points at a tar encrypted with the remote admin key (or whatever checks you want to put on it) holding the config files.
If all goes well it just pulls the file and processes it, same as if the file was on partition 2. If the file is invalid, it would be great if you could correct the file and re-introduce it (“retry config URL?”) to the existing partial/unconfigured setup without needing a whole new install every time you change the setup seeds.
This is not far from how firewalls deal with changing service points like Microsoft’s ever-changing Azure URLs, dynamic block lists etc. For Fortinet they’re called EDLs (external dynamic lists) and there are mechanisms to do this securely.
Apart from helping out amateur tinkerers like me, it would allow larger scale folks inject dynamic host-specific config at install time, a config per subnet/VLAN/site, for specific hardware configs, a git file etc.
So there is a bit of a chicken and egg issue with this kind of thing.
The network configuration is usually the most important part of the seed data/configuration, so needing that configuration in order to get more configuration is a bit of a problem
For larger deployments, we have Operations Center where you can come up with a basic network config (typically single NIC on a provisioning VLAN with DHCP) that allows for connectivity back to Operations Center, then as soon as it’s in Operations Center, you can programmatically push any IncusOS config you want to the system.
We’re actually landing scriptlet support now so that kind of configuration can happen completely automatically when the system self-registers with Operations Center.
You have probably already thought about this but the way I would prefer to do it - speaking with my homelab hat on as well as from my job’s perspective - would be to PXE boot (or otherwise attach) a small universal image which non-destructively inventorys the node’s hardware and then reports it to Operations Centre. Then you can choose to adopt it as an IncusOS node or not and provision it from there using tags, rules, whatever.
A bit like Digital Rebar (way too complicated for your usecases) or MaaS (um, yeah). At least then you have a central inventory and a clear up front idea of how much of your deployed estate will work out of the box, and you can build a plan (via Migration Center, perhaps).
Yeah, UEFI Secure Boot with UEFI HTTP netboot isn’t exactly fun
The direction we’re headed instead for Operations Center is to have it handle Redfish so we can access the FRU data and configure the firmware on the server directly, then use the virtual media feature to have the server boot from a custom .iso that’s served by Operations Center.
