neulab/tldr huggingface dataset:
Copy the master.pub fingerprint from the Local Keys section, and then set this value as the master_finger in the minion configuration file. Save the configuration file and then restart the Salt minion.
Minion Key Fingerprint Run the following command on each Salt minion to view the minion key fingerprint:
salt-call --local key.finger
Compare this value to the value that is displayed when you run the salt-key --finger <MINION_ID> command on the Salt master.
Key Management Salt uses AES encryption for all communication between the Master and the Minion. This ensures that the commands sent to the Minions cannot be tampered with, and that communication between Master and Minion is authenticated through trusted, accepted keys.
Before commands can be sent to a Minion, its key must be accepted on the Master. Run the salt-key command to list the keys known to the Salt Master:
[root@master ~]# salt-key -L Unaccepted Keys: alpha bravo charlie delta Accepted Keys:
This example shows that the Salt Master is aware of four Minions, but none of the keys has been accepted. To accept the keys and allow the Minions to be controlled by the Master, again use the salt-key command:
[root@master ~]# salt-key -A [root@master ~]# salt-key -L Unaccepted Keys: Accepted Keys: alpha bravo charlie delta
The salt-key command allows for signing keys individually or in bulk. The example above, using -A bulk-accepts all pending keys. To accept keys individually use the lowercase of the same option, -a keyname.
SEE ALSO: salt-key manpage
Sending Commands Communication between the Master and a Minion may be verified by running the test.version command:
[root@master ~]# salt alpha test.version alpha: 2018.3.4
Communication between the Master and all Minions may be tested in a similar way:
[root@master ~]# salt '*' test.version alpha: 2018.3.4 bravo: 2018.3.4 charlie: 2018.3.4 delta: 2018.3.4
Each of the Minions should send a 2018.3.4 response as shown above, or any other salt version installed.
What's Next? Understanding targeting is important. From there, depending on the way you wish to use Salt, you should also proceed to learn about Remote Execution and Configuration Management.
Additional Installation Guides Salt Bootstrap The Salt Bootstrap Script allows a user to install the Salt Minion or Master on a variety of system distributions and versions.
The Salt Bootstrap Script is a shell script is known as bootstrap-salt.sh.  It runs through a series of checks to determine the operating system type and version. It then installs the Salt binaries using the appropriate methods.
The Salt Bootstrap Script installs the minimum number of packages required to run Salt. This means that in the event you run the bootstrap to install via package, Git will not be installed. Installing the minimum number of packages helps ensure the script stays as lightweight as possible, assuming the user will install any other required packages after the Salt binaries are present on the system.
The Salt Bootstrap Script is maintained in a separate repo from Salt, complete with its own issues, pull requests, contributing guidelines, release protocol, etc.
To learn more, please see the Salt Bootstrap repo links:
• Salt Bootstrap repo
• README: includes supported operating systems, example usage, and more.
• Contributing Guidelines
• Release Process
NOTE: The Salt Bootstrap script can be found in the Salt repo under the salt/cloud/deploy/bootstrap-salt.sh path. Any changes to this file will be overwritten! Bug fixes and feature additions must be submitted via the Salt Bootstrap repo. Please see the Salt Bootstrap Script's Release Process for more information.
Opening the Firewall up for Salt The Salt master communicates with the minions using an AES-encrypted ZeroMQ connection. These communications are done over TCP ports 4505 and 4506, which need to be accessible on the master only. This document outlines suggested firewall rules for allowing these incoming connections to the master.
NOTE: No firewall configuration needs to be done on Salt minions. These changes refer to the master only.
Fedora 18 and beyond / RHEL 7 / CentOS 7 Starting with Fedora 18 FirewallD is the tool that is used to dynamically manage the firewall rules on a host. It has support for IPv4/6 settings and the separation of runtime and permanent configurations. To interact with FirewallD use the command line client firewall-cmd.
firewall-cmd example:
firewall-cmd --permanent --zone=<zone> --add-port=4505-4506/tcp
A network zone defines the security level of trust for the network.  The user should choose an appropriate zone value for their setup.  Possible values include: drop, block, public, external, dmz, work, home, internal, trusted.
Don't forget to reload after you made your changes.
firewall-cmd --reload
RHEL 6 / CentOS 6 The lokkit command packaged with some Linux distributions makes opening iptables firewall ports very simple via the command line. Just be careful to not lock out access to the server by neglecting to open the ssh port.
lokkit example:
lokkit -p 22:tcp -p 4505:tcp -p 4506:tcp
The system-config-firewall-tui command provides a text-based interface to modifying the firewall.
system-config-firewall-tui:
system-config-firewall-tui
openSUSE Salt installs firewall rules in /etc/sysconfig/SuSEfirewall2.d/services/salt.  Enable with:
SuSEfirewall2 open SuSEfirewall2 start
If you have an older package of Salt where the above configuration file is not included, the SuSEfirewall2 command makes opening iptables firewall ports very simple via the command line.
SuSEfirewall example:
SuSEfirewall2 open EXT TCP 4505 SuSEfirewall2 open EXT TCP 4506
The firewall module in YaST2 provides a text-based interface to modifying the firewall.
YaST2:
yast2 firewall
Windows Windows Firewall is the default component of Microsoft Windows that provides firewalling and packet filtering. There are many 3rd party firewalls available for Windows, some of which use rules from the Windows Firewall. If you are experiencing problems see the vendor's specific documentation for opening the required ports.
The Windows Firewall can be configured using the Windows Interface or from the command line.
Windows Firewall (interface):
1. Open the Windows Firewall Interface by typing wf.msc at the command prompt or in a run dialog (Windows Key + R)
2. Navigate to Inbound Rules in the console tree
3. Add a new rule by clicking New Rule... in the Actions area
4. Change the Rule Type to Port. Click Next
5. Set the Protocol to TCP and specify local ports 4505-4506. Click Next
6. Set the Action to Allow the connection. Click Next
7. Apply the rule to Domain, Private, and Public. Click Next
8. Give the new rule a Name, ie: Salt. You may also add a description. Click Finish
Windows Firewall (command line):
The Windows Firewall rule can be created by issuing a single command. Run the following command from the command line or a run prompt:
netsh advfirewall firewall add rule name="Salt" dir=in action=allow protocol=TCP localport=4505-4506
iptables Different Linux distributions store their iptables (also known as netfilter) rules in different places, which makes it difficult to standardize firewall documentation. Included are some of the more common locations, but your mileage may vary.
Fedora / RHEL / CentOS:
Arch Linux:
/etc/iptables/iptables.rules
Follow these instructions: https://wiki.debian.org/iptables
Once you've found your firewall rules, you'll need to add the below line to allow traffic on tcp/4505 and tcp/4506:
-A INPUT -m state --state new -m tcp -p tcp --dport 4505:4506 -j ACCEPT
Salt installs firewall rules in /etc/ufw/applications.d/salt.ufw. Enable with:
ufw allow salt
pf.conf The BSD-family of operating systems uses packet filter (pf). The following example describes the addition to pf.conf needed to access the Salt master.
pass in on $int_if proto tcp from any to $int_if port 4505:4506
Once this addition has been made to the pf.conf the rules will need to be reloaded. This can be done using the pfctl command.
pfctl -vf /etc/pf.conf
Whitelist communication to Master There are situations where you want to selectively allow Minion traffic from specific hosts or networks into your Salt Master. The first scenario which comes to mind is to prevent unwanted traffic to your Master out of security concerns, but another scenario is to handle Minion upgrades when there are backwards incompatible changes between the installed Salt versions in your environment.
Here is an example Linux iptables ruleset to be set on the Master:
# Allow Minions from these networks -I INPUT -s 10.1.2.0/24 -p tcp --dports 4505:4506 -j ACCEPT -I INPUT -s 10.1.3.0/24 -p tcp --dports 4505:4506 -j ACCEPT # Allow Salt to communicate with Master on the loopback interface -A INPUT -i lo -p tcp --dports 4505:4506 -j ACCEPT # Reject everything else -A INPUT -p tcp --dports 4505:4506 -j REJECT
NOTE: The important thing to note here is that the salt command needs to communicate with the listening network socket of salt-master on the loopback interface. Without this you will see no outgoing Salt traffic from the master, even for a simple salt '*' test.version, because the salt client never reached the salt-master to tell it to carry out the execution.
Preseed Minion with Accepted Key In some situations, it is not convenient to wait for a minion to start before accepting its key on the master. For instance, you may want the minion to bootstrap itself as soon as it comes online. You may also want to let your developers provision new development machines on the fly.
SEE ALSO: Many ways to preseed minion keys
Salt has other ways to generate and pre-accept minion keys in addition to the manual steps outlined below.
salt-cloud performs these same steps automatically when new cloud VMs are created (unless instructed not to).
salt-api exposes an HTTP call to Salt's REST API to generate and download the new minion keys as a tarball.
There is a general four step process to do this:
1. Generate the keys on the master:
root@saltmaster# salt-key --gen-keys=[key_name]
Pick a name for the key, such as the minion's id.
2. Add the public key to the accepted minion folder:
root@saltmaster# cp key_name.pub /etc/salt/pki/master/minions/[minion_id]
It is necessary that the public key file has the same name as your minion id.  This is how Salt matches minions with their keys. Also note that the pki folder could be in a different location, depending on your OS or if specified in the master config file.
3. Distribute the minion keys.
There is no single method to get the keypair to your minion.  The difficulty is finding a distribution method which is secure. For Amazon EC2 only, an AWS best practice is to use IAM Roles to pass credentials. (See blog post, https://aws.amazon.com/blogs/security/using-iam-roles-to-distribute-non-aws-credentials-to-your-ec2-instances/ )
Since the minion key is already accepted on the master, distributing the private key poses a potential security risk. A malicious party will have access to your entire state tree and other sensitive data if they gain access to a preseeded minion key.
4. Preseed the Minion with the keys
You will want to place the minion keys before starting the salt-minion daemon:
/etc/salt/pki/minion/minion.pem /etc/salt/pki/minion/minion.pub
Once in place, you should be able to start salt-minion and run salt-call state.apply or any other salt commands that require master authentication.
The macOS (Maverick) Developer Step By Step Guide To Salt Installation This document provides a step-by-step guide to installing a Salt cluster consisting of  one master, and one minion running on a local VM hosted on macOS.
NOTE: This guide is aimed at developers who wish to run Salt in a virtual machine.  The official (Linux) walkthrough can be found here.
The 5 Cent Salt Intro Since you're here you've probably already heard about Salt, so you already know Salt lets you configure and run commands on hordes of servers easily.  Here's a brief overview of a Salt cluster:
• Salt works by having a "master" server sending commands to one or multiple "minion" servers. The master server is the "command center". It is going to be the place where you store your configuration files, aka: "which server is the db, which is the web server, and what libraries and software they should have installed". The minions receive orders from the master.  Minions are the servers actually performing work for your business.
• Salt has two types of configuration files:
1. the "salt communication channels" or "meta"  or "config" configuration files (not official names): one for the master (usually is /etc/salt/master , on the master server), and one for minions (default is /etc/salt/minion or /etc/salt/minion.conf, on the minion servers). Those files are used to determine things like the Salt Master IP, port, Salt folder locations, etc.. If these are configured incorrectly, your minions will probably be unable to receive orders from the master, or the master will not know which software a given minion should install.
2. the "business" or "service" configuration files (once again, not an official name): these are configuration files, ending with ".sls" extension, that describe which software should run on which server, along with particular configuration properties for the software that is being installed. These files should be created in the /srv/salt folder by default, but their location can be changed using ... /etc/salt/master configuration file!
NOTE: This tutorial contains a third important configuration file, not to be confused with the previous two: the virtual machine provisioning configuration file. This in itself is not specifically tied to Salt, but it also contains some Salt configuration. More on that in step 3. Also note that all configuration files are YAML files. So indentation matters.
NOTE: Salt also works with "masterless" configuration where a minion is autonomous (in which case salt can be seen as a local configuration tool), or in "multiple master" configuration. See the documentation for more on that.
Before Digging In, The Architecture Of The Salt Cluster Salt Master The "Salt master" server is going to be the Mac OS machine, directly. Commands will be run from a terminal app, so Salt will need to be installed on the Mac.  This is going to be more convenient for toying around with configuration files.
Salt Minion We'll only have one "Salt minion" server. It is going to be running on a Virtual Machine running on the Mac, using VirtualBox. It will run an Ubuntu distribution.
Step 1 - Configuring The Salt Master On Your Mac Official Documentation
Because Salt has a lot of dependencies that are not built in macOS, we will use Homebrew to install Salt. Homebrew is a package manager for Mac, it's great, use it (for this tutorial at least!). Some people spend a lot of time installing libs by hand to better understand dependencies, and then realize how useful a package manager is once they're configuring a brand new machine and have to do it all over again. It also lets you uninstall things easily.
NOTE: Brew is a Ruby program (Ruby is installed by default with your Mac). Brew downloads, compiles, and links software. The linking phase is when compiled software is deployed on your machine. It may conflict with manually installed software, especially in the /usr/local directory. It's ok, remove the manually installed version then refresh the link by typing brew link 'packageName'. Brew has a brew doctor command that can help you troubleshoot. It's a great command, use it often. Brew requires xcode command line tools. When you run brew the first time it asks you to install them if they're not already on your system. Brew installs software in /usr/local/bin (system bins are in /usr/bin). In order to use those bins you need your $PATH to search there first. Brew tells you if your $PATH needs to be fixed.
TIP: Use the keyboard shortcut cmd + shift + period in the "open" macOS dialog box to display hidden files and folders, such as .profile.
Install Homebrew Install Homebrew here https://brew.sh/
Or just type
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Now type the following commands in your terminal (you may want to type brew doctor after each to make sure everything's fine):
brew install python brew install swig brew install zmq
NOTE: zmq is ZeroMQ. It's a fantastic library used for server to server network communication and is at the core of Salt efficiency.
Install Salt You should now have everything ready to launch this command:
NOTE: There should be no need for sudo pip install salt. Brew installed Python for your user, so you should have all the access. In case you would like to check, type which python to ensure that it's /usr/local/bin/python, and which pip which should be /usr/local/bin/pip.
Now type python in a terminal then, import salt. There should be no errors. Now exit the Python terminal using exit().
Create The Master Configuration If the default /etc/salt/master configuration file was not created, copy-paste it from here: https://docs.saltproject.io/ref/configuration/examples.html#configuration-examples-master
NOTE: /etc/salt/master is a file, not a folder.
Salt Master configuration changes. The Salt master needs a few customization to be able to run on macOS:
In the /etc/salt/master file, change max_open_files to 8192 (or just add the line: max_open_files: 8192 (no quote) if it doesn't already exists).
You should now be able to launch the Salt master:
There should be no errors when running the above command.
NOTE: This command is supposed to be a daemon, but for toying around, we'll keep it running on a terminal to monitor the activity.
Now that the master is set, let's configure a minion on a VM.
Step 2 - Configuring The Minion VM The Salt minion is going to run on a Virtual Machine. There are a lot of software options that let you run virtual machines on a mac, But for this tutorial we're going to use VirtualBox. In addition to virtualBox, we will use Vagrant, which allows you to create the base VM configuration.
Vagrant lets you build ready to use VM images, starting from an OS image and customizing it using "provisioners". In our case, we'll use it to:
• Download the base Ubuntu image
• Install salt on that Ubuntu image (Salt is going to be the "provisioner" for the VM).
• Launch the VM
• SSH into the VM to debug
• Stop the VM once you're done.
Install VirtualBox Go get it here: https://www.virtualbox.org/wiki/Downloads (click on VirtualBox for macOS hosts => x86/amd64)
Install Vagrant Go get it here: https://www.vagrantup.com/downloads.html and choose the latest version (1.3.5 at time of writing), then the .dmg file. Double-click to install it.  Make sure the vagrant command is found when run in the terminal. Type vagrant. It should display a list of commands.
Create The Minion VM Folder Create a folder in which you will store your minion's VM. In this tutorial, it's going to be a minion folder in the $home directory.
cd $home mkdir minion
Initialize Vagrant From the minion folder, type
This command creates a default Vagrantfile configuration file. This configuration file will be used to pass configuration parameters to the Salt provisioner in Step 3.
Import Precise64 Ubuntu Box vagrant box add precise64 http://files.vagrantup.com/precise64.box
NOTE: This box is added at the global Vagrant level. You only need to do it once as each VM will use this same file.
Modify the Vagrantfile Modify ./minion/Vagrantfile to use th precise64 box. Change the config.vm.box line to:
config.vm.box = "precise64"
Uncomment the line creating a host-only IP. This is the ip of your minion (you can change it to something else if that IP is already in use):
config.vm.network :private_network, ip: "192.168.33.10"
At this point you should have a VM that can run, although there won't be much in it. Let's check that.
Checking The VM From the $home/minion folder type:
A log showing the VM booting should be present. Once it's done you'll be back to the terminal:
ping 192.168.33.10
The VM should respond to your ping request.
Now log into the VM in ssh using Vagrant again:
You should see the shell prompt change to something similar to vagrant@precise64:~$ meaning you're inside the VM. From there, enter the following:
ping 10.0.2.2
NOTE: That ip is the ip of your VM host (the macOS host). The number is a VirtualBox default and is displayed in the log after the Vagrant ssh command. We'll use that IP to tell the minion where the Salt master is.  Once you're done, end the ssh session by typing exit.
It's now time to connect the VM to the salt master
Step 3 - Connecting Master and Minion Creating The Minion Configuration File Create the /etc/salt/minion file. In that file, put the following lines, giving the ID for this minion, and the IP of the master:
master: 10.0.2.2 id: 'minion1' file_client: remote
Minions authenticate with the master using keys. Keys are generated automatically if you don't provide one and can accept them later on. However, this requires accepting the minion key every time the minion is destroyed or created (which could be quite often). A better way is to create those keys in advance, feed them to the minion, and authorize them once.
Preseed minion keys From the minion folder on your Mac run:
sudo salt-key --gen-keys=minion1
This should create two files: minion1.pem, and minion1.pub.  Since those files have been created using sudo, but will be used by vagrant, you need to change ownership:
sudo chown youruser:yourgroup minion1.pem sudo chown youruser:yourgroup minion1.pub
Then copy the .pub file into the list of accepted minions:
sudo cp minion1.pub /etc/salt/pki/master/minions/minion1
Modify Vagrantfile to Use Salt Provisioner Let's now modify the Vagrantfile used to provision the Salt VM. Add the following section in the Vagrantfile (note: it should be at the same indentation level as the other properties):
# salt-vagrant config config.vm.provision :salt do |salt| salt.run_highstate = true salt.minion_config = "/etc/salt/minion" salt.minion_key = "./minion1.pem" salt.minion_pub = "./minion1.pub" end
Now destroy the vm and recreate it from the /minion folder:
vagrant destroy vagrant up
If everything is fine you should see the following message:
"Bootstrapping Salt... (this may take a while) Salt successfully configured and installed!"
Checking Master-Minion Communication To make sure the master and minion are talking to each other, enter the following:
You should see your minion answering with its salt version. It's now time to do some configuration.
Step 4 - Configure Services to Install On the Minion In this step we'll use the Salt master to instruct our minion to install Nginx.
Checking the system's original state First, make sure that an HTTP server is not installed on our minion. When opening a browser directed at http://192.168.33.10/ You should get an error saying the site cannot be reached.
Initialize the top.sls file System configuration is done in /srv/salt/top.sls (and subfiles/folders), and then applied by running the state.apply function to have the Salt master order its minions to update their instructions and run the associated commands.
First Create an empty file on your Salt master (macOS machine):
touch /srv/salt/top.sls
When the file is empty, or if no configuration is found for our minion an error is reported:
sudo salt 'minion1' state.apply
This should return an error stating: No Top file or external nodes data matches found.
Create The Nginx Configuration Now is finally the time to enter the real meat of our server's configuration.  For this tutorial our minion will be treated as a web server that needs to have Nginx installed.
Insert the following lines into /srv/salt/top.sls (which should current be empty).
base: 'minion1': - bin.nginx
Now create /srv/salt/bin/nginx.sls containing the following:
nginx: pkg.installed: - name: nginx service.running: - enable: True - reload: True
Check Minion State Finally, run the state.apply function again:
You should see a log showing that the Nginx package has been installed and the service configured. To prove it, open your browser and navigate to http://192.168.33.10/, you should see the standard Nginx welcome page.
Where To Go From Here A full description of configuration management within Salt (sls files among other things) is available here: https://docs.saltproject.io/en/latest/index.html#configuration-management
running salt as normal user tutorial Before continuing make sure you have a working Salt installation by following the installation and the configuration instructions.
There are many ways to salt-community including our mailing list and our IRC channel #salt.
Running Salt functions as non root user If you don't want to run salt cloud as root or even install it you can configure it to have a virtual root in your working directory.
The salt system uses the salt.syspath module to find the variables
If you run the salt-build, it will generated in:
./build/lib.linux-x86_64-2.7/salt/_syspaths.py
To generate it, run the command:
python setup.py build
Copy the generated module into your salt directory
cp ./build/lib.linux-x86_64-2.7/salt/_syspaths.py salt/_syspaths.py
Edit it to include needed variables and your new paths
# you need to edit this _your_current_dir_ = ... ROOT_DIR = _your_current_dir_ + "/salt/root"
# you need to edit this _location_of_source_code_ = ... INSTALL_DIR = _location_of_source_code_
CONFIG_DIR = ROOT_DIR + "/etc/salt" CACHE_DIR = ROOT_DIR + "/var/cache/salt" SOCK_DIR = ROOT_DIR + "/var/run/salt" SRV_ROOT_DIR = ROOT_DIR + "/srv" BASE_FILE_ROOTS_DIR = ROOT_DIR + "/srv/salt" BASE_PILLAR_ROOTS_DIR = ROOT_DIR + "/srv/pillar" BASE_MASTER_ROOTS_DIR = ROOT_DIR + "/srv/salt-master" LOGS_DIR = ROOT_DIR + "/var/log/salt" PIDFILE_DIR = ROOT_DIR + "/var/run" CLOUD_DIR = INSTALL_DIR + "/cloud" BOOTSTRAP = CLOUD_DIR + "/deploy/bootstrap-salt.sh"
mkdir -p root/etc/salt root/var/cache/run root/run/salt root/srv root/srv/salt root/srv/pillar root/srv/salt-master root/var/log/salt root/var/run
Populate the configuration files:
cp -r conf/* root/etc/salt/
Edit your root/etc/salt/master configuration that is used by salt-cloud:
user: *your user name*
PYTHONPATH=`pwd` scripts/salt-cloud
Standalone Minion Since the Salt minion contains such extensive functionality it can be useful to run it standalone. A standalone minion can be used to do a number of things:
• Use salt-call commands on a system without connectivity to a master
• Masterless States, run states entirely from files local to the minion
NOTE: When running Salt in masterless mode, it is not required to run the salt-minion daemon. By default the salt-minion daemon will attempt to connect to a master and fail. The salt-call command stands on its own and does not need the salt-minion daemon.
As of version 2016.11.0 you can have a running minion (with engines and beacons) without a master connection. If you wish to run the salt-minion daemon you will need to set the master_type configuration setting to be set to 'disable'.
Minion Configuration Throughout this document there are several references to setting different options to configure a masterless Minion. Salt Minions are easy to configure via a configuration file that is located, by default, in /etc/salt/minion.  Note, however, that on FreeBSD systems, the minion configuration file is located in /usr/local/etc/salt/minion.
You can learn more about minion configuration options in the Configuring the Salt Minion docs.
Telling Salt Call to Run Masterless The salt-call command is used to run module functions locally on a minion instead of executing them from the master. Normally the salt-call command checks into the master to retrieve file server and pillar data, but when running standalone salt-call needs to be instructed to not check the master for this data. To instruct the minion to not look for a master when running salt-call the file_client configuration option needs to be set.  By default the file_client is set to remote so that the minion knows that file server and pillar data are to be gathered from the master. When setting the file_client option to local the minion is configured to not gather this data from the master.
file_client: local
Now the salt-call command will not look for a master and will assume that the local system has all of the file and pillar resources.
Running States Masterless The state system can be easily run without a Salt master, with all needed files local to the minion. To do this the minion configuration file needs to be set up to know how to return file_roots information like the master. The file_roots setting defaults to /srv/salt for the base environment just like on the master:
file_roots: base: - /srv/salt
Now set up the Salt State Tree, top file, and SLS modules in the same way that they would be set up on a master. Now, with the file_client option set to local and an available state tree then calls to functions in the state module will use the information in the file_roots on the minion instead of checking in with the master.
Remember that when creating a state tree on a minion there are no syntax or path changes needed, SLS modules written to be used from a master do not need to be modified in any way to work with a minion.
This makes it easy to "script" deployments with Salt states without having to set up a master, and allows for these SLS modules to be easily moved into a Salt master as the deployment grows.
The declared state can now be executed with:
salt-call state.apply
Or the salt-call command can be executed with the --local flag, this makes it unnecessary to change the configuration file:
salt-call state.apply --local
External Pillars External pillars are supported when running in masterless mode.
Salt Masterless Quickstart Running a masterless salt-minion lets you use Salt's configuration management for a single machine without calling out to a Salt master on another machine.
Since the Salt minion contains such extensive functionality it can be useful to run it standalone. A standalone minion can be used to do a number of things:
• Stand up a master server via States (Salting a Salt Master)
It is also useful for testing out state trees before deploying to a production setup.
Bootstrap Salt Minion The salt-bootstrap script makes bootstrapping a server with Salt simple for any OS with a Bourne shell:
curl -L https://bootstrap.saltstack.com -o bootstrap_salt.sh sudo sh bootstrap_salt.sh
See the salt-bootstrap documentation for other one liners. When using Vagrant to test out salt, the Vagrant salt provisioner will provision the VM for you.
Telling Salt to Run Masterless To instruct the minion to not look for a master, the file_client configuration option needs to be set in the minion configuration file. By default the file_client is set to remote so that the minion gathers file server and pillar data from the salt master.  When setting the file_client option to local the minion is configured to not gather this data from the master.
Now the salt minion will not look for a master and will assume that the local system has all of the file and pillar resources.
Configuration which resided in the master configuration (e.g. /etc/salt/master) should be moved to the minion configuration since the minion does not read the master configuration.
NOTE: When running Salt in masterless mode, do not run the salt-minion daemon.  Otherwise, it will attempt to connect to a master and fail. The salt-call command stands on its own and does not need the salt-minion daemon.
Create State Tree Following the successful installation of a salt-minion, the next step is to create a state tree, which is where the SLS files that comprise the possible states of the minion are stored.
The following example walks through the steps necessary to create a state tree that ensures that the server has the Apache webserver installed.
NOTE: For a complete explanation on Salt States, see the tutorial.
1. Create the top.sls file:
/srv/salt/top.sls:
base: '*': - webserver
2. Create the webserver state tree:
/srv/salt/webserver.sls:
apache:               # ID declaration pkg:                # state declaration - installed       # function declaration
NOTE: The apache package has different names on different platforms, for instance on Debian/Ubuntu it is apache2, on Fedora/RHEL it is httpd and on Arch it is apache
The only thing left is to provision our minion using salt-call.
Salt-call The salt-call command is used to run remote execution functions locally on a minion instead of executing them from the master. Normally the salt-call command checks into the master to retrieve file server and pillar data, but when running standalone salt-call needs to be instructed to not check the master for this data:
salt-call --local state.apply
The --local flag tells the salt-minion to look for the state tree in the local file system and not to contact a Salt Master for instructions.
To provide verbose output, use -l debug:
salt-call --local state.apply -l debug
The minion first examines the top.sls file and determines that it is a part of the group matched by * glob and that the webserver SLS should be applied.
It then examines the webserver.sls file and finds the apache state, which installs the Apache package.
The minion should now have Apache installed, and the next step is to begin learning how to write more complex states.
Dependencies Salt should run on any Unix-like platform so long as the dependencies are met.
• Python - Python2 >= 2.7, Python3 >= 3.4
• msgpack - High-performance message interchange format
• YAML - Python YAML bindings
• Jinja2 - parsing Salt States (configurable in the master settings)
• MarkupSafe - Implements a XML/HTML/XHTML Markup safe string for Python
• apache-libcloud - Python lib for interacting with many of the popular cloud service providers using a unified API
• Requests - HTTP library
• Tornado - Web framework and asynchronous networking library
• futures - Python2 only dependency. Backport of the concurrent.futures package from Python 3.2
• ZeroMQ:
• ZeroMQ >= 3.2.0
• pyzmq >= 2.2.0 - ZeroMQ Python bindings
• PyCrypto - The Python cryptography toolkit
WARNING: For historical reasons, Salt requires PyCrypto as a "lowest common denominator". However, PyCrypto is unmaintained and best practice is to manually upgrade to use a more maintained library such as PyCryptodome. See Issue #52674 and Issue #54115 for more info
Salt defaults to the ZeroMQ transport. The --salt-transport installation option is available, but currently only supports the zeromq option. This may be expanded in the future.
python setup.py --salt-transport=zeromq install
This way, only the required dependencies are pulled by the setup script if need be.
If installing using pip, the --salt-transport install option can be provided like:
pip install --install-option="--salt-transport=zeromq" salt
NOTE: Salt does not bundle dependencies that are typically distributed as part of the base OS. If you have unmet dependencies and are using a custom or minimal installation, you might need to install some additional packages from your OS vendor.
Optional Dependencies • mako - an optional parser for Salt States (configurable in the master settings)
• gcc - dynamic Cython module compiling
Upgrading Salt When upgrading Salt, the master(s) should always be upgraded first. Backward compatibility for minions running newer versions of salt than their masters is not guaranteed.
Whenever possible, backward compatibility between new masters and old minions will be preserved.  Generally, the only exception to this policy is in case of a security vulnerability.
SEE ALSO: Installing Salt for development and contributing to the project.
Building Packages using Salt Pack Salt-pack is an open-source package builder for most commonly used Linux platforms, for example: Redhat/CentOS and Debian/Ubuntu families, utilizing SaltStack states and execution modules to build Salt and a specified set of dependencies, from which a platform specific repository can be built.
https://github.com/saltstack/salt-pack
This section explains how to configure user access, view and store job results, secure and troubleshoot, and how to perform many other administrative tasks.
Configuring the Salt Master The Salt system is amazingly simple and easy to configure, the two components of the Salt system each have a respective configuration file. The salt-master is configured via the master configuration file, and the salt-minion is configured via the minion configuration file.
SEE ALSO: Example master configuration file.
The configuration file for the salt-master is located at /etc/salt/master by default. Atomic included configuration files can be placed in /etc/salt/master.d/*.conf. Warning: files with other suffixes than .conf will not be included. A notable exception is FreeBSD, where the configuration file is located at /usr/local/etc/salt. The available options are as follows:
Primary Master Configuration interface Default: 0.0.0.0 (all interfaces)
The local interface to bind to, must be an IP address.
interface: 192.168.0.1
ipv6 Default: False
Whether the master should listen for IPv6 connections. If this is set to True, the interface option must be adjusted too (for example: interface: '::')
ipv6: True
publish_port Default: 4505
The network port to set up the publication interface.
publish_port: 4505
master_id Default: None
The id to be passed in the publish job to minions. This is used for MultiSyndics to return the job to the requesting master.
NOTE: This must be the same string as the syndic is configured with.
master_id: MasterOfMaster
user Default: root
The user to run the Salt processes
enable_ssh_minions Default: False
Tell the master to also use salt-ssh when running commands against minions.
enable_ssh_minions: True
NOTE: Cross-minion communication is still not possible.  The Salt mine and publish.publish do not work between minion types.
ret_port Default: 4506
The port used by the return server, this is the server used by Salt to receive execution returns and command executions.
ret_port: 4506
pidfile Default: /var/run/salt-master.pid
Specify the location of the master pidfile.
pidfile: /var/run/salt-master.pid
root_dir Default: /
The system root directory to operate from, change this to make Salt run from an alternative root.
root_dir: /
NOTE: This directory is prepended to the following options: pki_dir, cachedir, sock_dir, log_file, autosign_file, autoreject_file, pidfile, autosign_grains_dir.
conf_file Default: /etc/salt/master
The path to the master's configuration file.
conf_file: /etc/salt/master
pki_dir Default: /etc/salt/pki/master
The directory to store the pki authentication keys.
pki_dir: /etc/salt/pki/master
extension_modules Changed in version 2016.3.0: The default location for this directory has been moved. Prior to this version, the location was a directory named extmods in the Salt cachedir (on most platforms, /var/cache/salt/extmods). It has been moved into the master cachedir (on most platforms, /var/cache/salt/master/extmods).
Directory for custom modules. This directory can contain subdirectories for each of Salt's module types such as runners, output, wheel, modules, states, returners, engines, utils, etc.  This path is appended to root_dir.
extension_modules: /root/salt_extmods
extmod_whitelist/extmod_blacklist New in version 2017.7.0.
By using this dictionary, the modules that are synced to the master's extmod cache using saltutil.sync_* can be limited.  If nothing is set to a specific type, then all modules are accepted.  To block all modules of a specific type, whitelist an empty list.
extmod_whitelist: modules: - custom_module engines: - custom_engine pillars: []
extmod_blacklist: modules: - specific_module
Valid options:
• modules
• states
• grains
• renderers
• returners
• output
• proxy
• runners
• wheel
• engines
• queues
• pillar
• utils
• sdb
• cache
• clouds
• tops
• roster
• tokens
module_dirs Default: []
Like extension_modules, but a list of extra directories to search for Salt modules.
module_dirs: - /var/cache/salt/minion/extmods
cachedir Default: /var/cache/salt/master
The location used to store cache information, particularly the job information for executed salt commands.
This directory may contain sensitive data and should be protected accordingly.
cachedir: /var/cache/salt/master
verify_env Default: True
Verify and set permissions on configuration directories at startup.
verify_env: True
keep_jobs Default: 24
Set the number of hours to keep old job information. Note that setting this option to 0 disables the cache cleaner.
keep_jobs: 24
gather_job_timeout New in version 2014.7.0.
Default: 10
The number of seconds to wait when the client is requesting information about running jobs.
gather_job_timeout: 10
timeout Default: 5
Set the default timeout for the salt command and api.
loop_interval Default: 60
The loop_interval option controls the seconds for the master's maintenance process check cycle. This process updates file server backends, cleans the job cache and executes the scheduler.
output Default: nested
Set the default outputter used by the salt command.
outputter_dirs Default: []
A list of additional directories to search for salt outputters in.
outputter_dirs: []
output_file Default: None
Set the default output file used by the salt command. Default is to output to the CLI and not to a file. Functions the same way as the "--out-file" CLI option, only sets this to a single file for all salt commands.
output_file: /path/output/file
show_timeout Default: True
Tell the client to show minions that have timed out.
show_timeout: True
show_jid Default: False
Tell the client to display the jid when a job is published.
show_jid: False
color Default: True
By default output is colored, to disable colored output set the color value to False.
color: False
color_theme Default: ""
Specifies a path to the color theme to use for colored command line output.
color_theme: /etc/salt/color_theme
cli_summary Default: False
When set to True, displays a summary of the number of minions targeted, the number of minions returned, and the number of minions that did not return.
cli_summary: False
sock_dir Default: /var/run/salt/master
Set the location to use for creating Unix sockets for master process communication.
sock_dir: /var/run/salt/master
enable_gpu_grains Default: False
Enable GPU hardware data for your master. Be aware that the master can take a while to start up when lspci and/or dmidecode is used to populate the grains for the master.
enable_gpu_grains: True
skip_grains Default: False
MasterMinions should omit grains. A MasterMinion is "a minion function object for generic use on the master" that omit pillar. A RunnerClient creates a MasterMinion omitting states and renderer. Setting to True can improve master performance.
skip_grains: True
job_cache Default: True
The master maintains a temporary job cache. While this is a great addition, it can be a burden on the master for larger deployments (over 5000 minions).  Disabling the job cache will make previously executed jobs unavailable to the jobs system and is not generally recommended. Normally it is wise to make sure the master has access to a faster IO system or a tmpfs is mounted to the jobs dir.
job_cache: True
NOTE: Setting the job_cache to False will not cache minion returns, but the JID directory for each job is still created. The creation of the JID directories is necessary because Salt uses those directories to check for JID collisions. By setting this option to False, the job cache directory, which is /var/cache/salt/master/jobs/ by default, will be smaller, but the JID directories will still be present.
Note that the keep_jobs option can be set to a lower value, such as 1, to limit the number of hours jobs are stored in the job cache. (The default is 24 hours.)
Please see the Managing the Job Cache documentation for more information.
minion_data_cache Default: True
The minion data cache is a cache of information about the minions stored on the master, this information is primarily the pillar, grains and mine data. The data is cached via the cache subsystem in the Master cachedir under the name of the minion or in a supported database. The data is used to predetermine what minions are expected to reply from executions.
minion_data_cache: True
cache Default: localfs
Cache subsystem module to use for minion data cache.
cache: consul
memcache_expire_seconds Default: 0
Memcache is an additional cache layer that keeps a limited amount of data fetched from the minion data cache for a limited period of time in memory that makes cache operations faster. It doesn't make much sense for the localfs cache driver but helps for more complex drivers like consul.
This option sets the memcache items expiration time. By default is set to 0 that disables the memcache.
memcache_expire_seconds: 30
memcache_max_items Default: 1024
Set memcache limit in items that are bank-key pairs. I.e the list of minion_0/data, minion_0/mine, minion_1/data contains 3 items. This value depends on the count of minions usually targeted in your environment. The best one could be found by analyzing the cache log with memcache_debug enabled.
memcache_max_items: 1024
memcache_full_cleanup Default: False
If cache storage got full, i.e. the items count exceeds the memcache_max_items value, memcache cleans up its storage. If this option set to False memcache removes the only one oldest value from its storage. If this set set to True memcache removes all the expired items and also removes the oldest one if there are no expired items.
memcache_full_cleanup: True
memcache_debug Default: False
Enable collecting the memcache stats and log it on debug log level. If enabled memcache collect information about how many fetch calls has been done and how many of them has been hit by memcache. Also it outputs the rate value that is the result of division of the first two values. This should help to choose right values for the expiration time and the cache size.
memcache_debug: True
ext_job_cache Default: ''
Used to specify a default returner for all minions. When this option is set, the specified returner needs to be properly configured and the minions will always default to sending returns to this returner. This will also disable the local job cache on the master.
ext_job_cache: redis
event_return New in version 2015.5.0.
Default: ''
Specify the returner(s) to use to log events. Each returner may have installation and configuration requirements. Read the returner's documentation.
NOTE: Not all returners support event returns. Verify that a returner has an event_return() function before configuring this option with a returner.
event_return: - syslog - splunk
event_return_queue New in version 2015.5.0.
Default: 0
On busy systems, enabling event_returns can cause a considerable load on the storage system for returners. Events can be queued on the master and stored in a batched fashion using a single transaction for multiple events.  By default, events are not queued.
event_return_queue: 0
event_return_whitelist New in version 2015.5.0.
Default: []
Only return events matching tags in a whitelist.
Changed in version 2016.11.0: Supports glob matching patterns.
event_return_whitelist: - salt/master/a_tag - salt/run/*/ret
event_return_blacklist New in version 2015.5.0.
Store all event returns _except_ the tags in a blacklist.
event_return_blacklist: - salt/master/not_this_tag - salt/wheel/*/ret
max_event_size New in version 2014.7.0.
Default: 1048576
Passing very large events can cause the minion to consume large amounts of memory. This value tunes the maximum size of a message allowed onto the master event bus. The value is expressed in bytes.
max_event_size: 1048576
master_job_cache New in version 2014.7.0.
Default: local_cache
Specify the returner to use for the job cache. The job cache will only be interacted with from the salt master and therefore does not need to be accessible from the minions.
master_job_cache: redis
job_cache_store_endtime New in version 2015.8.0.
Default: False
Specify whether the Salt Master should store end times for jobs as returns come in.
job_cache_store_endtime: False
enforce_mine_cache Default: False
By-default when disabling the minion_data_cache mine will stop working since it is based on cached data, by enabling this option we explicitly enabling only the cache for the mine system.
enforce_mine_cache: False
max_minions Default: 0
The maximum number of minion connections allowed by the master. Use this to accommodate the number of minions per master if you have different types of hardware serving your minions. The default of 0 means unlimited connections.  Please note that this can slow down the authentication process a bit in large setups.
max_minions: 100
con_cache Default: False