Pulling the Strings

Even in smaller IT environments, managing systems as consistently as possible pays dividends. The effort required to learn and use massive tools for configuration management (e.g., Ansible, Chef, Puppet) rarely pays off, because you frequently need to complete simple, one-time tasks; when these present themselves, writing recipes (Chef) or manifests (Puppet) wastes too much time.

Alternatively, many admins use self-made scripts, which they execute to hosts in rotation from a list that is laborious to maintain. Although these methods work, you must take the particulars of the respective platforms into account and cope with possible timeouts while opening connections. This effort can be reduced by turning to a proven solution. The right tool should be able not only to abstract the differences of distributions and operating systems but also to provide its own communication channel and offer modules with pre-built commands and macros. Normally, projects from the orchestration and remote execution environment offer something similar. Thanks to its simple operation, speed, and scalability, SaltStack [1] stands out from the competition in these cases.

SaltStack

The systems and software architect Thomas S. Hatch faced the challenge of centrally maintaining an infrastructure that was partly inconsistent. To master it, he wrote his own software in Python; SaltStack (Salt, for short) emerged and was eventually published as an open source project in March 2011.

SaltStack is based on a central master, whose commands are executed on the target systems by Salt "minions." The communication between the master and the minions does not take place via SSH; rather, it relies on the well-known ZeroMQ [2] message bus library using an asynchronous approach. By design, various modules offer a full palette of commands and command sequences with which you can execute specific tasks. Additionally, another module facilitates running Linux commands. As soon as you initiate tasks with the master, the tool monitors execution on the minions and subsequently displays the outcome.

It does not matter whether you only use Salt on Linux, run different distributions on the master host and the target systems, or even go with FreeBSD. Salt supports a wide range of operating systems, although some of them (e.g., Windows) only as minions [3]. A list of all the operating systems in question can be found online [4]. You can deliver standardized commands with the modules supplied, and the modules on the minions then translate these into platform-specific commands.

Installation

As the master, you use a physical or virtual machine; even for large installations, the requests are so small that the master does not overtask the minions. Usually, you can install both the master and the minions from the official repository. However, where differences are too large, the available Salt versions can run into compatibility problems because of different module packages. You are better off running all minions compatibly with the same version of Salt. For the sake of ease in my tests, I prepared a set of virtual machines (VMs) that can see one another. An Ubuntu system hosts the master, and SUSE, Debian, and Fedora VMs serve as minions. You can see a more detailed overview along with OS versions and IPs in Table 1.

On Ubuntu 14.04, you can install the master with the

sudo apt-get install salt-master

command. To install the correct minion on Debian 7, modify the package sources by adding the following line to the /etc/apt/sources.list file

deb http://debian.saltstack.com/debian wheezy-saltstack main

and updating with sudo apt-get update. The minion is then installed by typing one of the following commands,

# On Debian
sudo apt-get install salt-minion
# On openSUSE 13.2
sudo zypper install salt-minion
# On Fedora 23
sudo dnf install salt-minion

depending on your Linux installation.

Configuration

On startup, the minions try to connect to the master by default. If they have not configured a target of this kind, the software automatically searches the DNS domain for a salt entry. You can therefore either create a corresponding A record that points to the master (in my test, the target was the IP address 192.168.178.39), or you can configure the Salt minions manually.

On any system running a minion, you can edit the /etc/salt/minion configuration file and search for the line that begins #master:. You then remove the comment character and modify the line to

master: 192.168.178.39

(Figure 1). Replace the IP address from the example with any address that shows on the master in your network. After the changes, you need to restart the minion.

Figure 1: If automatic configuration fails, set the Salt master's options manually.

If the local system or network has a firewall that potentially filters the communication between master and minions, open TCP ports 4505 and 4506 on all systems involved. In case of questions or problems, your best option is to check out the appropriate section in the official documentation [5].

The connection between the Salt master and its minions is encrypted, and both sides authenticate. Before the minions can accept commands from a master, they first need to store their keys on the master, and the master has to accept the keys. When a minion connects to a new master for the first time, this exchange occurs automatically. On the master, you can view the list of minions (Figure 2) that have submitted your key using:

sudo salt-key -L

Figure 2: Verification procedure: Salt makes sure the components know one another.

If you trust these minions straightaway, you can accept all keys in one fell swoop with the

sudo salt-key -A

command and confirm by typing Y. If you want to check the identity of the individual minions, on the other hand, help with salt-key can be found on the man page. Running sudo salt-key -L again verifies acceptance (Figure 2).

All minions listed in green beneath Accepted Keys will accept commands from the master. For test purposes, you should check that the master sees the minions online, using the

sudo salt-run manage.status

command. Figure 3 shows the result.

Figure 3: If you have registered the minions properly on the master, nothing stands in the way of communication between the computers.