saltstack is a great configuration management tool. It’s used in huge enterprises to effect changes on multiple servers. With small scripts, you can quickly implement a change on every server in your environment or on specific servers. saltstack is great at bringing all of your servers to a consistent baseline, ensuring that the same software is available across the board OR ensuring that certain software is REMOVED from every server, before or after deployment.
I don’t have a huge enterprise of thousands of servers. I have a dozen or so Raspberry PIs that I use and maintain in my home. saltstack scales DOWN as well as it scales up! In this series of posts, I’ll be showing how a dedicated Raspberry saltstack server can be a boon in managing a home network of our favorite computers. Seems like there are a lot of piddly tasks that need to be done to a new Raspberry on the network that I don’t always remember to do. saltstack is great at changing passwords, setting locale, removing applications that I never use, like pigpio.
Quick Installation Guide
First, grab the gpg key for a secure installation and updates:
wget -O - http://repo.saltstack.com/py3/debian/10/armhf/latest/SALTSTACK-GPG-KEY.pub | sudo apt-key add -
Next, setup the repo:
echo 'deb http://repo.saltstack.com/py3/debian/10/armhf/latest buster main' > /etc/apt/sources.list.d/saltstack.list
Update the repos:
sudo apt-get update
Finally, do the install:
sudo apt-get install salt-master
Important dns update
For best results, setup a fresh Raspberry and give it the hostname “salt”. More importantly, add an entry to dns that will ensure that all the “minions”, or saltstack clients can find their “master”. If you don’t want to name the salt-master “salt”, you will need to at least put in a CNAME entry.
Once you’ve got your salt-master server up and online and you’ve got a couple of computers running salt-minion on your network, it’s time to get them introduced to one another! saltstack is a fairly secure architecture. It’s enterprise-grade software, remember?
On your salt server, that is, the one running salt-master, run the command:
salt-key collects together all of the requests from the minions (those computers running salt-minion) and asks if you want to accept or deny their requests for a key.
root@salt:~# salt-key Accepted Keys: data1 pihole portal proxy salt trans zero-lr zero-syl Denied Keys: Unaccepted Keys: webs1 webs2 webs3 wordp1 wordp2 Rejected Keys: root@salt:~#
Here you can see that I’ve just installed salt-minion on my webs* and worp* servers. They immediately reach out to any server they can find named “salt” and send a key request. If I type:
salt-key -a web*
I can send the server key to the 3 servers in the list that match that pattern.
will mass accept all of the servers in the “Unaccepted Keys:” list. Once you accept the keys, salt will confirm the additions by displaying a new complete list, with the “Unaccepted” computers promoted to “Accepted” status.
A simple test to try, on your new minions from the salt master, is a ping. salt commands are in the following format:
salt <minion list> command.action [script]
So the first command we’ll try is
salt 'webs*' test.ping
and we get the following:
root@salt:~# salt 'webs*' test.ping webs1: True webs3: True webs2: True root@salt:~#
Fixing salt-minion naming mistakes
When you install the salt-minion, the software automatically grabs the hostname and creates the file /etc/salt/minion_id. This is the name that gets sent to the salt-master. Occasionally, you’ll get unintentional results. In my case, I end up with the domain name in the salt-key list, which works, but isn’t what I’m looking for. This is easy to fix.
When you see that you’ve got the name in the salt-keys list, go to the minion and fix the name by editing /etc/salt/minion_id and restart the client:
systemctl restart salt-minion
Now, go back to the master, delete the “wrong” name with a
salt-key -d 'wrong"
and then add the newly advertized name with:
salt-key -a 'good name'
Stay tuned to this channel for more salt scripting!