Push via Salt SSH
Push via Salt SSH is used in environments where Salt clients cannot reach the Uyuni Server directly. In this environment, clients are located in a firewall-protected zone called a DMZ. No system within the DMZ is authorized to open a connection to the internal network where the Uyuni Server is located.
Push via Salt SSH is also to use if installing a daemon agent on clients is not possible.
The Push via Salt SSH method has serious limitations. It does not scale well, and consumes more Server resources and network bandwidth than the plain Salt method. The Push via Salt SSH method is not at all supported with large setups (1000 clients and more).
The Push via Salt SSH method creates an encrypted tunnel from the Uyuni Server on the internal network to the clients located in the DMZ. After all actions such as updates and events are pushed and executed, the tunnel is closed.
The server uses the Salt SSH to contact the clients at regular intervals, checking in and performing scheduled actions and events.
This image demonstrates the Push via Salt SSH process path.
All items left of the
Taskomatic block represent processes running on the Uyuni client.
To use Push via Salt SSH, you must have the SSH daemon running on the client, and reachable by the
salt-api daemon running on the Uyuni Server.
Additionally, the required Python version will be installed with the salt-bundle on the remote system.
Red Hat Enterprise Linux 5, CentOS 5, and earlier are not supported, as they use unsupported versions of Python.
In the Uyuni Web UI, navigate toand complete the appropriate fields.
Select an activation key with the Push via SSH contact method configured. For more information about activation keys, see client-configuration:activation-keys.adoc.
Manage system completely via SSHcheckbox.
Click Bootstrap to begin registration.
Confirm that the system has been registered correctly by navigating to.
When you are configuring Push via Salt SSH, you can modify parameters that are used when a system is registered, including the host, activation key, and password. The password is used only for bootstrapping, it is not saved anywhere. All future SSH sessions are authorized via a key/certificate pair. These parameters are configured in.
You can also configure persistent parameters that are used system-wide, including the sudo user. For more information on configuring the sudo user, see client-configuration:contact-methods-pushssh.adoc.
The Push via Salt SSH feature uses taskomatic to execute scheduled actions using
The taskomatic job periodically checks for scheduled actions and executes them.
Unlike Push via SSH on traditional clients, the Push via Salt SSH feature executes a complete
salt-ssh call based on the scheduled action.
By default, twenty Salt SSH actions can be executed at a time.
You can increase the number of actions that can be executed in parallel, by adding these lines to your configuration file, and adjusting the value of
We recommend you keep the number of parallel actions low, to avoid problems:
taskomatic.com.redhat.rhn.taskomatic.task.SSHMinionActionExecutor.parallel_threads = <number> org.quartz.threadPool.threadCount = <value of parallel_threads + 20>
This adjusts the number of actions that can run in parallel on any one client and the total number of worker threads used by taskomatic. If actions needs to be run on multiple clients, actions are always executed sequentially on each client.
If the clients are connected through a proxy, you need to adjust the
MaxSessions settings on the proxy.
In this case, set the number of parallel connections to be three times the total number of clients.
There are some features that are not yet supported on Push via Salt SSH. These features do not work on Salt SSH clients:
Beacons, resulting in:
Installing a package on a system using
zypperdoes not invoke the package refresh.
Virtual Host functions (for example, a host to guests) does not work if the virtual host system is Salt SSH-based.