feat: Extend ISO config for USB-sourced config (sneakerconf)

[Ulexus]

Feature Request

A common problem, particularly in non-automated baremetal systems, is providing a configuration to a machine without knowing that machine's IP or before networking can be established with that machine.

Presently, the installer supports pulling the config from a disk label (currently metal-iso, though I suggest perhaps renaming this to something a bit clearer, like talos-config), which is exptected to contain a config.yaml file to use for the initial machine configuration.

When a Talos machine is running in maintenance mode, it waits for configuration to be applied. One possible vector for the application of configuration is plugging in a USB stick.

The scheme could be as follows:

• Talos maintenance mode probes (periodically or on disk addition) for partition label TALOS_CONFIG (or whatever)
• Talos mounts TALOS_CONFIG and looks for its configuration there, in the following order:
  • MAC.yaml where MAC is the MAC address of each discovered network interface
  • DMI-SERIAL.yaml where DMI-SERIAL is the chassis serial number as discovered from DMI.
  • config.yaml - default non-machine-specific configuration file
• Talos applies the discovered configuration as if through apply-config

[smira]

See also #3564 - seems to be a duplicate, plus it's already available in Talos in some way

[Ulexus]

Thanks; indeed. I thought I had already written an issue for this, but I couldn't find it.

[sergelogvinov]

I my opinion bette to have more security maintenance mode here. The operator install the cdrom/usb and run the server. Talos read small machine config, find the network config (like @Ulexus offers), and up the network. When thought api we can put normal (sensitive) machine config.

I think the metal platform and nocloud do the same. We can merge they in one solution. And add network presets MAC.yaml DMI-SERIAL.yaml.

One cdrom/image solves a lot of problems.

[Ulexus]

Extracting secret material from the machineconfig is another very important topic which we are working on, but I think it is fairly orthogonal to this issue. If a user has console and physical access to a machine, there's not much higher level of control that exists, so loading config when in maintenance mode from a local physical device is about as good as it gets.

That said, we have often considered phased or layered configuration: apply a minimal configuration first (e.g. basic network configuration, disk configuration), and then later apply a complete configuration. You can sort of do this today, but not to any serious degree. We might build out more facility for this operational mode in the future, after we get the general machine config changes done to more easily facilitate that (especially with the new COSI-fied machine config).

[flokli]

I think the metal platform and nocloud do the same. We can merge they in one solution. And add network presets MAC.yaml DMI-SERIAL.yaml.

Yes, nocloud and metal can both read config from an additional filesystem.

In the case of nocloud, this filesystem is named CIDATA/cidata, and can contain user-data, meta-data and network-config files. In the case of metal, the filesystem seems to have to be named metal-iso, and config is read from config.yaml.

I couldn't get both to work though :thinking: .

[sergelogvinov]

I couldn't get both to work though 🤔 .

Can you add more details, why you can use metal/nocloud platform?

[flokli]

This has been discussed on Slack a bit - I think in my case, it's might be mostly due to it only detecting CIDATA if it's a separate block devices, and not just a partition.

I'm using metal/nocloud platform for bare-metal Hetzner servers, where I can't use iPXE or a metadata server, but there's a rescue system, which I can use to ssh and dd the installation medium to disk.

I wanted to create the CIDATA filesystem as an additional partition while in the rescue system (see https://gist.github.com/flokli/24f23751aa7fd0459fca82fd61fbc12e for some example code), so I don't need to manually apply-config after reboot.

[flokli]

Ah, on Slack you replied:

CIDATA partition usually stores as separate block device. Openstack uses additional partition to store cloud-config. Try to use openstack platform…

I'll try the openstack variant.

It'd be really nice if we could unify all these code paths, so they will pick up from CIDATA/cidata/metal-iso/talos-config, independent on whether it's a separate block device or partition. This is all pretty confusing right now.

[flokli]

openstack/metadata.go also just seems to be using probe.GetDevWithFileSystemLabel, like nocloud and metal - which doesn't seem to work with partitions.

[flokli]

The partition detection was fixed in https://github.com/siderolabs/talos/commit/efa3f289853a47ae0d4bca5dbf656e527cf312dd. :tada:

It'd still be nice if the different configs could be merged together a bit, so the config partition name can be any of CIDATA/cidata/metal-iso/talos-config, and the talos config be either ./user-data or ./config.yaml in there.

There should probably still be an ISO variant, and a "small disk with partition" variant.

[smira]

Right now I believe it should work ISOs as well if they're properly labeled. But yeah, this needs to be properly documented