I've got an oddity that I am having trouble figuring out. One of our servers is not listed on the Uyuni web admin site, but there's a Salt ID for it. I've deleted it multiple times, but it keeps reappearing, even after rejecting it and deleting it. What I am trying to do is to remove any instance of this server from Uyuni and then re-add it - hoping that a clean install will take care of this issue. Ideas? [cid:image001.png@01D8606A.22AD1D00] [Vanderbilt] Jamen McGranahan Associate Director of Library Technology & Digital Services, Vanderbilt Library Vanderbilt University 615.343.1614 | jamen.mcgranahan@vanderbilt.edumailto:jamen.mcgranahan@vanderbilt.edu | https://www.library.vanderbilt.edu/ Central Library, 419 21st Avenue South Nashville, TN 37203 Pronouns: he/him/his [cid:image003.png@01D8606A.22AD1D00]
Hi Jamen
First of all, try to check if the machine ID for it is duplicated for any other registered clients
Victor
________________________________
From: McGranahan, Jamen (VU) via Uyuni Users
And it is probably keeping reappearing because the salt agent is still running on your server libvm29 and keep requesting for a key to the Salt server.
Just stop/remove the salt minion on it to prevent for the pending key to appear again and before trying to register it again.
And yes, like Viktor just said, you need to make sure that if this is a clone VM, then the machine ID has been renewed.
Philippe Bidault | Unix Engineer | Getronics
________________________________
M. 34617301667 | E. Philippe.Bidault@Getronics.com | W. www.getronics.comhttp://www.getronics.com
Follow us on:
[cid:SocialLink_Linkedin_32x32_e7c75ee5-f8bf-4d58-979b-3050856d34e9.png]https://www.linkedin.com/company/getronics/ [cid:SocialLink_Twitter_32x32_cb75fe15-abe1-46a3-9ac3-fc99d077e43b.png] https://twitter.com/getronics [cid:SocialLink_Youtube_32x32_1946f212-29cc-40bc-9061-3536027a9813.png] https://www.youtube.com/channel/UCfEFIFxLdxxhMN-Eaa6pXVA https://twitter.com/getronics
Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262.
Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain.
The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you.
Legal disclaimer: http://www.getronics.com/legal/ and further details of how we treat your personal data can be found in our privacy policyhttps://www.getronics.com/policy-pages/corporate-policy-legal-disclaimer/
From: Victor Zhestkov via Uyuni Users
Le jeudi 5 mai 2022, 17:29:39 CEST Bidault, Philippe via Uyuni Users a écrit :
And it is probably keeping reappearing because the salt agent is still running on your server libvm29 and keep requesting for a key to the Salt server. Just stop/remove the salt minion on it to prevent for the pending key to appear again and before trying to register it again.
I have had recently a very similar issue, and the cause was that I had both "salt-minion" and "venv-salt" running at same time. No matter how much I was accepting or rejecting the keys, they kept arriving. Solution was to directly delete the associated process on the minion and to keep only one of both services running. Best, -- Eric Bischoff - SUSE Manager QA Engineer SUSE Software Solutions Germany GmbH (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev
Hi Eric.
Such behavior cold be possible if both salt-minion and venv-salt-minion are installed on the system, but only salt-minion is configured to the sarver.
In this case on highstate apply, venv-salt-minion will be configured to the server as is's the preferred one, but the salt-minion left untouched.
In general it looks like it could happen on the testsuite, but not so common case for the real systems as we recommmed to apply the migration state to migrate to venv-salt-minion and it's disabling the salt-minion after configuring the bundle.
Victor
________________________________
From: Eric Bischoff
And it is probably keeping reappearing because the salt agent is still running on your server libvm29 and keep requesting for a key to the Salt server. Just stop/remove the salt minion on it to prevent for the pending key to appear again and before trying to register it again.
I have had recently a very similar issue, and the cause was that I had both "salt-minion" and "venv-salt" running at same time. No matter how much I was accepting or rejecting the keys, they kept arriving. Solution was to directly delete the associated process on the minion and to keep only one of both services running. Best, -- Eric Bischoff - SUSE Manager QA Engineer SUSE Software Solutions Germany GmbH (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev
Le jeudi 5 mai 2022, 18:22:11 CEST Victor Zhestkov a écrit :
Hi Eric.
Such behavior cold be possible if both salt-minion and venv-salt-minion are installed on the system, but only salt-minion is configured to the sarver. In this case on highstate apply, venv-salt-minion will be configured to the server as is's the preferred one, but the salt-minion left untouched. In general it looks like it could happen on the testsuite, but not so common case for the real systems as we recommmed to apply the migration state to migrate to venv-salt-minion and it's disabling the salt-minion after configuring the bundle.
Hi Victor, No, it's probably not a common case. It happened after some humans fiddled with the minion during a testing session :-P . I just wanted to give this tip: if you see two keys fighting each other for the same minion, this might be the reason: salt-minon and venv-salt both activated. BTW kudos to Vladimir for pinpointing the issue. Best, -- Eric Bischoff - SUSE Manager QA Engineer SUSE Software Solutions Germany GmbH (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev
Ah, I didn't realize there was a "machine-id" file. Just for future reference for anyone else who might run into this:
/etc/machine-id
This needs to be unique across all servers. If you clone a server (like we did), you'll have to remove this file and recreate it:
rm /etc/machine-id
systemd-machine-id-setup
[Vanderbilt]
Jamen McGranahan
Associate Director of Library Technology & Digital Services, Vanderbilt Library
Vanderbilt University
615.343.1614 | jamen.mcgranahan@vanderbilt.edumailto:jamen.mcgranahan@vanderbilt.edu | https://www.library.vanderbilt.edu/
Central Library, 419 21st Avenue South
Nashville, TN 37203
Pronouns: he/him/his
[cid:image003.png@01D8606B.12103990]
From: Victor Zhestkov
participants (4)
-
Bidault, Philippe -
Eric Bischoff -
McGranahan, Jamen (VU) -
Victor Zhestkov