Executing commands remotely

The underlying architecture of Salt is based on the idea of executing commands remotely. This is not a new concept; all networking is designed around some aspect of remote execution. This could be as simple as asking a remote web server to display a static Web page, or as complex as using a shell session to interactively issue commands against a remote server.

Under the hood, Salt is a more complex example of remote execution. But whereas most Internet users are used to interacting with only one server at a time (so far as they are aware), Salt is designed to allow users to explicitly target and issue commands to multiple machines directly.

Master and minions

Salt is based around the idea of a master, which controls one or more minions. Commands are normally issued from the master to a target group of minions, which then execute the tasks specified in the commands and return any resulting data back to the master.

Targeting minions

The first facet of the salt command is targeting. A target must be specified with each execution, which matches one or more minions. By default, the type of target is a glob, which is the style of pattern matching used by many command shells. Other types of targeting are also available, by adding a flag. For instance, to target a group of machines inside a particular subnet, the -S option is used:

# salt -S 192.168.0.0/24 test.ping

The following are most of the available target types, along with some basic usage examples. Not all target types are covered here; Range, for example, extends beyond the scope of this book. However, the most common types are covered.

Glob

This is the default target type for Salt, so it does not have a command line option. The minion ID of one or more minions can be specified, using shell wildcards if desired.

When the salt command is issued from most command shells, wildcard characters must be protected from shell expansion:

# salt '*' test.ping
# salt \* test.ping

When using Salt from an API or from other user interfaces, quoting and escaping wildcard characters is generally not required.

Perl Compatible Regular Expression (PCRE)

Short Option: -E

Long Option: --pcre

When more complex pattern matching is required, a Perl Compatible Regular Expression (PCRE) can be used. This type of targeting was added to the earliest versions of Salt, and was meant largely to be used inside shell scripts. However, its power can still be realized from the command line:

# salt -E '^[m|M]in.[e|o|u]n$' test.ping

List

Short Option: -L

Long Option: --list

This option allows multiple minions to be specified as a comma-separated list. The items in this list do not use pattern matching such as globbing or regular expressions; they must be declared explicitly:

# salt -L web1,web2,db1,proxy1 test.ping

Subnet

Short Option: -S

Long Option: --ipcidr

Minions may be targeted based on a specific IPv4 or an IPv4 subnet in CIDR notation:

# salt -S 192.168.0.42 test.ping
# salt -S 192.168.0.0/16 test.ping

As of Salt version 2016.3, IPv6 addresses cannot be targeted by a specific command line option. However, there are other ways to target IPv6 addresses. One way is to use grain matching.

Grain

Short Version: -G

Long Version: --grain

Salt can target minions based on individual pieces of information that describe the machine. This can range from the OS to CPU architecture to custom information (covered in more detail later in this chapter). Because some network information is also available as grains, IP addresses can also be targeted this way.

Since grains are specified as key/value pairs, both the name of the key and the value must be specified. These are separated by a colon:

# salt -G 'os:Ubuntu' test.ping
# salt -G 'os_family:Debian' test.ping

Some grains are returned in a multi-level dictionary. These can be accessed by separating each key of the dictionary with a colon:

# salt -G 'ip_interfaces:eth0:192.168.11.38'

Grains which contain colons may also be specified, though it may look strange. The following will match the local IPv6 address (::1). Note the number of colons used:

# salt -G 'ipv6:::1' test.ping

Grain PCRE

Short Version: (not available)

Long Version: --grain-pcre

Matching by grains can be powerful, but the ability to match by a more complex pattern is even more so.

# salt --grain-pcre 'os:red(hat|flag)' test.ping

Pillar

Short Option: -I

Long Option: --pillar

It is also possible to match based on pillar data. Pillars are described in more detail later in the chapter, but for now we can just think of them as variables that look like grains.

# salt -I 'my_var:my_val' test.ping

Compound

Short Option: -C

Long Option: --compound

Compound targets allow the user to specify multiple target types in a single command. By default, globs are used, but other target types may be specified by preceding the target with the corresponding letter followed by the @ sign:

Letter	Target
G	Grains
E	PCRE minion ID
P	PCRE grains
L	List
I	Pillar
J	Pillar PCRE
S	Subnet/IP address
R	SECO range

The following command will target the minions that are running Ubuntu, have the role pillar set to web, and are in the 192.168.100.0/24 subnet.

# salt -C 'G@os:Ubuntu and I@role:web and S@192.168.100.0/24' test.ping

Boolean grammar may also be used to join target types, including and, or, and not operators.

# salt -C 'min* or *ion' test.ping
# salt -C 'web* or *qa and G@os:Arch' test.ping

Nodegroup

Short Option: -N

Long Option: --nodegroup

While nodegroups are used internally in Salt (all targeting ultimately results in the creation of an on-the-fly nodegroup), it is much less common to explicitly use them from the command line. Node groups must be defined as a list of targets (using compound syntax) in the Salt master's configuration before they can be used from the command line. Such a configuration might look like the following:

nodegroups: 
  webdev: 'I@role:web and G@cluster:dev'  webqa: 'I@role:web and
  G@cluster:qa'  webprod: 'I@role:web and G@cluster:prod'

Once a nodegroup is defined and the master configuration reloaded, it can be targeted from Salt:

# salt -N webdev test.ping

Using module functions

After a target is specified, a function must be declared. The preceding examples all use the test.ping function but, obviously, other functions are available. Functions are actually defined in two parts, separated by a period:

<module> . <function> 

Inside a Salt command, these follow the target, but precede any arguments that might be added for the function:

salt <target> <module>.<function> [arguments...] 

For instance, the following Salt command will ask all minions to return the text, "Hello world":

salt '*' test.echo 'Hello world'

A number of execution modules ship with the core Salt distribution, and it is possible to add more. Version 2016.3 of Salt ships with around 400 execution modules. Not all modules are available for every platform; in fact, by design, some modules will only be available to the user if they are able to detect the required underlying functionality.

For instance, all functions in the test module are necessarily available on all platforms. These functions are designed to test the basic functionality of Salt and the availability of minions. Functions in the Apache module, however, are only available if the necessary commands are located on the minion in question.

Execution modules are the basic building blocks of Salt; other modules in Salt use them for their heavy lifting. Because execution modules are generally designed to be used from the command line, an argument for a function can usually be passed as a string. However, some arguments are designed to be used from other parts of Salt. To use these arguments from the command line, a Python-like data structure is emulated using a JSON string.

This makes sense, since Salt is traditionally configured using YAML, and all JSON is syntactically-correct YAML. Be sure to surround the JSON with single quotes on the command line to avoid shell expansion, and use double quotes inside the string. The following examples will help.

A list is declared using brackets:

'["item1","item2","item3"]' 

A dictionary is declared using braces (that is, curly brackets):

'{"key1":"value1","key2":"value2","key3":"value3"}' 

A list can include a dictionary, and a dictionary can include a list:

'[{"key1":"value1"},{"key2":"value2"}]' 
'{"list1":["item1","item2"],"list2":["item3","item4"]}' 

There are a few modules which can be considered core to Salt, and a handful of functions in each that are widely used.

test.ping

This is the most basic Salt command. Ultimately, it only asks the minion to return True. This function is widely used in documentation because of its simplicity, and to check whether a minion is responding. Don't worry if a minion doesn't respond right away; that doesn't necessarily mean it's down. A number of variables could cause a slower-than-usual return. However, successive failed attempts may be cause for concern.

test.echo

This function does little more than the test.ping command; it merely asks the minion to echo back a string that is passed to it. A number of other functions exist that perform similar tasks, including test.arg, test.kwarg, test.arg_type, and test.arg_repr.

test.sleep

A slightly more advanced testing scenario may require a minion to sleep for a number of seconds before returning True. This is often used to test or demonstrate the utilities that make use of the jobs system. The test.rand_sleep function is also useful for test cases where it is desirable to check the return from a large number of minions, with the return process spread out.

test.version

In a large enough infrastructure, a number of minions are bound to be running in a different version of Salt than others. When troubleshooting issues specific to certain versions of Salt, it helps to be able to take a quick look at the Salt version on each minion. This is the simplest way to check that. Checking the version of other packages that are maintained by the system packaging system can be performed with pkg.version.

pkg.install

Every package manager in Salt (as of version 2016.3) supports installing a package. This function can be as simple as asking for a single package name, or as complex as passing through a list of packages, each with a specific version. When using an execution module, you generally do not need to specify more than just a single package name, but inside the state module (covered later) the advanced functionality becomes more important.

pkg.remove

This matches the pkg.install function, allowing a certain package to be removed. Because versions are not so important when removing packages, this function doesn't get so complex. But it does allow passing a list of packages to be removed (using the pkgs argument) as a Python list. From the command line, this can be done using a JSON string.

file.replace

The sed command is one of the oldest members of the Unix administrator's toolkit. It has been the go-to command largely for tasks that involve editing files inline, and performing search and replace tasks. There have been a few attempts over the years to duplicate the functionality of the sed command. Initially, the file.sed function simply wrapped the Unix sed command. The file.psed function provided a Python-based replacement. However, sed is more than just a find/replace tool; it is a full language that can be problematic when used incorrectly. The file.replace function was designed from the ground up to provide the find/replace functionality that most users need, while avoiding the subtle nuances that can be caused by wrapping sed.

Other file functions

A number of common Unix commands have been added to the file function. The following functions complement the Unix command set for managing files and their metadata: file.chown, file.chgrp, file.get_mode, file.set_mode, file.link, file.symlink, file.rename, file.copy, file.move, file.remove, file.mkdir, file.makedirs, file.mknod, and a number of others.

Various user and group functions

The Unix toolset for managing users and groups is also available in Salt and includes user.add, user.delete, user.info, group.add, group.delete, group.info, user.chuid, user.chgid, user.chshell, user.chhome, user.chgroups, and many, many more.

sys.doc

By design, every public function in every execution module must be self-documenting. The documentation that appears at the top of the function should contain a description just long enough to describe the general use of the function, and must include at least one CLI example demonstrating the usage of that function.

This documentation is available from the minion using the sys.doc function. Without any arguments, it will display all the functions available on a particular minion. Adding the name of a module will show only the available functions in that module, and adding the name of a function will show only the documentation for that function, if it is available. This is an extremely valuable tool, both for providing simple reminders of how to use a function and for discovering which modules are available.