Salt configuration is very simple. The default configuration for the master will work for most installations and the only requirement for setting up a minion is to set the location of the master in the minion configuration file.
The configuration files will be installed to
/etc/salt and are named
after the respective components,
By default the Salt master listens on ports 4505 and 4506 on all
interfaces (0.0.0.0). To bind Salt to a specific IP, redefine the
"interface" directive in the master configuration file, typically
/etc/salt/master, as follows:
- #interface: 0.0.0.0 + interface: 10.0.0.1
After updating the configuration file, restart the Salt master. See the master configuration reference for more details about other configurable options.
Although there are many Salt Minion configuration options, configuring a Salt Minion is very simple. By default a Salt Minion will try to connect to the DNS name "salt"; if the Minion is able to resolve that name correctly, no configuration is needed.
If the DNS name "salt" does not resolve to point to the correct
location of the Master, redefine the "master" directive in the minion
configuration file, typically
/etc/salt/minion, as follows:
- #master: salt + master: 10.0.0.1
After updating the configuration file, restart the Salt minion. See the minion configuration reference for more details about other configurable options.
A proxy minion emulates the behaviour of a regular minion and inherits their options.
Similarly, the configuration file is
/etc/salt/proxy and the proxy
tries to connect to the DNS name "salt".
In addition to the regular minion options, there are several proxy-specific - see the proxy minion configuration reference.
Start the master in the foreground (to daemonize the process, pass the
Start the minion in the foreground (to daemonize the process, pass the
The simplest way to troubleshoot Salt is to run the master and minion in
the foreground with
log level set to
For information on salt's logging system please see the logging document.
Run as an unprivileged (non-root) user
To run Salt as another user, set the
user parameter in the
master config file.
Additionally, ownership, and permissions need to be set such that the desired user can read from and write to the following directories (and their subdirectories, where applicable):
More information about running salt as a non-privileged user can be found here.
There is also a full troubleshooting guide available.
Salt provides commands to validate the identity of your Salt master and Salt minions before the initial key exchange. Validating key identity helps avoid inadvertently connecting to the wrong Salt master, and helps prevent a potential MiTM attack when establishing the initial connection.
Print the master key fingerprint by running the following command on the Salt master:
salt-key -F master
master.pub fingerprint from the Local Keys section, and then set this value
master_finger in the minion configuration file. Save the configuration
file and then restart the Salt minion.
Run the following command on each Salt minion to view the minion key fingerprint:
salt-call --local key.finger
Compare this value to the value that is displayed when you run the
salt-key --finger <MINION_ID> command on the Salt master.
Salt uses AES encryption for all communication between the Master and the Minion. This ensures that the commands sent to the Minions cannot be tampered with, and that communication between Master and Minion is authenticated through trusted, accepted keys.
Before commands can be sent to a Minion, its key must be accepted on
the Master. Run the
salt-key command to list the keys known to
the Salt Master:
[root@master ~]# salt-key -L Unaccepted Keys: alpha bravo charlie delta Accepted Keys:
This example shows that the Salt Master is aware of four Minions, but none of
the keys has been accepted. To accept the keys and allow the Minions to be
controlled by the Master, again use the
[root@master ~]# salt-key -A [root@master ~]# salt-key -L Unaccepted Keys: Accepted Keys: alpha bravo charlie delta
salt-key command allows for signing keys individually or in bulk. The
example above, using
-A bulk-accepts all pending keys. To accept keys
individually use the lowercase of the same option,
Communication between the Master and a Minion may be verified by running
[root@master ~]# salt alpha test.ping alpha: True
Communication between the Master and all Minions may be tested in a similar way:
[root@master ~]# salt '*' test.ping alpha: True bravo: True charlie: True delta: True
Each of the Minions should send a
True response as shown above.