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.

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

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

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.

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

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

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

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:

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.