Il 06/10/2023 15:15, Johan Beisser ha scritto:
With that, on the salt-master, either autoaccept, or find a way to place the minion's public key in `/etc/salt/pki/master/minions/<minion-id>` and that will bypass the key acceptance entirely. Keys, inside of salt, are just managing where the file sits under the various minion directories in `/etc/salt/pki/master/` after all.
Yup. that's exactly where my problem lies: that "find a way" is what I'm looking for :)
Don't have to do it if you set the master's public key, and minion keys, before the minion is started though.
Well, for the minion it's not a problem, as long as it finds the correct pubkey: if its key is missing, a keypair can be generated. But the master doesn't know this new key (yet).
Then it's just having a single job starting after FAI's reboot, and doing `salt-call state.highstate` on first boot.
It's not a Salt problem, it's just a "timing issue" that I have to understand well. Once Salt knows a minion is being reinstalled (ideally I triggered it applying a given state), it should sync with FAI to wait the moment the minion is rebooting (or, even better, it receives the minion key before the reboot) and knows it can trust that key.
-- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
