Dynamically Register and Deregister Uyuni Clients

[kurzandras]

Hello!

I have the following situation: I have thousands of hosts and I would need to bootstrap new SLES12 and SLES15 clients and delete inactive clients on a daily basis and I would like to ask for advices how to achieve this the best way possible. The workflow what I can think of is the following:

Adding new servers:

• A new clean SLES server boots up
• It checks if the host is already registered to the Uyuni server (somehow).
• If it is not connected yet it starts the bootstrap script using the neccessary activation key (I would use a custom script for this).
• The Uyuni server accepts salt keys on an hourly basis (cron maybe).

Regarding deleting inactive clients I have no ideas, I have checked the documentation but unfortunately I could not really find a solution. There are informations how to delete a client, but I am not sure how to determine if a client is inactive from the command line.

I would have the following questions:

• How can I determine from the client if it is connected to the Uyuni server or not?
• Do you have any other ideas for accepting salt keys other than doing it periodically?
• How could I delete/deregister inactive clients from the command line (client and server)?
• Could you please share useful Salt/Uyuni commands which could help me achieve the dynamic registration/deregistration?

Any answer is hugely appreciated! Thank you very much for your help in advance!

Information for package Uyuni-Server-release:

Repository : uyuni-server-stable Name : Uyuni-Server-release Version : 2023.10-230900.209.1.uyuni3 Arch : x86_64 Vendor : obs://build.opensuse.org/systemsmanagement:Uyuni Support Level : Level 3 Installed Size : 1.4 KiB Installed : Yes (automatically) Status : up-to-date Source package : Uyuni-Server-release-2023.10-230900.209.1.uyuni3.src Summary : Uyuni Server Description : Uyuni lets you efficiently manage physical, virtual, and cloud-based Linux systems. It provides automated and cost-effective configuration and software management, asset management, and system provisioning.

[j-kihet]

Hi For auto accepting you can use the following script running in crontab on the master server. There are other methods. This is just a fast and simple solution. Keep in mind that clients need to have a unique Minion Id or salt will reject them.

#!/bin/bash
for OUTPUT in $(salt-key --list unaccepted)
do
        salt-key -a "$OUTPUT" --yes
done

Spacecmd or the API can also be used to automate most of the task you need.

https://www.uyuni-project.org/uyuni-docs/en/uyuni/reference/spacecmd/spacecmd-functions.html https://www.uyuni-project.org/uyuni-docs/en/uyuni/reference/help/api-menu.html https://www.uyuni-project.org/uyuni-docs/en/uyuni/reference/spacecmd/api.html

Automatic removal is a bit more tricky since the salt client can stop working when there is no space, an error occurs , issues with proxy servers and so on.

Depending on how you create/delete the servers, if you are using ci/cd you can probably build the removal function in there.

The bootstrap script that uyuni generates is handy, you can also modify it to your needs.

[kurzandras]

Hello @j-kihet !

Thank you for your quick response! Just one small additional question: which salt command can I use from the client to check if it is connected to the master?

"venv-salt-call test.ping" displays:

local: True

Is this enough to check the connection?

[j-kihet]

Im not sure , I haven't used any of the client side commands. Ping probably just tries to ping the master/proxy and does not test if its and active/working client.

[jmozd]

WRT alternatives to accepting Salt keys manually: If your VMs follow a deployment process, you can generate the keys during provisioning and not only deploy private/public part to the VM, but also the public part to the Salt master, resulting in a pre-accepted minion (in a controlled fashion!).

Do you have any other ideas for accepting salt keys other than doing it periodically?

Instead of a "test.ping", you could try to retrieve pillar data. This can give you details on the actually configured master (when retrieving the according pillar item) and will only work if the minion is fully functional. OTOH, I believe that even test.ping will only work with accepted minion keys. And so depending on your deployment strategy, you might need to consider that your server has started, its minion is up and running but your tests do fail, because the minion key is not (yet) accepted by the Salt master. That's why I'd go for pre-accepted keys ;)

How could I delete/deregister inactive clients from the command line (client and server)?

How about "spacecmd system_delete"?

but I am not sure how to determine if a client is inactive from the command line

The (to me) important question is "how is 'inactive client' defined?" Once you have that answered, it should be possible to figure out how to check for the condition.