From ArchWiki
Jump to navigation Jump to search


Reason: Do not show systemctl commands. (Discuss in Talk:Saltstack#)




Install the salt package.

Components of Salt Stack


Salt Master

The default configuration is suitable for the vast majority of installations. Start and Enable the salt-master service.

The Salt master can also be started in the foreground in debug mode, greatly increasing the command output:

# salt-master -l debug


Salt Minion

The Salt Minion can operate with or without a Salt Master. This wiki assumes that the minion will be connected to the master. For information on how to run a master-less minion please see the masterless quickstart guide:



Now that the master can be found, Start and Enable the salt-minion service.

Or to run in debug mode

# salt-minion -l debug

Salt Key

Salt authenticates minion using public key encryption and authentication. For a minion to start accepting commands from the master the minion keys need to be accepted. The salt-key command is used to manage all of the keys on the master. To list the keys that are on the master run salt-key list command:

# salt-key -L


# salt-key -a

Or you can accept all keys at once with :

# salt-key -A

Salt Cloud

Salt can also be used to provision cloud servers on most major cloud providers. In order to connect to these providers, additional dependencies may be required. python-apache-libcloudAUR is required for many popular providers such as Rackspace and Amazon, and can be found in the community repositories. Further details for configuring your cloud provider can be found at the official wiki:

Salt commands

After connecting and accepting the minion on the Salt master you can now send commands to the minion. Salt commands allow for a vast set of functions to be executed and for specific minion and groups of minions to be targeted for execution. This makes the salt command very powerful, but the command is also very usable, and easy to understand.


# salt '*'


For more commands see documentation or run:

# salt '*' sys.doc

Salt States

In addition to running commands, salt can use what are known as states. A state is like a configuration file that allows setting up a new installation in the exact same way. A state can also be ran on that install after several weeks to make sure the computer is still in a known configuration.

Salt Environments

States can be separated into different environments. These environments can be used for making changes in a test environment before moving to a production machine, configuring a group of servers the same way, etc. The base environment is /srv/salt by default, and sometimes /srv/salt must be manually created.

Different environments can be set up in the salt-master file. Check /etc/salt/master for more info.

Creating a State

A state is a text file ending in *.sls located within a configured environment. This assumes the only the default base environment set up.

Create a file in /srv/salt called test.sls.

# vim /srv/salt/test.sls

Add the following to the file:

 pkg.installed: []

Now run the state:

# salt '*' state.apply test

Salt will search the base environment folder for anything called test.sls and apply the configuration it finds to all servers. In this case, netcat will be installed on all servers.

For more information on state file syntax and using states, see here:

The top file

The top file is the main way to apply different configs to different servers at once. The top file is called top.sls and is placed in the root of an environment. The top file configuration can be ran with the following command.

# salt '*' state.apply

Let us assume we have 2 servers: fs01, web01. Let us also assume we have 3 states in the base environment: nettools.sls, samba.sls, apache.sls. Here is a sample top file.

# Applied to all servers

# Applied only to fs01

# Applied only to web01

When state.apply is ran, the top file is read, and the states are applied to the correct servers. IE: nettools on all servers, samba on fs01, apache on web01.

Scheduling Tasks

Enable the salt scheduler on the minion with

salt 'minion-name' schedule.enable

and Install python2-dateutil on the master and any minions that will be using the scheduler and restart the salt-minion service on that server. Remember, you can easily install python2-dateutil and restart the salt-minion service on all minions using a state or a salt '*' command.

Assume samba.sls, stored in /srv/salt, needs to be run every Monday on fs01. This can be accomplished by placing the following into a state file and running it.

     - function: state.sls
     - job_args:
       - samba
     - when:
       - Monday 5:00am


salt 'minion-name' schedule.list

to verify the job was placed on the schedule.

A point to note. In the config file above, specifying state.sls for the function is how you specify job_args is receiving a state called samba. Do NOT try substituting state.sls with samba.sls or any other sls file. Function simply tells the scheduler how to treat jobs_args.

For more details on configuring schedules, see

See also