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
The configuration file for the salt-master is located at /etc/salt/master. The available options are as follows:
Default: 5
The number of threads to start for receiving commands and replies from minions. If minions are stalling on replies because you have many minions, raise the worker_threads value.
worker_threads: 5
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
Default: /
The system root directory to operate from, change this to make Salt run from an alternative root
root_dir: /
Default: /etc/salt/pki
The directory to store the pki authentication keys.
pki_dir: /etc/salt/pki
Default: /var/cache/salt
The location used to store cache information, particularly the job information for executed salt commands.
cachedir: /var/cache/salt
Default: True
The master maintains a 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
Default:: /tmp/salt-unix
Set the location to use for creating Unix sockets for master process communication
Default: False
Open mode is a dangerous security feature. One problem encountered with pki authentication systems is that keys can become "mixed up" and authentication begins to fail. Open mode turns off authentication and tells the master to accept all authentication. This will clean up the pki keys received from the minions. Open mode should not be turned on for general use. Open mode should only be used for a short period of time to clean up pki keys. To turn on open mode set this value to True.
open_mode: False
Default: False
Enable auto_accept. This setting will automatically accept all incoming public keys from the minions
auto_accept: False
Default: False
Set to true to enable cython modules (.pyx files) to be compiled on the fly on the Salt master
cython_enable: False
Default: top.sls
The state system uses a "top" file to tell the minions what environment to use and what modules to use. The state_top file is defined relative to the root of the base environment
state_top: top.sls
Default: None
The external_nodes option allows Salt to gather data that would normally be placed in a top file from and external node controller. The external_nodes option is the executable that will return the ENC data. Remember that Salt will look for external nodes AND top files and combine the results if both are enabled and available!
external_nodes: cobbler-ext-nodes
Default: yaml_jinja
The renderer to use on the minions to render the state data
renderer: yaml_jinja
Default:: False
Set the global failhard flag, this informs all states to stop running states at the moment a single state fails
failhard: False
Default:: False
Set all state calls to only test if they are going to acctually make changes or just post what changes are going to be made
test: False
Default: base: [/srv/salt]
Salt runs a lightweight file server written in zeromq to deliver files to minions. This file server is built into the master daemon and does not require a dedicated port.
The file server works on environments passed to the master. Each environment can have multiple root directories. The subdirectories in the multiple file roots cannot match, otherwise the downloaded files will not be able to be reliably ensured. A base environment is required to house the top file. Example:
file_roots:
base:
- /srv/salt/
dev:
- /srv/salt/dev/services
- /srv/salt/dev/states
prod:
- /srv/salt/prod/services
- /srv/salt/prod/states
base:
- /srv/salt
Default: md5
The hash_type is the hash to use when discovering the hash of a file on the master server, the default is md5, but sha1, sha224, sha256, sha384 and sha512 are also supported.
hash_type: md5
Default: 1048576
The buffer size in the file server in bytes
file_buffer_size: 1048576
Set the environments and directorirs used to hold pillar sls data. This configuration is the same as file_roots:
Default: base: [/srv/pillar]
file_roots:
base:
- /srv/pillar/
dev:
- /srv/pillar/dev/
prod:
- /srv/pillar/prod/
base:
- /srv/pillar
The ext_pillar option allows for any number of external pillar interfaces to be called when populating pillar data. The configuration is based on ext_pillar functions. The available ext_pillar functions are: hiera, cmd_yaml. By default the ext_pillar interface is not configued to run.
Default:: None
ext_pillar:
- hiera: /etc/hiera.yaml
- cmd: cat /etc/salt/yaml
A Salt syndic is a Salt master used to pass commands from a higher Salt master to minions below the syndic. Using the syndic is simple. If this is a master that will have syndic servers(s) below it, set the "order_masters" setting to True. If this is a master that will be running a syndic daemon for passthrough the "syndic_master" setting needs to be set to the location of the master server
Default: False
Extra data needs to be sent with publications if the master is controlling a lower level master via a syndic minion. If this is the case the order_masters value must be set to True
order_masters: False
Default: None
If this master will be running a salt-syndic to connect to a higher level master, specify the higher level master with this configuration value
syndic_master: masterofmasters
Salt minions can send commands to other minions, but only if the minion is allowed to. By default "Peer Publication" is disabled, and when enabled it is enabled for specific minions and specific commands. This allows secure compartmentalization of commands based on individual minions.
Default: {}
The configuration uses regular expressions to match minions and then a list of regular expressions to match functions. The following will allow the minion authenticated as foo.example.com to execute functions from the test and pkg modules
peer:
foo.example.com:
- test.*
- pkg.*
This will allow all minions to execute all commands:
peer:
.*:
- .*
This is not recommended, since it would allow anyone who gets root on any single minion to instantly have root on all of the minions!
Default: {}
The peer_run option is used to open up runners on the master to access from the minions. The peer_run configuration matches the format of the peer configuration.
The following example would allow foo.example.com to execute the manage.up runner:
peer_run:
foo.example.com:
- manage.up
Default: {}
Node groups allow for logical groupings of minion nodes. A group consists of a group name and a compound target.
nodegroups:
group1: 'L@foo.domain.com,bar.domain.com,baz.domain.com and bl*.domain.com'
group2: 'G@os:Debian and foo.domain.com'
Default: /var/log/salt/master
The location of the master log file
log_file: /var/log/salt/master
Default: warning
The level of messages to send to the log file. One of 'info', 'quiet', 'critical', 'error', 'debug', 'warning'.
log_level: warning
Default: {}
Logger levels can be used to tweak specific loggers logging levels. Imagine you want to have the Salt library at the 'warning' level, but you still wish to have 'salt.modules' at the 'debug' level:
log_granular_levels:
'salt': 'warning',
'salt.modules': 'debug'