Hi Allen,
It may be worth regenerating the client's machine-id, as that's how Uyuni/Salt identifies machines. My assumption is that the salt key is linked to the machine id in Uyuni from the previous registration.
I could be wrong and others may give you better advice, but FWIW: these are the commands I've added to my bootstrap.sh to do that, but they can be run manually before bootstrapping. They'll remove the existing id on a EL machine and regenerate it.
echo "Clearing machine-id to ensure no dupes"
rm -f /etc/machine-id
rm -f /var/lib/dbus/machine-id
dbus-uuidgen --ensure
systemd-machine-id-setup
-----Original Message-----
From: Allen Beddingfield
Sent: 26 August 2022 06:01
To: users@lists.uyuni-project.org
Subject: [EXTERNAL EMAIL] "The salt master has cached the public key for this node" error.
[You don't often get email from allen@ua.edu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
I have a salt minion that I deleted (by going to "salt keys" in the web ui), stopped the salt minion process on the server, changed the hostname, and re-ran the bootstrap script. It shows up in the lists of keys, and I have selected to approve it, but it never actually turns blue so that it can be selected. The minion on the server is giving this error: "The Salt Master has cached the public key for this node, this salt minion will wait for 10 seconds before attempting to re-authenticate". I've also tried deleting it with salt-key -d, with the same result.
I have encountered this before on a SUSE Manger server, and the resolution was to remove the corresponding entry from /var/lib/salt/.ssh/known_hosts, which doesn't seem to exist on my Uyuni 2022.06 server.
Any ideas on how to proceed? FYI, the minion is running CentOS 7.x.
Thanks.
Allen B.
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
allen@ua.edu
