Documentation< Previous | Contents | Next >
10.2.2. Executing Commands on Minions
As soon as minions are connected, you can execute commands on them from the master:
master# salt ’*’ test.ping
kali-scratch:
True kali-master:
True
master# salt ’*’ test.ping
kali-scratch:
True kali-master:
True
This command asks all minions (the ’*’ is a wildcard targeting all minions) to execute the ping function from the test execution module. This function returns a True value on success and is a simple way to ensure that the connection is working between the master and the various minions.
You can also target a specific minion by giving its identifier in the first parameter, or possibly a subset of minions by using a less-generic wildcard (such as ’*-scratch’ or ’kali-*’). Here is an example of how to execute an arbitrary shell command on the kali-scratch minion:
master# salt kali-scratch cmd.shell ’uptime; uname -a’
kali-scratch:
05:25:48 up 44 min, 2 users, load average: 0.00, 0.01, 0.05
Linux kali-scratch 4.5.0-kali1-amd64 #1 SMP Debian 4.5.3-2kali1 (2016-05-09) x86_64
➥ GNU/Linux
master# salt kali-scratch cmd.shell ’uptime; uname -a’
kali-scratch:
05:25:48 up 44 min, 2 users, load average: 0.00, 0.01, 0.05
Linux kali-scratch 4.5.0-kali1-amd64 #1 SMP Debian 4.5.3-2kali1 (2016-05-09) x86_64
➥ GNU/Linux
Salt Module Reference There are many execution modules available for all sorts of use cases. We won’t cover them all here, but the full list is available at https://docs.saltstack.com/ en/latest/ref/modules/all/index.html. You can also obtain a description of all the execution modules and their available functions on a given minion with the salt minion sys.doc command. Running this command returns a very long list of func- tions, but you can filter the list by passing the name of a function or module prefixed by its parent module as a parameter: | |
master# salt kali-scratch sys.doc disk.usage disk.usage: Return usage information for volumes mounted on this ➥ minion | |
One of the most useful modules is pkg, which is a package manager abstraction relying on the appropriate package manager for the system (apt-get for Debian and its derivatives like Kali).
The pkg.refresh_db command updates the package list (that is, it performs apt-get update) while pkg.upgrade installs all the available updates (it performs apt-get upgrade or apt-get dist-upgrade, depending on the options received). The pkg.list_upgrades command lists the pending upgrade operations (that would be performed by the pkg.upgrade dist_upgrade=True command).
The service module is an abstraction of the service manager (systemd in the case of Kali), which lets you perform all the usual systemctl operations: service.enable, service.disable, service. start, service.stop, service.restart, and service.reload:
master# salt ’*’ service.enable ssh
kali-scratch:
True kali-master:
True
master# salt ’*’ service.start ssh
kali-master:
True
kali-scratch:
True
master# salt ’*’ pkg.refresh_db
kali-scratch:
----------
kali-master:
----------
master# salt ’*’ pkg.upgrade dist_upgrade=True
kali-scratch:
----------
changes:
----------
base-files:
----------
new:
1:2016.2.1
old:
1:2016.2.0
[...]
zaproxy:
----------
new:
2.5.0-0kali1 old:
2.4.3-0kali3
comment: result:
True
master# salt ’*’ service.enable ssh
kali-scratch:
True kali-master:
True
master# salt ’*’ service.start ssh
kali-master:
True
kali-scratch:
True
master# salt ’*’ pkg.refresh_db
kali-scratch:
----------
kali-master:
----------
master# salt ’*’ pkg.upgrade dist_upgrade=True
kali-scratch:
----------
changes:
----------
base-files:
----------
new:
1:2016.2.1
old:
1:2016.2.0
[...]
zaproxy:
----------
new:
2.5.0-0kali1 old:
2.4.3-0kali3
comment: result:
True
As a more concrete sample, you could easily set up a distributed Nmap scan with dnmap. After having installed the package on all the minions, you start the server in a first terminal:
server# salt ’*’ pkg.install dnmap
[...]
server# vim dnmap.txt
server# dnmap_server -f dnmap.txt
server# salt ’*’ pkg.install dnmap
[...]
server# vim dnmap.txt
server# dnmap_server -f dnmap.txt
Assuming that the server IP is 1.2.3.4, you can next tell all minions to start a client process that connects to the server:
server# salt ’*’ cmd.run_bg template=jinja ’dnmap_client -s 1.2.3.4 -a {{ grains.id }}’
kali-scratch:
----------
pid:
17137
[...]
server# salt ’*’ cmd.run_bg template=jinja ’dnmap_client -s 1.2.3.4 -a {{ grains.id }}’
kali-scratch:
----------
pid:
17137
[...]
Note that the example uses cmd.run_bg to run the dnmap_client command in the background. Don’t wait until it finishes, since it is a long-running process. Unfortunately, it doesn’t kill itself properly when you interrupt the server so you might have to clean it up:
server# salt ’*’ cmd.shell ’pkill -f dnmap_client’
server# salt ’*’ cmd.shell ’pkill -f dnmap_client’