Terminology
- Beacon
-
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-pyinotify
package. For Red Hat Enterprise Linux systems, install thepython-inotify
package.For more information on beacons, see https://docs.saltstack.com/en/latest/topics/beacons/
- Broker
-
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.
- Environment
-
Uyuni implements Salt with a single environment. Multiple Salt environments are not supported.
- Formulas
-
Formulas are collections of Salt States that contain generic parameter fields. Formulas are used within Uyuni to assist with configuring Salt clients. Some formulas have extensive configuration options, and use forms to help organize them in the Uyuni Web UI.
For more information about formulas, see Salt Formulas.
- Grains
-
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.
For more information on grains, see https://docs.saltstack.com/en/latest/topics/grains/.
- Highstate
-
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 Uyuni 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
. - Master
-
The Salt master issues commands to its attached clients. In Uyuni, the Salt master must be the Uyuni Server.
- Minions
-
Salt clients that are connected to and controlled by the Salt master on the Uyuni Server. In Uyuni, these are sometimes referred to as Salt clients. This is a difference in terminology only.
- Modules
-
Functions within Salt are stored in modules. Salt modules are stored on clients and the Uyuni Server within the
/usr/lib/python*/site-packages/salt/
directory. There are many types of Salt modules, including state and execution modules. You can write your own Salt modules using Python.For a complete list of available Salt modules, see https://docs.saltstack.com/en/latest/ref/index.html.
- Pillars
-
Pillars are created on the Uyuni 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
-
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
salt
package using states. Update all other system packages using states. You can then update thesalt
package from the Uyuni 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.