Choice of Target

Someone with an army of subordinates at their command will either direct their orders to all the group's members, or just a selection. The same holds for a Salt master: here, too, it decides which minions it communicates with.

The primary command you will use on SaltStack is built to that effect. After entering the command (salt), you name the targets (choose all with "*") and specify a <module>.<function> pair, which in this case checks the connections with the minions:

$ sudo salt "*" test.ping
linux-x3b4.site:
  True
fedora23.fritz.box:
  True
deb7:
  True

Targeting the minions (i.e., choosing the targets) is one of two central elements in working with the command. Salt provides a wide range of options just to reach a particular host:

$ sudo salt "deb7" test.version
deb7:
  2015.5.3

With Salt, you can also select minions using regular expressions and patterns. For example, entering d* lets you incorporate all systems whose names begin with the letter d.

Alternatively, file[1-5] can be applied to the minions with the file1 to file5 identifier.

To address the three minions in the test configuration shown here, for instance, you could use the starting letters of their names, after which any character string could follow:

$ sudo salt "[d,l,f]*" test.version
linux-x3b4.site:
  2014.1.11
deb7:
  2015.5.3
fedora23.fritz.box:
  2015.5.5

You can link together almost any number of criteria to select a system on what SaltStack calls compound matchers. Activate these keywords with -C before choosing the targets. Inside the quotes, you are free to enter several pieces of information, linking them with and or and not. This simple example shows how to select all minions then exclude the Debian host:

$ sudo salt -C "* and not deb*" test.ping
linux-x3b4.site:
  True
fedora23.fritz.box:
  True

You can select minions on the basis of attributes like the operating system, the IP address, and many other factors. More information can be found in the "Attributes" section.

Incidentally, if you get the impression that a minion name is not optimal, you can set the name in the /etc/salt/minion_id file. Generally, you can assign any name, although for day-to-day use, a fully qualified domain name (FQDN) or a combination of role and number have proven successful.

The test module used here mostly does not see day-to-day use. Instead, it helps with debugging and fast connectivity checking. Further functions of test can be found in the online documentation [6]. Likewise, if you want to take a comprehensive look at the choice of target systems on Salt, there are relevant documents on the web [7].

Attributes

A Salt minion is aware of certain information about the system on which it is running and stores this in so-called grains. Among other things, grains provide information about the operating system, the network configuration, the hardware, or the BIOS.

In the following example, the first command delivers a list of all grain names on all minions, whereas the second command provides their values, as seen in Figure 4:

sudo salt "*" grains.ls
sudo salt "*" grains.items

Figure 4: By design, Salt recognizes numerous important attributes of a system on which a compatible minion is running.

Sometimes you only need certain information, so you only need to retrieve single grains, such as the operating system:

$ sudo salt "*" grains.item os
deb7:
  os: Debian
linux-x3b4.site:
  os:openSUSEfedora23.fritz.box:
  os: Fedora

Furthermore, minions can be addressed on the basis of grains, which makes it possible to target minions across several relevant conditions, such as those with a specific CPU architecture or those with 984MB of working memory that do not have the same name as the openSUSE test system:

$ sudo salt -G "cpuarch:x86_64" test.ping
$ sudo salt -C "mem_total:984 and not linux-x3b4.site" test.ping

By default, Salt has been designed to define a few important grains, but in many cases, it will make sense to add your own definitions (e.g., with information about the computers' locations or roles). SaltStack lends support with its comprehensive documentation [8].

Variety of Modules

Although SaltStack lets you send shell commands directly to minions, in practice most administrators will tend to rely on pre-made modules that cover a multitude of scenarios, from managing users or packages to interacting with databases. All of the modules offer commands tailored for the various platforms and options for processing the output if needed. For this reason, you will want to give modules preference over shell commands, as long as they offer the desired functionality.

A complete list of all available Salt modules can be found online [9]. Please note that different numbers of modules are available depending on the Salt version you use. Only the latest version supports all the modules. If you are looking for more of a challenge, you will find tips in the documentation to write and integrate your own modules [10]. Salt also supports virtual modules. When you deploy these modules, you will not be able to tell the difference, but under the hood, these extensions run other modules that then complete the required tasks.

One such virtual module, for instance, is the pkg package module: A look at the official documentation [11] shows that it forwards commands to standard modules, which Salt selects according to the platform on the target system. As soon as you look into using a module, it is a very sensible idea to discover all the extension's functions by reading the official documentation.

The pkg module contains numerous important calls, such as letting you install or remove repositories across multiple platforms, manage repositories, and handle pending updates. A full overview of the commands can be found online for systems with the Apt package manager [12].

The calls from this sub-module are, in fact, broadly comparable under the hood to the modules that work with Yum or Zypper. To discover across multiple platforms whether a certain package is installed on a system, simply request the version:

$ sudo salt "*" pkg.version grep
deb7:
  2.12-2
linux-x3b4.site:
  2.20-2.4.1
fedora23.fritz.box:
  2.21-7

To reinstall a package, run pkg.install (Listing 1). You can tell from the output whether the package was already installed, updated, or reinstalled, as the case may be. If a system provides no response at all, the package was already available in its up-to-date version. If you want to update the package lists explicitly (apt-get update), simply add the option refresh=True before the name of the package.

Processing files on Salt is simple, just like managing packages. Using the file module [13], you can not only request metadata on files (e.g., the current Linux privileges, the owner, the file size, and a few other facts), but also delete, append, or manipulate them using regular expressions. One module.function pair that proves to be very useful is file.append, with which you can append one or more lines to the file. Using file.comment and file.comment_line, you can comment out the lines of a file, and file.rename lets you can change its name. In the online documentation [13], you will find many examples demonstrating how to manipulate files simultaneously on multiple systems.

Listing 2 shows how to add one entry to the /etc/motd file. If you want to build up your knowledge with Salt, one experiment to follow this would be to reverse the change by first commenting out the newly added lines with a file module, then deleting them with another call.