Saltstack is a popular tool to automate infrastructure management via data-driven orchestration and remote execution, similar to Puppet, but based on Python and supposedly far more efficient on the orchestration part.
If you are very new to this, I recommend starting with Salt-master and Salt-minion only and add other components once you get familiar with things.
curl -fsSL https://github.com/saltstack/salt-install-guide/releases/latest/download/salt.repo | sudo tee /etc/yum.repos.d/salt.repo
sudo dnf clean expire-cache
sudo dnf install salt-master
sudo dnf install salt-minion
sudo dnf install salt-ssh
sudo dnf install salt-syndic
sudo dnf install salt-cloud
sudo dnf install salt-api
sudo systemctl enable salt-master && sudo systemctl start salt-master
sudo systemctl enable salt-minion && sudo systemctl start salt-minion
sudo systemctl enable salt-syndic && sudo systemctl start salt-syndic
sudo systemctl enable salt-api && sudo systemctl start salt-api
sudo apt install curl gpg
# Ensure keyrings dir exists
mkdir -m 755 -p /etc/apt/keyrings
# Download public key
curl -fsSL https://packages.broadcom.com/artifactory/api/security/keypair/SaltProjectKey/public | gpg --dearmor | sudo tee /etc/apt/keyrings/salt-archive-keyring.pgp > /dev/null
# Create apt repo target configuration
curl -fsSL https://github.com/saltstack/salt-install-guide/releases/latest/download/salt.sources | sudo tee /etc/apt/sources.list.d/salt.sources
sudo apt update
echo 'Package: salt-*
Pin: version 3006.*
Pin-Priority: 1001' | sudo tee /etc/apt/preferences.d/salt-pin-1001
sudo apt-get install salt-master
sudo apt-get install salt-minion
sudo apt-get install salt-ssh
sudo apt-get install salt-syndic
sudo apt-get install salt-cloud
sudo apt-get install salt-api
sudo systemctl enable salt-master && sudo systemctl start salt-master
sudo systemctl enable salt-minion && sudo systemctl start salt-minion
sudo systemctl enable salt-syndic && sudo systemctl start salt-syndic
sudo systemctl enable salt-api && sudo systemctl start salt-api
Both Salt-Master and Salt-Minion Services come with fully sufficient default configurations. If you need to adjust it, use configuration files in /etc/salt/master.d/ or /etc/salt/minion.d/ respectively.
If you have multiple networks on you master node, you may want to set the proper interface . Sometimes it also is useful to use different ports for security reasons. Here is how you override the the default settings:
# The network interface to bind to
interface: 192.0.2.20
# The Request/Reply port
ret_port: 4506
# The port minions bind to for commands, aka the publish port
publish_port: 4505
Afterwards you need to restart the salt-master service:
sudo systemctl restart salt-master
Typically you then have to reconfigure the salt-minion too:
master: 192.0.2.20
Afterwards you need to restart the salt-minion service:
sudo systemctl restart salt-minion
It might take a few seconds to get the service back up. If it takes longer, usually a look into the log at /var/log/salt/minion is helpful.
salt-key command:salt-key
Example response:
Unaccepted Keys:
db1
Accepted Keys:
web1
web2
Rejected:
badguy
In this example, to accept the key for db1, run:
salt-key -a db1
While it is possible to use
salt-key -Ato accept any pending key, it should be avoided, unless you are certain all keys can be trusted. It is very easy to set a minion id to a misleading id by setting a custom id.
Consider it best practice to have a clear defoied naming convention (i.e. FQDNs instead hostnames) and adding new minions via predefined workflow, which ensures only the proper keys are accepted.
Deleting a single key:
salt-key -d web1
Example response:
The following accepted key is set to be removed:
web1
[n/Y]
Deleting ALL keys:
salt-key -D
Example response:
The following keys are going to be deleted:
web1
web2
[n/Y]
Again be extra careful using that command, as it really does delete ALL keys. Unless you happen to clean up your entire Salt environment, it is unlikely to ever delete ALL keys. Rather use filters, see below.
Deleting keys using a filter:
salt-key -d 'web*'
Example response:
The following keys are going to be deleted:
web1
web2
[n/Y]
It is possible to automate key acceptance. One approach would be to enable the auto*accept: True setting in the master config file.
"Automatically accepting keys is very dangerous. Auto accepting minions means anyone can set a minion to connect and gather data on the entire system or worse depending on master config settings.
Be extremely cautious about automatically accepting all incoming keys from a Salt minion. Just because it is possible to auto-accept keys does not mean you should do it."
As a matter of fact, you REALLY should AVOID it.
systemctl status salt-master
Example response:
salt-master.service - The Salt Master Server
Loaded: loaded (/lib/systemd/system/salt-master.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2020-02-04 16:34:55 CST; 17h ago
Docs: man:salt-master(1)
file:///usr/share/doc/salt/html/contents.html
https://docs.saltproject.io/en/latest/contents.html
Main PID: 8727 (salt-master)
Tasks: 32 (limit: 4915)
CGroup: /system.slice/salt-master.service
├─8727 /usr/bin/python2 /usr/bin/salt-master
Feb 04 16:34:55 VM systemd[1]: Starting The Salt Master Server...
salt '*' test.version
This will return all reachable known minions and their salt versions:
minion1:
3006.23
Be sure to have firewall settings adjusted for the master on both
ret_postandpublish_port. If selinux is used, set it topermissiveat least for testing. On the client side.
As for the services (salt-master, salt-minion) I noticed this can take a while to start, and on the master after a reboot it often does not come up automatically, so a manual restart or cronjob for that might be necessary.
At this stage, you should be up and running with your basic salt environment and can start managing all nodes, including the master (yes, the minion should also run on the master).