Beacons allow you to use the Salt event system to monitor non-Salt processes. Clients can use beacons to connect to various system processes for constant monitoring. When a monitored activity occurs, an event is sent on the Salt event bus that can then trigger a reactor.
To use beacons on SUSE Linux Enterprise Server Salt clients, install the
python-pyinotifypackage. For Red Hat Enterprise Linux systems, install the
For more information on beacons, see https://docs.saltstack.com/en/latest/topics/beacons/
The Salt broker allows clients to pass commands to each other. The broker acts like a switch, therefore peer communication will only work for clients on the same network, or connected to the same proxy.
For more information on Salt and peer communication, see https://docs.saltstack.com/en/latest/ref/peer.html.
SUSE Manager implements Salt with a single environment. Multiple Salt environments are not supported.
Formulas are collections of Salt States that contain generic parameter fields. Formulas are used within SUSE Manager to assist with configuring Salt clients. Some formulas have extensive configuration options, and use forms to help organize them in the SUSE Manager Web UI.
For more information about formulas, see salt:formulas-intro.adoc.
Grains provide information about the hardware of a client. This includes the operating system, IP addresses, network interfaces, and memory. When you run a Salt command any modules and functions are run locally from the system being called. Salt modules are stored on clients and the SUSE Manager Server within the
For more information on grains, see https://docs.saltstack.com/en/latest/topics/grains/.
This term is used when you apply all outstanding states to all targeted clients at the same time. The highstate must be applied when doing changes to systems, including enabling and disabling formulas.
- Key Fingerprints
Key fingerprints are exchanged between the SUSE Manager Server and Salt clients to verify the identity of the server and the client. This prevents Salt clients from connecting to the wrong server. You can see the fingerprints of your Salt clients by navigating to.
The Salt master issues commands to its attached clients. In SUSE Manager, the Salt master must be the SUSE Manager Server.
Salt clients that are connected to and controlled by the Salt master on the SUSE Manager Server. In SUSE Manager, these are referred to as Salt clients, in order to clearly differentiate them from traditional clients. This is a difference in terminology only.
Functions within Salt are stored in modules. There are many types of Salt modules, including state and execution modules. For a complete list of available Salt modules, see https://docs.saltstack.com/en/latest/ref/index.html. Alternatively, you can write your own Salt modules using Python.
Pillars are created on the SUSE Manager Server. They contain information about a client or group of clients. Pillars allow you to send confidential information to a targeted client or group of clients. Pillars are useful for sensitive data, configuration of clients, variables, and any arbitrary data.
For more information on pillars, see https://docs.saltstack.com/en/latest/topics/tutorials/pillar.html.
States are configuration templates. They allow you to describe what each of your systems should look like, including the applications and services that are installed and running. States are applied to the target client. This automates the process of bringing a large number of systems into a known state, and then maintaining them.
Do not update the
saltpackage using states. Update all other system packages using states. You can then update the
saltpackage from the SUSE Manager Web UI as a separate step.
For more information on states, see https://docs.saltstack.com/en/latest/topics/tutorials/starting_states.html.
For more Salt terminology, see https://docs.saltstack.com/en/latest/glossary.html.