neulab/tldr huggingface dataset:
If used in conjunction with hgfs_saltenv_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_saltenv_blacklist: - base - v1.* - 'mybranch\d+'
hgfs_update_interval New in version 2018.3.0.
This option defines the update interval (in seconds) for hgfs_remotes.
hgfs_update_interval: 120
svnfs: Subversion Remote File Server Backend svnfs_remotes New in version 0.17.0.
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:
• svnfs_root
• svnfs_mountpoint
• svnfs_trunk
• svnfs_branches
• svnfs_tags
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 New in version 2014.7.0.
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 New in version 0.17.0.
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 New in version 2014.7.0.
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_trunk: trunk
svnfs_branches New in version 2014.7.0.
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_branches: branches
svnfs_tags New in version 2014.7.0.
Default: tags
Path relative to the root of the repository where the tags are located. Can also be configured on a per-remote basis, see here for more info.
svnfs_tags: tags
svnfs_saltenv_whitelist New in version 2014.7.0.
Changed in version 2018.3.0: Renamed from svnfs_env_whitelist to svnfs_saltenv_whitelist
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_saltenv_blacklist, then the subset of branches/tags which match the whitelist but do not match the blacklist will be exposed as fileserver environments.
svnfs_saltenv_whitelist: - base - v1.* - 'mybranch\d+'
svnfs_saltenv_blacklist New in version 2014.7.0.
Changed in version 2018.3.0: Renamed from svnfs_env_blacklist to svnfs_saltenv_blacklist
If used, branches/tags which match one of the specified expressions will not be exposed as fileserver environments.
If used in conjunction with svnfs_saltenv_whitelist, then the subset of branches/tags which match the whitelist but do not match the blacklist will be exposed as fileserver environments.
svnfs_saltenv_blacklist: - base - v1.* - 'mybranch\d+'
svnfs_update_interval New in version 2018.3.0.
This option defines the update interval (in seconds) for svnfs_remotes.
svnfs_update_interval: 120
minionfs: MinionFS Remote File Server Backend minionfs_env New in version 2014.7.0.
Default: base
Environment from which MinionFS files are made available.
minionfs_env: minionfs
minionfs_mountpoint New in version 2014.7.0.
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 New in version 2014.7.0.
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 New in version 2014.7.0.
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'
minionfs_update_interval New in version 2018.3.0.
This option defines the update interval (in seconds) for MinionFS.
NOTE: Since MinionFS consists of files local to the master, the update process for this fileserver backend just reaps the cache for this backend.
minionfs_update_interval: 120
azurefs: Azure File Server Backend New in version 2015.8.0.
See the azurefs documentation for usage examples.
azurefs_update_interval New in version 2018.3.0.
This option defines the update interval (in seconds) for azurefs.
azurefs_update_interval: 120
s3fs: S3 File Server Backend New in version 0.16.0.
See the s3fs documentation for usage examples.
s3fs_update_interval New in version 2018.3.0.
This option defines the update interval (in seconds) for s3fs.
s3fs_update_interval: 120
Pillar Configuration pillar_roots Default:
base: - /srv/pillar
Set the environments and directories used to hold pillar sls data. This configuration is the same as file_roots:
As of 2017.7.5 and 2018.3.1, it is possible to have __env__ as a catch-all environment.
pillar_roots: base: - /srv/pillar dev: - /srv/pillar/dev prod: - /srv/pillar/prod __env__: - /srv/pillar/others
on_demand_ext_pillar New in version 2016.3.6,2016.11.3,2017.7.0.
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.
decrypt_pillar New in version 2017.7.0.
A list of paths to be recursively decrypted during pillar compilation.
decrypt_pillar: - 'foo:bar': gpg - 'lorem:ipsum:dolor'
Entries in this list can be formatted either as a simple string, or as a key/value pair, with the key being the pillar location, and the value being the renderer to use for pillar decryption. If the former is used, the renderer specified by decrypt_pillar_default will be used.
decrypt_pillar_delimiter New in version 2017.7.0.
Default: :
The delimiter used to distinguish nested data structures in the decrypt_pillar option.
decrypt_pillar_delimiter: '|' decrypt_pillar: - 'foo|bar': gpg - 'lorem|ipsum|dolor'
decrypt_pillar_default New in version 2017.7.0.
Default: gpg
The default renderer used for decryption, if one is not specified for a given pillar key in decrypt_pillar.
decrypt_pillar_default: my_custom_renderer
decrypt_pillar_renderers New in version 2017.7.0.
Default: ['gpg']
List of renderers which are permitted to be used for pillar decryption.
decrypt_pillar_renderers: - gpg - my_custom_renderer
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.
pillar_opts: False
pillar_safe_render_error Default: True
The pillar_safe_render_error option prevents the master from passing pillar render errors to the minion. This is set on by default because the error could contain templating data which would give that minion information it shouldn't have, like a password! When set True the error message will only show:
Rendering SLS 'my.sls' failed. Please see master log for details.
pillar_safe_render_error: True
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/master/salt/pillar
By default, the ext_pillar interface is not configured to run.
ext_pillar: - hiera: /etc/hiera.yaml - cmd_yaml: cat /etc/salt/yaml - reclass: inventory_base_uri: /etc/reclass
There are additional details at salt-pillars
ext_pillar_first New in version 2015.5.0.
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.
ext_pillar_first: False
pillarenv_from_saltenv Default: False
When set to True, the pillarenv value will assume the value of the effective saltenv when running states. This essentially makes salt-run pillar.show_pillar saltenv=dev equivalent to salt-run pillar.show_pillar saltenv=dev pillarenv=dev. If pillarenv is set on the CLI, it will override this option.
pillarenv_from_saltenv: True
NOTE: For salt remote execution commands this option should be set in the Minion configuration instead.
pillar_raise_on_missing New in version 2015.5.0.
Set this option to True to force a KeyError to be raised whenever an attempt to retrieve a named value from pillar fails. When this option is set to False, the failed attempt returns an empty string.
Git External Pillar (git_pillar) Configuration Options git_pillar_provider New in version 2015.8.0.
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 New in version 2015.8.0.
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 New in version 2015.8.0.
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 New in version 2015.8.0.
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 its 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 New in version 2015.8.0.
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 New in version 2015.8.0.
Changed in version 2016.11.0.
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.
In the 2016.11.0 release, the default config value changed from False to True.
git_pillar_ssl_verify: True
git_pillar_global_lock New in version 2015.8.9.
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_pillar_includes New in version 2017.7.0.
Normally, when processing git_pillar remotes, if more than one repo under the same git section in the ext_pillar configuration refers to the same pillar environment, then each repo in a given environment will have access to the other repos' files to be referenced in their top files. However, it may be desirable to disable this behavior. If so, set this value to False.
For a more detailed examination of how includes work, see this explanation from the git_pillar documentation.
git_pillar_includes: False
git_pillar_update_interval New in version 3000.
This option defines the default update interval (in seconds) for git_pillar remotes. The update is handled within the global loop, hence git_pillar_update_interval should be a multiple of loop_interval.
git_pillar_update_interval: 120
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 New in version 2015.8.0.
Along with git_pillar_password, is used to authenticate to HTTPS remotes.
git_pillar_user: git
git_pillar_password New in version 2015.8.0.
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 New in version 2015.8.0.
git_pillar_insecure_auth: True
git_pillar_pubkey New in version 2015.8.0.
Along with git_pillar_privkey (and optionally git_pillar_passphrase), is used to authenticate to SSH remotes.
git_pillar_pubkey: /path/to/key.pub
git_pillar_privkey New in version 2015.8.0.
Along with git_pillar_pubkey (and optionally git_pillar_passphrase), is used to authenticate to SSH remotes.
git_pillar_privkey: /path/to/key
git_pillar_passphrase New in version 2015.8.0.
git_pillar_passphrase: mypassphrase
git_pillar_refspecs New in version 2017.7.0.
When fetching from remote repositories, by default Salt will fetch branches and tags. This parameter can be used to override the default and specify alternate refspecs to be fetched. This parameter works similarly to its GitFS counterpart, in that it can be configured both globally and for individual remotes.
git_pillar_refspecs: - '+refs/heads/*:refs/remotes/origin/*' - '+refs/tags/*:refs/tags/*' - '+refs/pull/*/head:refs/remotes/origin/pr/*' - '+refs/pull/*/merge:refs/remotes/origin/merge/*'
git_pillar_verify_config New in version 2017.7.0.
By default, as the master starts it performs some sanity checks on the configured git_pillar repositories. If any of these sanity checks fail (such as when an invalid configuration is used), the master daemon will abort.
git_pillar_verify_config: False
Pillar Merging Options pillar_source_merging_strategy New in version 2014.7.0.
Default: smart
The pillar_source_merging_strategy option allows you to configure merging strategy between different sources. It accepts 5 values:
• none:
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.
New in version 2016.3.4.
• recurse:
It will recursively merge 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:
foo: 42 bar: !aggregate { element1: True } baz: !aggregate quux
bar: !aggregate { element2: True } baz: !aggregate quux2
foo: 42 bar: element1: True element2: True baz: - quux - quux2
NOTE: This requires that the render pipeline defined in the renderer master configuration ends in yamlex.
• 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
• smart (default):
Guesses the best strategy based on the "renderer" setting.
NOTE: In order for yamlex based features such as !aggregate to work as expected across documents using the default smart merge strategy, the renderer config option must be set to jinja|yamlex or similar.
pillar_merge_lists New in version 2015.8.0.
Recursively merge lists by aggregating them instead of replacing them.
pillar_merge_lists: False
pillar_includes_override_sls New in version 2017.7.6,2018.3.1.
Prior to version 2017.7.3, keys from pillar includes would be merged on top of the pillar SLS. Since 2017.7.3, the includes are merged together and then the pillar SLS is merged on top of that.
Set this option to True to return to the old behavior.
pillar_includes_override_sls: True
Pillar Cache Options pillar_cache New in version 2015.8.8.
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: False
NOTE: Setting pillar_cache: True has no effect on targeting minions with pillar.
pillar_cache_ttl New in version 2015.8.8.
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 New in version 2015.8.8.
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
Master Reactor Settings reactor Default: []
Defines a salt reactor. See the Reactor documentation for more information.
reactor: - 'salt/minion/*/start': - salt://reactor/startup_tasks.sls
reactor_refresh_interval Default: 60
The TTL for the cache of the reactor configuration.
reactor_refresh_interval: 60
reactor_worker_threads Default: 10
The number of workers for the runner/wheel in the reactor.
reactor_worker_threads: 10
reactor_worker_hwm Default: 10000
The queue size for workers in the reactor.
reactor_worker_hwm: 10000
Salt-API Master Settings There are some settings for salt-api that can be configured on the Salt Master.
api_logfile Default: /var/log/salt/api
The logfile location for salt-api.
api_logfile: /var/log/salt/api
api_pidfile Default: /var/run/salt-api.pid
If this master will be running salt-api, specify the pidfile of the salt-api daemon.
api_pidfile: /var/run/salt-api.pid
rest_timeout Default: 300
Used by salt-api for the master requests timeout.
rest_timeout: 300
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
order_masters: False
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_master_port: 4506
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 New in version 2016.3.0.
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_failover: random
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.
syndic_wait: 5
syndic_forward_all_events New in version 2017.7.0.
Option on multi-syndic or single when connected to multiple masters to be able to send events to all connected masters.
syndic_forward_all_events: False
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:
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!
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
Master Logging Settings log_file Default: /var/log/salt/master
The master log can be sent to a regular file, local path name, or network location. See also log_file.
log_file: /var/log/salt/master
log_file: file:///dev/log
log_file: udp://loghost:10514
log_level Default: warning
The level of messages to send to the console. See also log_level.
log_level: warning
log_level_logfile Default: warning
The level of messages to send to the log file. See also log_level_logfile. When it is not set explicitly it will inherit the level set by log_level option.
log_level_logfile: warning
log_datefmt Default: %H:%M:%S
The date and time format used in console log messages. See also log_datefmt.
log_datefmt: '%H:%M:%S'
log_datefmt_logfile Default: %Y-%m-%d %H:%M:%S
The date and time format used in log file messages. See also log_datefmt_logfile.
log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'
log_fmt_console Default: [%(levelname)-8s] %(message)s
The format of the console logging messages. See also log_fmt_console.
NOTE: Log colors are enabled in log_fmt_console rather than the color config since the logging system is loaded before the master config.
Console log colors are specified by these additional formatters:
%(colorlevel)s %(colorname)s %(colorprocess)s %(colormsg)s
Since it is desirable to include the surrounding brackets, '[' and ']', in the coloring of the messages, these color formatters also include padding as well.  Color LogRecord attributes are only available for console logging.
log_fmt_console: '%(colorlevel)s %(colormsg)s' log_fmt_console: '[%(levelname)-8s] %(message)s'
log_fmt_logfile Default: %(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s
The format of the log file logging messages. See also log_fmt_logfile.
log_fmt_logfile: '%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s'
log_granular_levels Default: {}
This can be used to control logging levels more specifically. See also log_granular_levels.
log_rotate_max_bytes Default:  0
The maximum number of bytes a single log file may contain before it is rotated.  A value of 0 disables this feature. Currently only supported on Windows. On other platforms, use an external tool such as 'logrotate' to manage log files.  log_rotate_max_bytes
log_rotate_backup_count Default:  0
The number of backup files to keep when rotating log files. Only used if log_rotate_max_bytes is greater than 0. Currently only supported on Windows. On other platforms, use an external tool such as 'logrotate' to manage log files.  log_rotate_backup_count
Node Groups nodegroups 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 or bl*.domain.com' group2: 'G@os:Debian and foo.domain.com' group3: 'G@os:Debian and N@group1' group4: - 'G@foo:bar' - 'or' - 'G@foo:baz'
More information on using nodegroups can be found here.
Range Cluster Settings range_server Default: 'range:80'
The range server (and optional port) that serves your cluster information https://github.com/ytoolshed/range/wiki/%22yamlfile%22-module-file-spec
range_server: range:80
Include Configuration Configuration can be loaded from multiple files. The order in which this is done is:
1. The master config file itself
2. The files matching the glob in default_include
3. The files matching the glob in include (if defined)
Each successive step overrides any values defined in the previous steps. Therefore, any config options defined in one of the default_include files would override the same value in the master config file, and any options defined in include would override both.
default_include Default: master.d/*.conf
The master can include configuration from other files. Per default the master will automatically include all config files from master.d/*.conf where master.d is relative to the directory of the master configuration file.
NOTE: Salt creates files in the master.d directory for its own use. These files are prefixed with an underscore. A common example of this is the _schedule.conf file.
include Default: not defined
The master can include configuration from other files. To enable this, pass a list of paths to this option. The paths can be either relative or absolute; if relative, they are considered to be relative to the directory the main minion configuration file lives in. Paths can make use of shell-style globbing. If no files are matched by a path passed to this option then the master will log a warning message.
# Include files from a master.d directory in the same # directory as the master config file include: master.d/*
# Include a single extra file into the configuration include: /etc/roles/webserver
# Include several files and the master.d directory include: - extra_config - master.d/* - /etc/roles/webserver
Keepalive Settings tcp_keepalive Default: True
The tcp keepalive interval to set on TCP ports. This setting can be used to tune Salt connectivity issues in messy network environments with misbehaving firewalls.
tcp_keepalive: True
tcp_keepalive_cnt Default: -1
Sets the ZeroMQ TCP keepalive count. May be used to tune issues with minion disconnects.
tcp_keepalive_cnt: -1
tcp_keepalive_idle Default: 300
Sets ZeroMQ TCP keepalive idle. May be used to tune issues with minion disconnects.
tcp_keepalive_idle: 300
tcp_keepalive_intvl Default: -1
Sets ZeroMQ TCP keepalive interval. May be used to tune issues with minion disconnects.
tcp_keepalive_intvl': -1
Windows Software Repo Settings winrepo_provider New in version 2015.8.0.
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 generated by 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
winrepo_remotes_ng: - '<commit_id> https://github.com/saltstack/salt-winrepo-ng.git'
winrepo_branch New in version 2015.8.0.
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
winrepo_remotes: - https://mygitserver/winrepo1.git - https://mygitserver/winrepo2.git: - foo https://mygitserver/winrepo3.git
winrepo_ssl_verify New in version 2015.8.0.
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_ssl_verify: True
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 New in version 2015.8.0.
Along with winrepo_password, is used to authenticate to HTTPS remotes.
winrepo_user: git
winrepo_password New in version 2015.8.0.
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 New in version 2015.8.0.
winrepo_insecure_auth: True
winrepo_pubkey New in version 2015.8.0.
Along with winrepo_privkey (and optionally winrepo_passphrase), is used to authenticate to SSH remotes.
winrepo_pubkey: /path/to/key.pub
winrepo_privkey New in version 2015.8.0.
Along with winrepo_pubkey (and optionally winrepo_passphrase), is used to authenticate to SSH remotes.
winrepo_privkey: /path/to/key
winrepo_passphrase New in version 2015.8.0.
winrepo_passphrase: mypassphrase
winrepo_refspecs New in version 2017.7.0.
winrepo_refspecs: - '+refs/heads/*:refs/remotes/origin/*' - '+refs/tags/*:refs/tags/*' - '+refs/pull/*/head:refs/remotes/origin/pr/*' - '+refs/pull/*/merge:refs/remotes/origin/merge/*'
Configure Master on Windows The master on Windows requires no additional configuration. You can modify the master configuration by creating/editing the master config file located at c:\salt\conf\master. The same configuration options available on Linux are available in Windows, as long as they apply. For example, SSH options wouldn't apply in Windows. The main differences are the file paths. If you are familiar with common salt paths, the following table may be useful:
┌────────────┬───────┬───────────────┐ │linux Paths │       │ Windows Paths │ ├────────────┼───────┼───────────────┤ │/etc/salt   │ <---> │ c:\salt\conf  │ ├────────────┼───────┼───────────────┤ │/           │ <---> │ c:\salt       │ └────────────┴───────┴───────────────┘
So, for example, the master config file in Linux is /etc/salt/master. In Windows the master config file is c:\salt\conf\master. The Linux path /etc/salt becomes c:\salt\conf in Windows.
Common File Locations ┌────────────────────────────┬─────────────────────────────────┐ │Linux Paths                 │ Windows Paths                   │ ├────────────────────────────┼─────────────────────────────────┤ │conf_file: /etc/salt/master │ conf_file:                      │ │                            │ c:\salt\conf\master             │ ├────────────────────────────┼─────────────────────────────────┤ │log_file:                   │ log_file:                       │ │/var/log/salt/master        │ c:\salt\var\log\salt\master     │ ├────────────────────────────┼─────────────────────────────────┤ │pidfile:                    │ pidfile:                        │ │/var/run/salt-master.pid    │ c:\salt\var\run\salt-master.pid │ └────────────────────────────┴─────────────────────────────────┘
Common Directories ┌───────────────────────────────┬───────────────────────────────────────┐ │Linux Paths                    │ Windows Paths                         │ ├───────────────────────────────┼───────────────────────────────────────┤ │cachedir:                      │ cachedir:                             │ │/var/cache/salt/master         │ c:\salt\var\cache\salt\master         │ ├───────────────────────────────┼───────────────────────────────────────┤ │extension_modules:             │ c:\salt\var\cache\salt\master\extmods │ │/var/cache/salt/master/extmods │                                       │ ├───────────────────────────────┼───────────────────────────────────────┤ │pki_dir: /etc/salt/pki/master  │ pki_dir: c:\salt\conf\pki\master      │ ├───────────────────────────────┼───────────────────────────────────────┤ │root_dir: /                    │ root_dir: c:\salt                     │ ├───────────────────────────────┼───────────────────────────────────────┤ │sock_dir: /var/run/salt/master │ sock_dir: c:\salt\var\run\salt\master │ └───────────────────────────────┴───────────────────────────────────────┘
Roots file_roots
┌──────────────┬──────────────────────┐ │Linux Paths   │ Windows Paths        │ ├──────────────┼──────────────────────┤ │/srv/salt     │ c:\salt\srv\salt     │ ├──────────────┼──────────────────────┤ │/srv/spm/salt │ c:\salt\srv\spm\salt │ └──────────────┴──────────────────────┘
pillar_roots
┌────────────────┬────────────────────────┐ │Linux Paths     │ Windows Paths          │ ├────────────────┼────────────────────────┤ │/srv/pillar     │ c:\salt\srv\pillar     │ ├────────────────┼────────────────────────┤ │/srv/spm/pillar │ c:\salt\srv\spm\pillar │ └────────────────┴────────────────────────┘
Win Repo Settings ┌──────────────────────┬──────────────────────────────┐ │Linux Paths           │ Windows Paths                │ ├──────────────────────┼──────────────────────────────┤ │winrepo_dir:          │ winrepo_dir:                 │ │/srv/salt/win/repo    │ c:\salt\srv\salt\win\repo    │ ├──────────────────────┼──────────────────────────────┤ │winrepo_dir_ng:       │ winrepo_dir_ng:              │ │/srv/salt/win/repo-ng │ c:\salt\srv\salt\win\repo-ng │ └──────────────────────┴──────────────────────────────┘
Configuring the Salt Minion 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 minion configuration file
The Salt Minion configuration is very simple. Typically, the only value that needs to be set is the master value so the minion knows where to locate its master.
By default, the salt-minion configuration will be in /etc/salt/minion.  A notable exception is FreeBSD, where the configuration will be in /usr/local/etc/salt/minion.
Minion Primary Configuration master Default: salt
The hostname or IP address of the master. See ipv6 for IPv6 connections to the master.
Default: salt
master: salt
master:port Syntax New in version 2015.8.0.
The master config option can also be set to use the master's IP in conjunction with a port number by default.
master: localhost:1234
For IPv6 formatting with a port, remember to add brackets around the IP address before adding the port and enclose the line in single quotes to make it a string:
master: '[2001:db8:85a3:8d3:1319:8a2e:370:7348]:1234'
NOTE: If a port is specified in the master as well as master_port, the master_port setting will be overridden by the master configuration.
List of Masters Syntax The option can also be set to a list of masters, enabling multi-master mode.
master: - address1 - address2
Changed in version 2014.7.0: The master can be dynamically configured. The master value can be set to an module function which will be executed and will assume that the returning value is the ip or hostname of the desired master. If a function is being specified, then the master_type option must be set to func, to tell the minion that the value is a function to be run and not a fully-qualified domain name.
master: module.function master_type: func
In addition, instead of using multi-master mode, the minion can be configured to use the list of master addresses as a failover list, trying the first address, then the second, etc. until the minion successfully connects. To enable this behavior, set master_type to failover:
master: - address1 - address2 master_type: failover
By default output is colored. To disable colored output, set the color value to False.
ipv6 Default: None
Whether the master should be connected over IPv6. By default salt minion will try to automatically detect IPv6 connectivity to master.
master_uri_format New in version 2015.8.0.
Specify the format in which the master address will be evaluated. Valid options are default or ip_only. If ip_only is specified, then the master address will not be split into IP and PORT, so be sure that only an IP (or domain name) is set in the master configuration setting.
master_uri_format: ip_only
master_tops_first New in version 2018.3.0.
SLS targets defined using the Master Tops system are normally executed after any matches defined in the Top File. Set this option to True to have the minion execute the Master Tops states first.
master_tops_first: True
master_type New in version 2014.7.0.
Default: str
The type of the master variable. Can be str, failover, func or disable.
master_type: failover
If this option is set to failover, master must be a list of master addresses. The minion will then try each master in the order specified in the list until it successfully connects.  master_alive_interval must also be set, this determines how often the minion will verify the presence of the master.
master_type: func
If the master needs to be dynamically assigned by executing a function instead of reading in the static master value, set this to func. This can be used to manage the minion's master setting from an execution module. By simply changing the algorithm in the module to return a new master ip/fqdn, restart the minion and it will connect to the new master.
As of version 2016.11.0 this option can be set to disable and the minion will never attempt to talk to the master. This is useful for running a masterless minion daemon.
master_type: disable
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 minion event bus. The value is expressed in bytes.
enable_legacy_startup_events New in version 2019.2.0.
When a minion starts up it sends a notification on the event bus with a tag that looks like this: salt/minion/<minion_id>/start. For historical reasons the minion also sends a similar event with an event tag like this: minion_start. This duplication can cause a lot of clutter on the event bus when there are many minions. Set enable_legacy_startup_events: False in the minion config to ensure only the salt/minion/<minion_id>/start events are sent. Beginning with the 3001 Salt release this option will default to False.
enable_legacy_startup_events: True
master_failback New in version 2016.3.0.
If the minion is in multi-master mode and the :conf_minion`master_type` configuration option is set to failover, this setting can be set to True to force the minion to fail back to the first master in the list if the first master is back online.
master_failback: False
master_failback_interval New in version 2016.3.0.
If the minion is in multi-master mode, the :conf_minion`master_type` configuration is set to failover, and the master_failback option is enabled, the master failback interval can be set to ping the top master with this interval, in seconds.
master_failback_interval: 0
master_alive_interval Default: 0
Configures how often, in seconds, the minion will verify that the current master is alive and responding.  The minion will try to establish a connection to the next master in the list if it finds the existing one is dead.
master_alive_interval: 30
master_shuffle New in version 2014.7.0.
Deprecated since version 2019.2.0.
WARNING: This option has been deprecated in Salt 2019.2.0. Please use random_master instead.
master_shuffle: True
random_master New in version 2014.7.0.
Changed in version 2019.2.0: The master_failback option can be used in conjunction with random_master to force the minion to fail back to the first master in the list if the first master is back online. Note that master_type must be set to failover in order for the master_failback setting to work.
If master is a list of addresses, shuffle them before trying to connect to distribute the minions over all available masters. This uses Python's random.shuffle method.
If multiple masters are specified in the 'master' setting as a list, the default behavior is to always try to connect to them in the order they are listed. If random_master is set to True, the order will be randomized instead upon Minion startup. This can be helpful in distributing the load of many minions executing salt-call requests, for example, from a cron job. If only one master is listed, this setting is ignored and a warning is logged.
random_master: True