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.
Primary Master Configuration
interface
Default: 0.0.0.0
(all interfaces)
The local interface to bind to, must be an IP address.
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: '::'
)
publish_port
Default: 4505
The network port to set up the publication interface.
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
max_open_files
Default: 100000
Each minion connecting to the master uses AT LEAST one file descriptor, the
master subscription connection. If enough minions connect you might start
seeing on the console(and then salt-master crashes):
Too many open files (tcp_listener.cpp:335)
Aborted (core dumped)
By default this value will be the one of ulimit -Hn, i.e., the hard limit for
max open files.
To set a different value than the default one, uncomment, and configure this
setting. Remember that this value CANNOT be higher than the hard limit. Raising
the hard limit depends on the OS and/or distribution, a good way to find the
limit is to search the internet for something like this:
raise max open files hard limit debian
worker_threads
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 should not be put below 3 when using the peer system, but can
drop down to 1 worker otherwise.
Note
When the master daemon starts, it is expected behaviour to see
multiple salt-master processes, even if 'worker_threads' is set to '1'. At
a minimum, a controlling process will start along with a Publisher, an
EventPublisher, and a number of MWorker processes will be started. The
number of MWorker processes is tuneable by the 'worker_threads'
configuration value while the others are not.
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.
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.
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
, etc. This path is appended to
root_dir
.
extension_modules: /root/salt_extmods
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.
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.
gather_job_timeout
Default: 10
The number of seconds to wait when the client is requesting information
about running jobs.
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.
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
color
Default: True
By default output is colored, to disable colored output set the color value
to False.
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.
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: True
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.
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.
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 and grains data. The data is
cached in the Master cachedir under the name of the minion and used to
predetermine what minions are expected to reply from executions.
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.
event_return
Default: ''
Specify the returner to use to log events. A 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: cassandra_cql
event_return_queue
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_whitelist
Default: []
Only return events matching tags in a whitelist.
event_return_whitelist:
- salt/master/a_tag
- salt/master/another_tag
event_return_blacklist
Default: []
Store all event returns _except_ the tags in a blacklist.
event_return_blacklist:
- salt/master/not_this_tag
- salt/master/or_this_one
max_event_size
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.
master_job_cache
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.
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.
con_cache
Default: False
If max_minions is used in large installations, the master might experience
high-load situations because of having to check the number of connected
minions for every authentication. This cache provides the minion-ids of
all connected minions to all MWorker-processes and greatly improves the
performance of max_minions.
presence_events
Default: False
Causes the master to periodically look for actively connected minions.
Presence events are fired on the event bus on a
regular interval with a list of connected minions, as well as events with lists
of newly connected or disconnected minions. This is a master-only operation
that does not send executions to minions. Note, this does not detect minions
that connect to a master via localhost.
transport
Default: zeromq
Changes the underlying transport layer. ZeroMQ is the recommended transport
while additional transport layers are under development. Supported values are
zeromq
, raet
(experimental), and tcp
(experimental). This setting has
a significant impact on performance and should not be changed unless you know
what you are doing! Transports are explained in Salt Transports.
transport_opts
Default: {}
(experimental) Starts multiple transports and overrides options for each transport with the provided dictionary
This setting has a significant impact on performance and should not be changed unless you know
what you are doing! Transports are explained in Salt Transports. The following example shows how to start a TCP transport alongside a ZMQ transport.
transport_opts:
tcp:
publish_port: 4605
ret_port: 4606
zeromq: []
Master Security Settings
open_mode
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
.
auto_accept
Default: False
Enable auto_accept. This setting will automatically accept all incoming
public keys from minions.
autosign_timeout
Default: 120
Time in minutes that a incoming public key with a matching name found in
pki_dir/minion_autosign/keyid is automatically accepted. Expired autosign keys
are removed when the master checks the minion_autosign directory. This method
to auto accept minions can be safer than an autosign_file because the
keyid record can expire and is limited to being an exact name match.
This should still be considered a less than secure option, due to the fact
that trust is based on just the requesting minion id.
autosign_file
Default: not defined
If the autosign_file
is specified incoming keys specified in the autosign_file
will be automatically accepted. Matches will be searched for first by string
comparison, then by globbing, then by full-string regex matching.
This should still be considered a less than secure option, due to the fact
that trust is based on just the requesting minion id.
autoreject_file
Default: not defined
Works like autosign_file
, but instead allows you to specify
minion IDs for which keys will automatically be rejected. Will override both
membership in the autosign_file
and the
auto_accept
setting.
publisher_acl
Default: {}
Enable user accounts on the master to execute specific modules. These modules
can be expressed as regular expressions. Note that client_acl option is
deprecated by publisher_acl option and will be removed in future releases.
publisher_acl:
fred:
- test.ping
- pkg.*
publisher_acl_blacklist
Default: {}
Blacklist users or modules
This example would blacklist all non sudo users, including root from
running any commands. It would also blacklist any use of the "cmd"
module. Note that client_acl_blacklist option is deprecated by
publisher_acl_blacklist option and will be removed in future releases.
This is completely disabled by default.
publisher_acl_blacklist:
users:
- root
- '^(?!sudo_).*$' # all non sudo users
modules:
- cmd
external_auth
Default: {}
The external auth system uses the Salt auth modules to authenticate and
validate users to access areas of the Salt system.
external_auth:
pam:
fred:
- test.*
token_expire
Default: 43200
Time (in seconds) for a newly generated token to live.
Default: 12 hours
file_recv
Default: False
Allow minions to push files to the master. This is disabled by default, for
security purposes.
file_recv_max_size
Default: 100
Set a hard-limit on the size of the files that can be pushed to the master.
It will be interpreted as megabytes.
master_sign_pubkey
Default: False
Sign the master auth-replies with a cryptographic signature of the master's
public key. Please see the tutorial how to use these settings in the
Multimaster-PKI with Failover Tutorial
master_sign_key_name
Default: master_sign
The customizable name of the signing-key-pair without suffix.
master_sign_key_name: <filename_without_suffix>
master_pubkey_signature
Default: master_pubkey_signature
The name of the file in the master's pki-directory that holds the pre-calculated
signature of the master's public-key.
master_pubkey_signature: <filename>
master_use_pubkey_signature
Default: False
Instead of computing the signature for each auth-reply, use a pre-calculated
signature. The master_pubkey_signature
must also be set for this.
master_use_pubkey_signature: True
rotate_aes_key
Default: True
Rotate the salt-masters AES-key when a minion-public is deleted with salt-key.
This is a very important security-setting. Disabling it will enable deleted
minions to still listen in on the messages published by the salt-master.
Do not disable this unless it is absolutely clear what this does.
allow_minion_key_revoke
Default: True
Controls whether a minion can request its own key revocation. When True
the master will honor the minion's request and revoke its key. When False,
the master will drop the request and the minion's key will remain accepted.
Master State System Settings
state_top
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.
master_tops
Default: {}
The master_tops option replaces the external_nodes option by creating
a pluggable system for the generation of external top data. The external_nodes
option is deprecated by the master_tops option.
To gain the capabilities of the classic external_nodes system, use the
following configuration:
master_tops:
ext_nodes: <Shell command which returns yaml>
external_nodes
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
renderer
Default: yaml_jinja
The renderer to use on the minions to render the state data.
jinja_trim_blocks
Default: False
If this is set to True
, the first newline after a Jinja block is
removed (block, not variable tag!). Defaults to False
and corresponds
to the Jinja environment init variable trim_blocks
.
jinja_lstrip_blocks
Default: False
If this is set to True
, leading spaces and tabs are stripped from the
start of a line to a block. Defaults to False
and corresponds to the
Jinja environment init variable lstrip_blocks
.
jinja_lstrip_blocks: False
failhard
Default: False
Set the global failhard flag. This informs all states to stop running states
at the moment a single state fails.
state_verbose
Default: True
Controls the verbosity of state runs. By default, the results of all states are
returned, but setting this value to False
will cause salt to only display
output for states that failed or states that have changes.
state_output
Default: full
The state_output setting changes if the output is the full multi line
output for each changed state if set to 'full', but if set to 'terse'
the output will be shortened to a single line. If set to 'mixed', the output
will be terse unless a state failed, in which case that output will be full.
If set to 'changes', the output will be full unless the state didn't change.
state_aggregate
Default: False
Automatically aggregate all states that have support for mod_aggregate by
setting to True
. Or pass a list of state module names to automatically
aggregate just those types.
state_events
Default: False
Send progress events as each function in a state run completes execution
by setting to True
. Progress events are in the format
salt/job/<JID>/prog/<MID>/<RUN NUM>
.
yaml_utf8
Default: False
Enable extra routines for YAML renderer used states containing UTF characters.
test
Default: False
Set all state calls to only test if they are going to actually make changes
or just post what changes are going to be made.
Master File Server Settings
fileserver_backend
Default: ['roots']
Salt supports a modular fileserver backend system, this system allows the salt
master to link directly to third party systems to gather and manage the files
available to minions. Multiple backends can be configured and will be searched
for the requested file in the order in which they are defined here. The default
setting only enables the standard backend roots
, which is configured using
the file_roots
option.
Example:
fileserver_backend:
- roots
- git
Note
For masterless Salt, this parameter must be specified in the minion config
file.
fileserver_followsymlinks
Default: True
By default, the file_server follows symlinks when walking the filesystem tree.
Currently this only applies to the default roots fileserver_backend.
fileserver_followsymlinks: True
fileserver_ignoresymlinks
Default: False
If you do not want symlinks to be treated as the files they are pointing to,
set fileserver_ignoresymlinks
to True
. By default this is set to
False. When set to True
, any detected symlink while listing files on the
Master will not be returned to the Minion.
fileserver_ignoresymlinks: False
fileserver_limit_traversal
Default: False
By default, the Salt fileserver recurses fully into all defined environments
to attempt to find files. To limit this behavior so that the fileserver only
traverses directories with SLS files and special Salt directories like _modules,
set fileserver_limit_traversal
to True
. This might be useful for
installations where a file root has a very large number of files and performance
is impacted.
fileserver_limit_traversal: False
hash_type
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.
file_buffer_size
Default: 1048576
The buffer size in the file server in bytes.
file_buffer_size: 1048576
file_ignore_regex
Default: ''
A regular expression (or a list of expressions) that will be matched
against the file path before syncing the modules and states to the minions.
This includes files affected by the file.recurse state.
For example, if you manage your custom modules and states in subversion
and don't want all the '.svn' folders and content synced to your minions,
you could set this to '/.svn($|/)'. By default nothing is ignored.
file_ignore_regex:
- '/\.svn($|/)'
- '/\.git($|/)'
file_ignore_glob
Default ''
A file glob (or list of file globs) that will be matched against the file
path before syncing the modules and states to the minions. This is similar
to file_ignore_regex above, but works on globs instead of regex. By default
nothing is ignored.
file_ignore_glob:
- '\*.pyc'
- '\*/somefolder/\*.bak'
- '\*.swp'
Note
Vim's .swp files are a common cause of Unicode errors in
file.recurse
states which use
templating. Unless there is a good reason to distribute them via the
fileserver, it is good practice to include '\*.swp'
in the
file_ignore_glob
.
roots: Master's Local File Server
file_roots
Default:
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
Note
For masterless Salt, this parameter must be specified in the minion config
file.
git: Git Remote File Server Backend
gitfs_remotes
Default: []
When using the git
fileserver backend at least one git remote needs to be
defined. The user running the salt master will need read access to the repo.
The repos will be searched in order to find the file requested by a client and
the first repo to have the file will return it. Branches and tags are
translated into salt environments.
gitfs_remotes:
- git://github.com/saltstack/salt-states.git
- file:///var/git/saltmaster
Note
file://
repos will be treated as a remote and copied into the master's
gitfs cache, so only the local refs for those repos will be exposed as
fileserver environments.
As of 2014.7.0, it is possible to have per-repo versions of several of the
gitfs configuration parameters. For more information, see the GitFS
Walkthrough.
gitfs_provider
Optional parameter used to specify the provider to be used for gitfs. More
information can be found in the GitFS Walkthrough.
Must be one of the following: pygit2
, gitpython
, or dulwich
. If
unset, then each will be tried in that same order, and the first one with a
compatible version installed will be the provider that is used.
gitfs_ssl_verify
Default: False
Specifies whether or not to ignore SSL certificate errors when contacting the
remote repository. The False
setting is useful if you're using a
git repo that uses a self-signed certificate. However, keep in mind that
setting this to anything other True
is a considered insecure, and using an
SSH-based transport (if available) may be a better option.
gitfs_mountpoint
Default: ''
Specifies a path on the salt fileserver which will be prepended to all files
served by gitfs. This option can be used in conjunction with
gitfs_root
. It can also be configured on a per-remote basis, see
here for more info.
gitfs_mountpoint: salt://foo/bar
Note
The salt://
protocol designation can be left off (in other words,
foo/bar
and salt://foo/bar
are equivalent). Assuming a file
baz.sh
in the root of a gitfs remote, and the above example mountpoint,
this file would be served up via salt://foo/bar/baz.sh
.
gitfs_root
Default: ''
Relative path to a subdirectory within the repository from which Salt should
begin to serve files. This is useful when there are files in the repository
that should not be available to the Salt fileserver. Can be used in conjunction
with gitfs_mountpoint
. If used, then from Salt's perspective the
directories above the one specified will be ignored and the relative path will
(for the purposes of gitfs) be considered as the root of the repo.
gitfs_root: somefolder/otherfolder
Changed in version 2014.7.0: Ability to specify gitfs roots on a per-remote basis was added. See
here for more info.
gitfs_base
Default: master
Defines which branch/tag should be used as the base
environment.
Changed in version 2014.7.0: Ability to specify the base on a per-remote basis was added. See here for more info.
gitfs_env_whitelist
Default: []
Used to restrict which environments are made available. Can speed up state runs
if the repos in gitfs_remotes
contain many branches/tags. More
information can be found in the GitFS Walkthrough.
gitfs_env_whitelist:
- base
- v1.*
- 'mybranch\d+'
gitfs_env_blacklist
Default: []
Used to restrict which environments are made available. Can speed up state runs
if the repos in gitfs_remotes
contain many branches/tags. More
information can be found in the GitFS Walkthrough.
gitfs_env_blacklist:
- base
- v1.*
- 'mybranch\d+'
gitfs_global_lock
Default: True
When set to False
, if there is an update lock for a gitfs remote and the
pid written to it is not running on the master, the lock file will be
automatically cleared and a new lock will be obtained. When set to True
,
Salt will simply log a warning when there is an update lock present.
On single-master deployments, disabling this option can help automatically deal
with instances where the master was shutdown/restarted during the middle of a
gitfs update, leaving a update lock in place.
However, on multi-master deployments with the gitfs cachedir shared via
GlusterFS, nfs, or another network filesystem, it is strongly recommended
not to disable this option as doing so will cause lock files to be removed if
they were created by a different master.
# Disable global lock
gitfs_global_lock: False
GitFS Authentication Options
These parameters only currently apply to the pygit2 gitfs provider. Examples of
how to use these can be found in the GitFS Walkthrough.
gitfs_user
Default: ''
Along with gitfs_password
, is used to authenticate to HTTPS
remotes.
gitfs_password
Default: ''
Along with gitfs_user
, is used to authenticate to HTTPS remotes.
This parameter is not required if the repository does not use authentication.
gitfs_password: mypassword
gitfs_insecure_auth
Default: False
By default, Salt will not authenticate to an HTTP (non-HTTPS) remote. This
parameter enables authentication over HTTP. Enable this at your own risk.
gitfs_insecure_auth: True
gitfs_passphrase
Default: ''
This parameter is optional, required only when the SSH key being used to
authenticate is protected by a passphrase.
gitfs_passphrase: mypassphrase
hg: Mercurial Remote File Server Backend
hgfs_remotes
Default: []
When using the hg
fileserver backend at least one mercurial remote needs to
be defined. The user running the salt master will need read access to the repo.
The repos will be searched in order to find the file requested by a client and
the first repo to have the file will return it. Branches and/or bookmarks are
translated into salt environments, as defined by the
hgfs_branch_method
parameter.
hgfs_remotes:
- https://username@bitbucket.org/username/reponame
Note
As of 2014.7.0, it is possible to have per-repo versions of the
hgfs_root
, hgfs_mountpoint
,
hgfs_base
, and hgfs_branch_method
parameters.
For example:
hgfs_remotes:
- https://username@bitbucket.org/username/repo1
- base: saltstates
- https://username@bitbucket.org/username/repo2:
- root: salt
- mountpoint: salt://foo/bar/baz
- https://username@bitbucket.org/username/repo3:
- root: salt/states
- branch_method: mixed
hgfs_branch_method
Default: branches
Defines the objects that will be used as fileserver environments.
branches
- Only branches and tags will be used
bookmarks
- Only bookmarks and tags will be used
mixed
- Branches, bookmarks, and tags will be used
hgfs_branch_method: mixed
Note
Starting in version 2014.1.0, the value of the hgfs_base
parameter defines which branch is used as the base
environment,
allowing for a base
environment to be used with an
hgfs_branch_method
of bookmarks
.
Prior to this release, the default
branch will be used as the base
environment.
hgfs_mountpoint
Default: ''
Specifies a path on the salt fileserver which will be prepended to all files
served by hgfs. This option can be used in conjunction with
hgfs_root
. It can also be configured on a per-remote basis, see
here
for more info.
hgfs_mountpoint: salt://foo/bar
Note
The salt://
protocol designation can be left off (in other words,
foo/bar
and salt://foo/bar
are equivalent). Assuming a file
baz.sh
in the root of an hgfs remote, this file would be served up via
salt://foo/bar/baz.sh
.
hgfs_root
Default: ''
Relative path to a subdirectory within the repository from which Salt should
begin to serve files. This is useful when there are files in the repository
that should not be available to the Salt fileserver. Can be used in conjunction
with hgfs_mountpoint
. If used, then from Salt's perspective the
directories above the one specified will be ignored and the relative path will
(for the purposes of hgfs) be considered as the root of the repo.
hgfs_root: somefolder/otherfolder
Changed in version 2014.7.0: Ability to specify hgfs roots on a per-remote basis was added. See
here
for more info.
hgfs_base
Default: default
Defines which branch should be used as the base
environment. Change this if
hgfs_branch_method
is set to bookmarks
to specify which
bookmark should be used as the base
environment.
hgfs_env_whitelist
Default: []
Used to restrict which environments are made available. Can speed up state runs
if your hgfs remotes contain many branches/bookmarks/tags. Full names, globs,
and regular expressions are supported. If using a regular expression, the
expression must match the entire minion ID.
If used, only branches/bookmarks/tags which match one of the specified
expressions will be exposed as fileserver environments.
If used in conjunction with hgfs_env_blacklist
, then the subset
of branches/bookmarks/tags which match the whitelist but do not match the
blacklist will be exposed as fileserver environments.
hgfs_env_whitelist:
- base
- v1.*
- 'mybranch\d+'
hgfs_env_blacklist
Default: []
Used to restrict which environments are made available. Can speed up state runs
if your hgfs remotes contain many branches/bookmarks/tags. Full names, globs,
and regular expressions are supported. If using a regular expression, the
expression must match the entire minion ID.
If used, branches/bookmarks/tags which match one of the specified expressions
will not be exposed as fileserver environments.
If used in conjunction with hgfs_env_whitelist
, then the subset
of branches/bookmarks/tags which match the whitelist but do not match the
blacklist will be exposed as fileserver environments.
hgfs_env_blacklist:
- base
- v1.*
- 'mybranch\d+'
svn: Subversion Remote File Server Backend
svnfs_remotes
Default: []
When using the svn
fileserver backend at least one subversion remote needs
to be defined. The user running the salt master will need read access to the
repo.
The repos will be searched in order to find the file requested by a client and
the first repo to have the file will return it. The trunk, branches, and tags
become environments, with the trunk being the base
environment.
svnfs_remotes:
- svn://foo.com/svn/myproject
Note
As of 2014.7.0, it is possible to have per-repo versions of the following
configuration parameters:
For example:
svnfs_remotes:
- svn://foo.com/svn/project1
- svn://foo.com/svn/project2:
- root: salt
- mountpoint: salt://foo/bar/baz
- svn//foo.com/svn/project3:
- root: salt/states
- branches: branch
- tags: tag
svnfs_mountpoint
Default: ''
Specifies a path on the salt fileserver which will be prepended to all files
served by hgfs. This option can be used in conjunction with
svnfs_root
. It can also be configured on a per-remote basis, see
here
for more info.
svnfs_mountpoint: salt://foo/bar
Note
The salt://
protocol designation can be left off (in other words,
foo/bar
and salt://foo/bar
are equivalent). Assuming a file
baz.sh
in the root of an svnfs remote, this file would be served up via
salt://foo/bar/baz.sh
.
svnfs_root
Default: ''
Relative path to a subdirectory within the repository from which Salt should
begin to serve files. This is useful when there are files in the repository
that should not be available to the Salt fileserver. Can be used in conjunction
with svnfs_mountpoint
. If used, then from Salt's perspective the
directories above the one specified will be ignored and the relative path will
(for the purposes of svnfs) be considered as the root of the repo.
svnfs_root: somefolder/otherfolder
Changed in version 2014.7.0: Ability to specify svnfs roots on a per-remote basis was added. See
here
for more info.
svnfs_trunk
Default: trunk
Path relative to the root of the repository where the trunk is located. Can
also be configured on a per-remote basis, see here
for more info.
svnfs_branches
Default: branches
Path relative to the root of the repository where the branches are located. Can
also be configured on a per-remote basis, see here
for more info.
svnfs_env_whitelist
Default: []
Used to restrict which environments are made available. Can speed up state runs
if your svnfs remotes contain many branches/tags. Full names, globs, and
regular expressions are supported. If using a regular expression, the expression
must match the entire minion ID.
If used, only branches/tags which match one of the specified expressions will
be exposed as fileserver environments.
If used in conjunction with svnfs_env_blacklist
, then the subset
of branches/tags which match the whitelist but do not match the blacklist
will be exposed as fileserver environments.
svnfs_env_whitelist:
- base
- v1.*
- 'mybranch\d+'
svnfs_env_blacklist
Default: []
Used to restrict which environments are made available. Can speed up state runs
if your svnfs remotes contain many branches/tags. Full names, globs, and
regular expressions are supported. If using a regular expression, the
expression must match the entire minion ID.
If used, branches/tags which match one of the specified expressions will not
be exposed as fileserver environments.
If used in conjunction with svnfs_env_whitelist
, then the subset
of branches/tags which match the whitelist but do not match the blacklist
will be exposed as fileserver environments.
svnfs_env_blacklist:
- base
- v1.*
- 'mybranch\d+'
minion: MinionFS Remote File Server Backend
minionfs_env
Default: base
Environment from which MinionFS files are made available.
minionfs_mountpoint
Default: ''
Specifies a path on the salt fileserver from which minionfs files are served.
minionfs_mountpoint: salt://foo/bar
Note
The salt://
protocol designation can be left off (in other words,
foo/bar
and salt://foo/bar
are equivalent).
minionfs_whitelist
Default: []
Used to restrict which minions' pushed files are exposed via minionfs. If using
a regular expression, the expression must match the entire minion ID.
If used, only the pushed files from minions which match one of the specified
expressions will be exposed.
If used in conjunction with minionfs_blacklist
, then the subset
of hosts which match the whitelist but do not match the blacklist will be
exposed.
minionfs_whitelist:
- server01
- dev*
- 'mail\d+.mydomain.tld'
minionfs_blacklist
Default: []
Used to restrict which minions' pushed files are exposed via minionfs. If using
a regular expression, the expression must match the entire minion ID.
If used, only the pushed files from minions which match one of the specified
expressions will not be exposed.
If used in conjunction with minionfs_whitelist
, then the subset
of hosts which match the whitelist but do not match the blacklist will be
exposed.
minionfs_blacklist:
- server01
- dev*
- 'mail\d+.mydomain.tld'
Pillar Configuration
pillar_roots
Default:
Set the environments and directories used to hold pillar sls data. This
configuration is the same as file_roots
:
pillar_roots:
base:
- /srv/pillar
dev:
- /srv/pillar/dev
prod:
- /srv/pillar/prod
on_demand_ext_pillar
New in version 2016.3.6,2016.11.3,Nitrogen.
Default: ['libvirt', 'virtkey']
The external pillars permitted to be used on-demand using pillar.ext
.
on_demand_ext_pillar:
- libvirt
- virtkey
- git
Warning
This will allow minions to request specific pillar data via
pillar.ext
, and may be considered a
security risk. However, pillar data generated in this way will not affect
the in-memory pillar data, so this risk is
limited to instances in which states/modules/etc. (built-in or custom) rely
upon pillar data generated by pillar.ext
.
pillar_opts
Default: False
The pillar_opts
option adds the master configuration file data to a dict in
the pillar called master
. This can be used to set simple configurations in
the master config file that can then be used on minions.
Note that setting this option to True
means the master config file will be
included in all minion's pillars. While this makes global configuration of services
and systems easy, it may not be desired if sensitive data is stored in the master
configuration.
ext_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 can be found herein:
https://github.com/saltstack/salt/blob/develop/salt/pillar
By default, the ext_pillar interface is not configured to run.
Default: []
ext_pillar:
- hiera: /etc/hiera.yaml
- cmd_yaml: cat /etc/salt/yaml
- reclass:
inventory_base_uri: /etc/reclass
There are additional details at Pillars
ext_pillar_first
Default: False
This option allows for external pillar sources to be evaluated before
pillar_roots
. External pillar data is evaluated separately from
pillar_roots
pillar data, and then both sets of pillar data are
merged into a single pillar dictionary, so the value of this config option will
have an impact on which key "wins" when there is one of the same name in both
the external pillar data and pillar_roots
pillar data. By
setting this option to True
, ext_pillar keys will be overridden by
pillar_roots
, while leaving it as False
will allow
ext_pillar keys to override those from pillar_roots
.
Note
For a while, this config option did not work as specified above, because of
a bug in Pillar compilation. This bug has been resolved in version 2016.3.4
and later.
Git External Pillar (git_pillar) Configuration Options
git_pillar_provider
Specify the provider to be used for git_pillar. Must be either pygit2
or
gitpython
. If unset, then both will be tried in that same order, and the
first one with a compatible version installed will be the provider that is
used.
git_pillar_provider: gitpython
git_pillar_base
Default: master
If the desired branch matches this value, and the environment is omitted from
the git_pillar configuration, then the environment for that git_pillar remote
will be base
. For example, in the configuration below, the foo
branch/tag would be assigned to the base
environment, while bar
would
be mapped to the bar
environment.
git_pillar_base: foo
ext_pillar:
- git:
- foo https://mygitserver/git-pillar.git
- bar https://mygitserver/git-pillar.git
git_pillar_branch
Default: master
If the branch is omitted from a git_pillar remote, then this branch will be
used instead. For example, in the configuration below, the first two remotes
would use the pillardata
branch/tag, while the third would use the foo
branch/tag.
git_pillar_branch: pillardata
ext_pillar:
- git:
- https://mygitserver/pillar1.git
- https://mygitserver/pillar2.git:
- root: pillar
- foo https://mygitserver/pillar3.git
git_pillar_env
Default: ''
(unset)
Environment to use for git_pillar remotes. This is normally derived from the
branch/tag (or from a per-remote env
parameter), but if set this will
override the process of deriving the env from the branch/tag name. For example,
in the configuration below the foo
branch would be assigned to the base
environment, while the bar
branch would need to explicitly have bar
configured as it's environment to keep it from also being mapped to the
base
environment.
git_pillar_env: base
ext_pillar:
- git:
- foo https://mygitserver/git-pillar.git
- bar https://mygitserver/git-pillar.git:
- env: bar
For this reason, this option is recommended to be left unset, unless the use
case calls for all (or almost all) of the git_pillar remotes to use the same
environment irrespective of the branch/tag being used.
git_pillar_root
Default: ''
Path relative to the root of the repository where the git_pillar top file and
SLS files are located. In the below configuration, the pillar top file and SLS
files would be looked for in a subdirectory called pillar
.
git_pillar_root: pillar
ext_pillar:
- git:
- master https://mygitserver/pillar1.git
- master https://mygitserver/pillar2.git
Note
This is a global option. If only one or two repos need to have their files
sourced from a subdirectory, then git_pillar_root
can be
omitted and the root can be specified on a per-remote basis, like so:
ext_pillar:
- git:
- master https://mygitserver/pillar1.git
- master https://mygitserver/pillar2.git:
- root: pillar
In this example, for the first remote the top file and SLS files would be
looked for in the root of the repository, while in the second remote the
pillar data would be retrieved from the pillar
subdirectory.
git_pillar_ssl_verify
Default: False
Specifies whether or not to ignore SSL certificate errors when contacting the
remote repository. The False
setting is useful if you're using a
git repo that uses a self-signed certificate. However, keep in mind that
setting this to anything other True
is a considered insecure, and using an
SSH-based transport (if available) may be a better option.
git_pillar_ssl_verify: True
git_pillar_global_lock
Default: True
When set to False
, if there is an update/checkout lock for a git_pillar
remote and the pid written to it is not running on the master, the lock file
will be automatically cleared and a new lock will be obtained. When set to
True
, Salt will simply log a warning when there is an lock present.
On single-master deployments, disabling this option can help automatically deal
with instances where the master was shutdown/restarted during the middle of a
git_pillar update/checkout, leaving a lock in place.
However, on multi-master deployments with the git_pillar cachedir shared via
GlusterFS, nfs, or another network filesystem, it is strongly recommended
not to disable this option as doing so will cause lock files to be removed if
they were created by a different master.
# Disable global lock
git_pillar_global_lock: False
Git External Pillar Authentication Options
These parameters only currently apply to the pygit2
git_pillar_provider
. Authentication works the same as it does
in gitfs, as outlined in the GitFS Walkthrough,
though the global configuration options are named differently to reflect that
they are for git_pillar instead of gitfs.
git_pillar_user
Default: ''
Along with git_pillar_password
, is used to authenticate to HTTPS
remotes.
git_pillar_password
Default: ''
Along with git_pillar_user
, is used to authenticate to HTTPS
remotes. This parameter is not required if the repository does not use
authentication.
git_pillar_password: mypassword
git_pillar_insecure_auth
Default: False
By default, Salt will not authenticate to an HTTP (non-HTTPS) remote. This
parameter enables authentication over HTTP. Enable this at your own risk.
git_pillar_insecure_auth: True
git_pillar_passphrase
Default: ''
This parameter is optional, required only when the SSH key being used to
authenticate is protected by a passphrase.
git_pillar_passphrase: mypassphrase
Pillar Merging Options
pillar_source_merging_strategy
Default: smart
The pillar_source_merging_strategy option allows you to configure merging
strategy between different sources. It accepts 5 values:
New in version 2016.3.4: It will not do any merging at all and only parse the pillar data from the passed environment and 'base' if no environment was specified.
recurse
:
it will merge recursively mapping of data. For example, theses 2 sources:
foo: 42
bar:
element1: True
bar:
element2: True
baz: quux
will be merged as:
foo: 42
bar:
element1: True
element2: True
baz: quux
aggregate
:
instructs aggregation of elements between sources that use the #!yamlex renderer.
For example, these two documents:
#!yamlex
foo: 42
bar: !aggregate {
element1: True
}
baz: !aggregate quux
#!yamlex
bar: !aggregate {
element2: True
}
baz: !aggregate quux2
will be merged as:
foo: 42
bar:
element1: True
element2: True
baz:
- quux
- quux2
overwrite
:
Will use the behaviour of the 2014.1 branch and earlier.
Overwrites elements according the order in which they are processed.
First pillar processed:
A:
first_key: blah
second_key: blah
Second pillar processed:
A:
third_key: blah
fourth_key: blah
will be merged as:
A:
third_key: blah
fourth_key: blah
smart
(default):
Guesses the best strategy based on the "renderer" setting.
pillar_merge_lists
Default: False
Recursively merge lists by aggregating them instead of replacing them.
pillar_merge_lists: False
Pillar Cache Options
pillar_cache
Default: False
A master can cache pillars locally to bypass the expense of having to render them
for each minion on every request. This feature should only be enabled in cases
where pillar rendering time is known to be unsatisfactory and any attendant security
concerns about storing pillars in a master cache have been addressed.
When enabling this feature, be certain to read through the additional pillar_cache_*
configuration options to fully understand the tunable parameters and their implications.
pillar_cache_ttl
Default: 3600
If and only if a master has set pillar_cache: True
, the cache TTL controls the amount
of time, in seconds, before the cache is considered invalid by a master and a fresh
pillar is recompiled and stored.
pillar_cache_backend
Default: disk
If an only if a master has set pillar_cache: True
, one of several storage providers
can be utilized:
disk
(default):
The default storage backend. This caches rendered pillars to the master cache.
Rendered pillars are serialized and deserialized as msgpack
structures for speed.
Note that pillars are stored UNENCRYPTED. Ensure that the master cache has permissions
set appropriately (sane defaults are provided).
memory
[EXPERIMENTAL]:
An optional backend for pillar caches which uses a pure-Python
in-memory data structure for maximal performance. There are several caveats,
however. First, because each master worker contains its own in-memory cache,
there is no guarantee of cache consistency between minion requests. This
works best in situations where the pillar rarely if ever changes. Secondly,
and perhaps more importantly, this means that unencrypted pillars will
be accessible to any process which can examine the memory of the salt-master
!
This may represent a substantial security risk.
pillar_cache_backend: disk
Syndic Server Settings
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.
Do not forget that, in other words, it means that it shares with the local minion
its ID and PKI directory.
order_masters
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
syndic_master
Changed in version 2016.3.5,2016.11.1: Set default higher level master address.
Default: masterofmasters
If this master will be running the salt-syndic
to connect to a higher level
master, specify the higher level master with this configuration value.
syndic_master: masterofmasters
You can optionally connect a syndic to multiple higher level masters by
setting the syndic_master
value to a list:
syndic_master:
- masterofmasters1
- masterofmasters2
Each higher level master must be set up in a multi-master configuration.
syndic_master_port
Default: 4506
If this master will be running the salt-syndic
to connect to a higher level
master, specify the higher level master port with this configuration value.
syndic_pidfile
Default: /var/run/salt-syndic.pid
If this master will be running the salt-syndic
to connect to a higher level
master, specify the pidfile of the syndic daemon.
syndic_pidfile: /var/run/syndic.pid
syndic_log_file
Default: /var/log/salt/syndic
If this master will be running the salt-syndic
to connect to a higher level
master, specify the log file of the syndic daemon.
syndic_log_file: /var/log/salt-syndic.log
syndic_failover
Default: random
The behaviour of the multi-syndic when connection to a master of masters failed.
Can specify random
(default) or ordered
. If set to random
, masters
will be iterated in random order. If ordered
is specified, the configured
order will be used.
syndic_wait
Default: 5
The number of seconds for the salt client to wait for additional syndics to
check in with their lists of expected minions before giving up.
Peer Publish Settings
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.
peer
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:
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!
By adding an additional layer you can limit the target hosts in addition to the
accessible commands:
peer:
foo.example.com:
'db*':
- test.*
- pkg.*
peer_run
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
Windows Software Repo Settings
winrepo_provider
Specify the provider to be used for winrepo. Must be either pygit2
or
gitpython
. If unset, then both will be tried in that same order, and the
first one with a compatible version installed will be the provider that is
used.
winrepo_provider: gitpython
winrepo_dir
Changed in version 2015.8.0: Renamed from win_repo
to winrepo_dir
.
Default: /srv/salt/win/repo
Location on the master where the winrepo_remotes
are checked out
for pre-2015.8.0 minions. 2015.8.0 and later minions use
winrepo_remotes_ng
instead.
winrepo_dir: /srv/salt/win/repo
winrepo_dir_ng
New in version 2015.8.0: A new ng repo was added.
Default: /srv/salt/win/repo-ng
Location on the master where the winrepo_remotes_ng
are checked
out for 2015.8.0 and later minions.
winrepo_dir_ng: /srv/salt/win/repo-ng
winrepo_cachefile
Changed in version 2015.8.0: Renamed from win_repo_mastercachefile
to winrepo_cachefile
Note
2015.8.0 and later minions do not use this setting since the cachefile
is now located on the minion.
Default: winrepo.p
Path relative to winrepo_dir
where the winrepo cache should be
created.
winrepo_cachefile: winrepo.p
winrepo_remotes
Changed in version 2015.8.0: Renamed from win_gitrepos
to winrepo_remotes
.
Default: ['https://github.com/saltstack/salt-winrepo.git']
List of git repositories to checkout and include in the winrepo for
pre-2015.8.0 minions. 2015.8.0 and later minions use
winrepo_remotes_ng
instead.
winrepo_remotes:
- https://github.com/saltstack/salt-winrepo.git
To specify a specific revision of the repository, prepend a commit ID to the
URL of the repository:
winrepo_remotes:
- '<commit_id> https://github.com/saltstack/salt-winrepo.git'
Replace <commit_id>
with the SHA1 hash of a commit ID. Specifying a commit
ID is useful in that it allows one to revert back to a previous version in the
event that an error is introduced in the latest revision of the repo.
winrepo_remotes_ng
New in version 2015.8.0: A new ng repo was added.
Default: ['https://github.com/saltstack/salt-winrepo-ng.git']
List of git repositories to checkout and include in the winrepo for
2015.8.0 and later minions.
winrepo_remotes_ng:
- https://github.com/saltstack/salt-winrepo-ng.git
To specify a specific revision of the repository, prepend a commit ID to the
URL of the repository:
winrepo_remotes:
- '<commit_id> https://github.com/saltstack/salt-winrepo-ng.git'
Replace <commit_id>
with the SHA1 hash of a commit ID. Specifying a commit
ID is useful in that it allows one to revert back to a previous version in the
event that an error is introduced in the latest revision of the repo.
winrepo_branch
Default: master
If the branch is omitted from a winrepo remote, then this branch will be
used instead. For example, in the configuration below, the first two remotes
would use the winrepo
branch/tag, while the third would use the foo
branch/tag.
winrepo_branch: winrepo
ext_pillar:
- git:
- https://mygitserver/winrepo1.git
- https://mygitserver/winrepo2.git:
- foo https://mygitserver/winrepo3.git
winrepo_ssl_verify
Default: False
Specifies whether or not to ignore SSL certificate errors when contacting the
remote repository. The False
setting is useful if you're using a
git repo that uses a self-signed certificate. However, keep in mind that
setting this to anything other True
is a considered insecure, and using an
SSH-based transport (if available) may be a better option.
Winrepo Authentication Options
These parameters only currently apply to the pygit2
winrepo_provider
. Authentication works the same as it does in
gitfs, as outlined in the GitFS Walkthrough,
though the global configuration options are named differently to reflect that
they are for winrepo instead of gitfs.
winrepo_user
Default: ''
Along with winrepo_password
, is used to authenticate to HTTPS
remotes.
winrepo_password
Default: ''
Along with winrepo_user
, is used to authenticate to HTTPS
remotes. This parameter is not required if the repository does not use
authentication.
winrepo_password: mypassword
winrepo_insecure_auth
Default: False
By default, Salt will not authenticate to an HTTP (non-HTTPS) remote. This
parameter enables authentication over HTTP. Enable this at your own risk.
winrepo_insecure_auth: True
winrepo_privkey
Default: ''
Along with winrepo_pubkey
(and optionally
winrepo_passphrase
), is used to authenticate to SSH remotes.
winrepo_privkey: /path/to/key
winrepo_passphrase
Default: ''
This parameter is optional, required only when the SSH key being used to
authenticate is protected by a passphrase.
winrepo_passphrase: mypassphrase