Skip to main content

Saltstack Refresh Course 1: Setup

Shenzhen, China

Installing Salt

Installing Salt from a bash file:

#!/bin/bash
# Install pip
curl https://bootstrap.pypa.io/get-pip.py | python

# Install Salt
/usr/local/bin/pip install salt

# Configure Salt
mkdir -p /etc/salt/minion.d/
echo "master: <My Master IP"> /etc/salt/minion.d/master.conf
echo "<My Minion ID>" > /etc/salt/minion_id

# Run salt
/usr/local/bin/salt-minion -d

Setting up Salt (Manually)

Start by defining the Root directory for your Salt Master configuration files:

nano /etc/salt/master.d/roots.conf

We are going to collect all our configuration files in the default mkdir -p /srv/salt/base directory:

file_roots:
base:
- /srv/salt/base

Now we need to tell our Salt Minion where to find the master server:

nano /etc/salt/minion.d/master.conf

In my case the master is running on the same server but I will still use the local IP:

master: 192.168.2.110

We can now start the Salt Minion daemon and check the minion key with the following commands:

salt-minion -d
salt-key

Your minion should have send a connection request with a identifying key. Your master should have this key listed under Unaccepted Keys. Since the key is not very readable we first want to change it. To do this we can first stop the minion process:

systemctl stop salt-minion
systemctl status salt-minion

You can delete the old key with salt-key -d 'old-key'. You can replace the key with something sensible, e.g. salt-master_minion. For this we first have to find out the Master public key:

salt-key --finger-all

Local Keys:
master.pem: f1:d3:52:eb:f4:...
master.pub: 64:12:61:93:3e:...

And then add both the key and the desired Minion ID to our /etc/salt/minion.d/master.conf file:

# Set the location of the salt master server. If the master server cannot be
# resolved, then the minion will fail to start.
master: 192.168.2.110

# Fingerprint of the master public key to validate the identity of your Salt master
# before the initial key exchange. The master fingerprint can be found by running
# "salt-key -f master.pub" on the Salt master.
master_finger: '64:12:61:93:3e:...'

# Explicitly declare the id for this minion to use, if left commented the id
# will be the hostname as returned by the python call: socket.getfqdn()
# Since salt uses detached ids it is possible to run multiple minions on the
# same machine but with different ids, this can be useful for salt compute
# clusters.
id: salt-master_minion

Now restart the minion with:

systemctl start salt-minion
systemctl status salt-minion

If we re-run the key command we will now see our Minion key listed with the new name (below I added another server - so now I have the master_minion and a regular minion waiting for approval):

salt-key

Accepted Keys:
Denied Keys:
Unaccepted Keys:
salt-master_minion
salt-minion

I can accept them with the following command:

salt-key -a salt-*

Salt Command Line Interface

manage.up

We can now verify that all minions are up and ready:

salt-run manage.up

- salt-master_minion
- salt-minion

cmd.run

We can also execute commands directly on our minions:

salt salt-minion cmd.run 'ls -lah /etc'
salt salt-minion cmd.run 'uptime'
salt salt-master_minion cmd.run 'hostname'

Execution Modules

Salt Module Reference

test.ping

Module for running arbitrary tests

test

salt 'salt-*' test.ping
salt-master_minion:
True
salt-minion:
True

user.add

Manage users with the useradd command

useradd

salt 'salt-minion' user.add 'zabbix'

salt-minion:
True

You can verify that the user was added on your Minion with cat /etc/passwd. You can delete the user (and remove the home directory) with:

salt 'salt-minion' user.delete zabbix remove=True force=True

file.append

Manage information about regular files, directories, and special files on the minion, set/read user, group, mode, and data.

file

salt 'salt-minion' file.append /root/test 'Salty Dayz, Sailors'

salt-minion:
Wrote 1 lines to "/root/test"

aptpkg / yumpkg

Support for APT (Advanced Packaging Tool)

aptpkg

salt '*' pkg.install git

Salt Grains, Pillars and SaltUtil

Grains return system variables

salt salt-minion grains.items

salt-minion:
----------
apps:
----------
port:
7777
biosreleasedate:
07/31/2018
biosversion:
0407
cpu_model:
Intel(R) Core(TM) i3-8130U CPU @ 2.20GHz
cpuarch:
x86_64
dns:
----------
domain:
ip4_nameservers:
- 127.0.0.53
ip6_nameservers:
nameservers:
- 127.0.0.53
options:
- edns0
search:
- workgroup
sortlist:
domain:
fqdn:
salt-minion
fqdn_ip4:
- 127.0.1.1
fqdn_ip6:
fqdns:
- registry.salt-minion
- salt-minion

...

Pillars should be used to store secrets (SSH logins, api keys, etc.). Those information are stored on the master server and only securely transferred to the minion server that needs the information. Pillar data has to be synced using the SaltUtil accordingly.

salt salt-minion saltutil.pillar_refresh
salt-minion:
True

salt salt-minion saltutil.sync_all
salt-minion:
----------
beacons:
clouds:
engines:
executors:
grains:
log_handlers:
matchers:
modules:
output:
proxymodules:
renderers:
returners:
sdb:
serializers:
states:
thorium:
utils: