neulab/tldr huggingface dataset:
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.
con_cache: True
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.
presence_events: False
detect_remote_minions Default: False
When checking the minions connected to a master, also include the master's connections to minions on the port specfied in the setting remote_minions_port.  This is particularly useful when checking if the master is connected to any Heist-Salt minions. If this setting is set to True, the master will check all connections on port 22 by default unless a user also configures a different port with the setting remote_minions_port.
Changing this setting will check the remote minions the master is connected to when using presence events, the manage runner, and any other parts of the code that call the connected_ids method to check the status of connected minions.
detect_remote_minions: True
remote_minions_port Default: 22
The port to use when checking for remote minions when detect_remote_minions is set to True.
remote_minions_port: 2222
ping_on_rotate New in version 2014.7.0.
By default, the master AES key rotates every 24 hours. The next command following a key rotation will trigger a key refresh from the minion which may result in minions which do not respond to the first command after a key refresh.
To tell the master to ping all minions immediately after an AES key refresh, set ping_on_rotate to True. This should mitigate the issue where a minion does not appear to initially respond after a key is rotated.
Note that enabling this may cause high load on the master immediately after the key rotation event as minions reconnect. Consider this carefully if this salt master is managing a large number of minions.
If disabled, it is recommended to handle this event by listening for the aes_key_rotate event with the key tag and acting appropriately.
ping_on_rotate: False
transport Default: zeromq
Changes the underlying transport layer. ZeroMQ is the recommended transport while additional transport layers are under development. Supported values are zeromq and tcp (experimental). This setting has a significant impact on performance and should not be changed unless you know what you are doing!
transport: zeromq
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!  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_stats Default: False
Turning on the master stats enables runtime throughput and statistics events to be fired from the master event bus. These events will report on what functions have been run on the master and how long these runs have, on average, taken over a given period of time.
master_stats_event_iter Default: 60
The time in seconds to fire master_stats events. This will only fire in conjunction with receiving a request to the master, idle masters will not fire these events.
sock_pool_size Default: 1
To avoid blocking waiting while writing a data to a socket, we support socket pool for Salt applications. For example, a job with a large number of target host list can cause long period blocking waiting. The option is used by ZMQ and TCP transports, and the other transport methods don't need the socket pool by definition. Most of Salt tools, including CLI, are enough to use a single bucket of socket pool. On the other hands, it is highly recommended to set the size of socket pool larger than 1 for other Salt applications, especially Salt API, which must write data to socket concurrently.
sock_pool_size: 15
ipc_mode Default: ipc
The ipc strategy. (i.e., sockets versus tcp, etc.) Windows platforms lack POSIX IPC and must rely on TCP based inter-process communications. ipc_mode is set to tcp by default on Windows.
ipc_mode: ipc
tcp_master_pub_port Default: 4512
The TCP port on which events for the master should be published if ipc_mode is TCP.
tcp_master_pub_port: 4512
tcp_master_pull_port Default: 4513
The TCP port on which events for the master should be pulled if ipc_mode is TCP.
tcp_master_pull_port: 4513
tcp_master_publish_pull Default: 4514
The TCP port on which events for the master should be pulled fom and then republished onto the event bus on the master.
tcp_master_publish_pull: 4514
tcp_master_workers Default: 4515
The TCP port for mworkers to connect to on the master.
tcp_master_workers: 4515
auth_events New in version 2017.7.3.
Default: True
Determines whether the master will fire authentication events. Authentication events are fired when a minion performs an authentication check with the master.
auth_events: True
minion_data_cache_events New in version 2017.7.3.
Determines whether the master will fire minion data cache events.  Minion data cache events are fired when a minion requests a minion data cache refresh.
minion_data_cache_events: True
http_connect_timeout New in version 2019.2.0.
Default: 20
HTTP connection timeout in seconds.  Applied when fetching files using tornado back-end.  Should be greater than overall download time.
http_connect_timeout: 20
http_request_timeout New in version 2015.8.0.
Default: 3600
HTTP request timeout in seconds.  Applied when fetching files using tornado back-end.  Should be greater than overall download time.
http_request_timeout: 3600
use_yamlloader_old New in version 2019.2.1.
Use the pre-2019.2 YAML renderer.  Uses legacy YAML rendering to support some legacy inline data structures.  See the 2019.2.1 release notes for more details.
use_yamlloader_old: False
req_server_niceness New in version 3001.
Default: None
Process priority level of the ReqServer subprocess of the master. Supported on POSIX platforms only.
req_server_niceness: 9
pub_server_niceness New in version 3001.
Process priority level of the PubServer subprocess of the master. Supported on POSIX platforms only.
pub_server_niceness: 9
fileserver_update_niceness New in version 3001.
Process priority level of the FileServerUpdate subprocess of the master. Supported on POSIX platforms only.
fileserver_update_niceness: 9
maintenance_niceness New in version 3001.
Process priority level of the Maintenance subprocess of the master. Supported on POSIX platforms only.
maintenance_niceness: 9
mworker_niceness New in version 3001.
Process priority level of the MWorker subprocess of the master. Supported on POSIX platforms only.
mworker_niceness: 9
mworker_queue_niceness New in version 3001.
default: None
process priority level of the MWorkerQueue subprocess of the master. supported on POSIX platforms only.
mworker_queue_niceness: 9
event_return_niceness New in version 3001.
process priority level of the EventReturn subprocess of the master. supported on POSIX platforms only.
event_return_niceness: 9
event_publisher_niceness New in version 3001.
default: none
process priority level of the EventPublisher subprocess of the master. supported on POSIX platforms only.
event_publisher_niceness: 9
reactor_niceness New in version 3001.
process priority level of the Reactor subprocess of the master. supported on POSIX platforms only.
reactor_niceness: 9
Salt-SSH Configuration roster Default: flat
Define the default salt-ssh roster module to use
roster: cache
roster_defaults New in version 2017.7.0.
Default settings which will be inherited by all rosters.
roster_defaults: user: daniel sudo: True priv: /root/.ssh/id_rsa tty: True
roster_file Default: /etc/salt/roster
Pass in an alternative location for the salt-ssh flat roster file.
roster_file: /root/roster
rosters Default: None
Define locations for flat roster files so they can be chosen when using Salt API. An administrator can place roster files into these locations. Then, when calling Salt API, the roster_file parameter should contain a relative path to these locations. That is, roster_file=/foo/roster will be resolved as /etc/salt/roster.d/foo/roster etc. This feature prevents passing insecure custom rosters through the Salt API.
rosters: - /etc/salt/roster.d - /opt/salt/some/more/rosters
ssh_passwd Default: ''
The ssh password to log in with.
ssh_passwd: ''
ssh_priv_passwd Default: ''
Passphrase for ssh private key file.
ssh_priv_passwd: ''
ssh_port Default: 22
The target system's ssh port number.
ssh_port: 22
ssh_scan_ports Default: 22
Comma-separated list of ports to scan.
ssh_scan_ports: 22
ssh_scan_timeout Default: 0.01
Scanning socket timeout for salt-ssh.
ssh_scan_timeout: 0.01
ssh_sudo Default: False
Boolean to run command via sudo.
ssh_sudo: False
ssh_timeout Default: 60
Number of seconds to wait for a response when establishing an SSH connection.
ssh_timeout: 60
ssh_user Default: root
The user to log in as.
ssh_user: root
ssh_log_file New in version 2016.3.5.
Default: /var/log/salt/ssh
Specify the log file of the salt-ssh command.
ssh_log_file: /var/log/salt/ssh
ssh_minion_opts Default: None
Pass in minion option overrides that will be inserted into the SHIM for salt-ssh calls. The local minion config is not used for salt-ssh. Can be overridden on a per-minion basis in the roster (minion_opts)
ssh_minion_opts: gpg_keydir: /root/gpg
ssh_use_home_key Default: False
Set this to True to default to using ~/.ssh/id_rsa for salt-ssh authentication with minions
ssh_use_home_key: False
ssh_identities_only Default: False
Set this to True to default salt-ssh to run with -o IdentitiesOnly=yes. This option is intended for situations where the ssh-agent offers many different identities and allows ssh to ignore those identities and use the only one specified in options.
ssh_identities_only: False
ssh_list_nodegroups Default: {}
List-only nodegroups for salt-ssh. Each group must be formed as either a comma-separated list, or a YAML list. This option is useful to group minions into easy-to-target groups when using salt-ssh. These groups can then be targeted with the normal -N argument to salt-ssh.
ssh_list_nodegroups: groupA: minion1,minion2 groupB: minion1,minion3
Run the ssh_pre_flight script defined in the salt-ssh roster. By default the script will only run when the thin dir does not exist on the targeted minion. This will force the script to run and not check if the thin dir exists first.
thin_extra_mods Default: None
List of additional modules, needed to be included into the Salt Thin. Pass a list of importable Python modules that are typically located in the site-packages Python directory so they will be also always included into the Salt Thin, once generated.
min_extra_mods Default: None
Identical as thin_extra_mods, only applied to the Salt Minimal.
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.
open_mode: False
auto_accept Default: False
Enable auto_accept. This setting will automatically accept all incoming public keys from minions.
auto_accept: False
keysize Default: 2048
The size of key that should be generated when creating new keys.
keysize: 2048
autosign_timeout New in version 2014.7.0.
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.
Changed in version 2018.3.0: For security reasons the file must be readonly except for its owner.  If permissive_pki_access is True the owning group can also have write access, but if Salt is running as root it must be a member of that group.  A less strict requirement also existed in previous version.
autoreject_file New in version 2014.1.0.
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.
autosign_grains_dir New in version 2018.3.0.
If the autosign_grains_dir is specified, incoming keys from minions with grain values that match those defined in files in the autosign_grains_dir will be accepted automatically. Grain values that should be accepted automatically can be defined by creating a file named like the corresponding grain in the autosign_grains_dir and writing the values into that file, one value per line.  Lines starting with a # will be ignored.  Minion must be configured to send the corresponding grains on authentication.  This should still be considered a less than secure option, due to the fact that trust is based on just the requesting minion.
Please see the Autoaccept Minions from Grains documentation for more information.
autosign_grains_dir: /etc/salt/autosign_grains
permissive_pki_access Default: False
Enable permissive access to the salt keys. This allows you to run the master or minion as root, but have a non-root group be given access to your pki_dir. To make the access explicit, root must belong to the group you've given access to. This is potentially quite insecure. If an autosign_file is specified, enabling permissive_pki_access will allow group access to that specific file.
permissive_pki_access: False
publisher_acl Default: {}
Enable user accounts on the master to execute specific modules. These modules can be expressed as regular expressions.
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.
This is completely disabled by default.
publisher_acl_blacklist: users: - root - '^(?!sudo_).*$'   #  all non sudo users modules: - cmd.* - test.echo
sudo_acl Default: False
Enforce publisher_acl and publisher_acl_blacklist when users have sudo access to the salt command.
sudo_acl: False
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
token_expire: 43200
token_expire_user_override Default: False
Allow eauth users to specify the expiry time of the tokens they generate.
A boolean applies to all users or a dictionary of whitelisted eauth backends and usernames may be given:
token_expire_user_override: pam: - fred - tom ldap: - gary
keep_acl_in_token Default: False
Set to True to enable keeping the calculated user's auth list in the token file. This is disabled by default and the auth list is calculated or requested from the eauth driver each time.
keep_acl_in_token: False
eauth_acl_module Default: ''
Auth subsystem module to use to get authorized access list for a user. By default it's the same module used for external authentication.
eauth_acl_module: django
file_recv Default: False
Allow minions to push files to the master. This is disabled by default, for security purposes.
file_recv: False
file_recv_max_size New in version 2014.7.0.
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.
file_recv_max_size: 100
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_pubkey: True
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.
rotate_aes_key: True
publish_session Default: 86400
The number of seconds between AES key rotations on the master.
publish_session: Default: 86400
ssl New in version 2016.11.0.
TLS/SSL connection options. This could be set to a dictionary containing arguments corresponding to python ssl.wrap_socket method. For details see Tornado and Python documentation.
Note: to set enum arguments values like cert_reqs and ssl_version use constant names without ssl module prefix: CERT_REQUIRED or PROTOCOL_SSLv23.
ssl: keyfile: <path_to_keyfile> certfile: <path_to_certfile> ssl_version: PROTOCOL_TLSv1_2
preserve_minion_cache Default: False
By default, the master deletes its cache of minion data when the key for that minion is removed. To preserve the cache after key deletion, set preserve_minion_cache to True.
WARNING: This may have security implications if compromised minions auth with a previous deleted minion ID.
preserve_minion_cache: False
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.
allow_minion_key_revoke: False
optimization_order Default: [0, 1, 2]
In cases where Salt is distributed without .py files, this option determines the priority of optimization level(s) Salt's module loader should prefer.
NOTE: This option is only supported on Python 3.5+.
optimization_order: - 2 - 0 - 1
Master Large Scale Tuning Settings 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)
max_open_files: 100000
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.
worker_threads: 5
pub_hwm Default: 1000
The zeromq high water mark on the publisher interface.
pub_hwm: 1000
zmq_backlog Default: 1000
The listen queue size of the ZeroMQ backlog.
zmq_backlog: 1000
Master Module Management runner_dirs Default: []
Set additional directories to search for runner modules.
runner_dirs: - /var/lib/salt/runners
utils_dirs New in version 2018.3.0.
Set additional directories to search for util modules.
utils_dirs: - /var/lib/salt/utils
cython_enable Default: False
Set to true to enable Cython modules (.pyx files) to be compiled on the fly on the Salt master.
cython_enable: False
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. The value of "state_top" is also used for the pillar top file
state_top: top.sls
state_top_saltenv This option has no default value. Set it to an environment name to ensure that only the top file from that environment is considered during a highstate.
NOTE: Using this value does not change the merging strategy. For instance, if top_file_merging_strategy is set to merge, and state_top_saltenv is set to foo, then any sections for environments other than foo in the top file for the foo environment will be ignored. With state_top_saltenv set to base, all states from all environments in the base top file will be applied, while all other top files are ignored. The only way to set state_top_saltenv to something other than base and not have the other environments in the targeted top file ignored, would be to set top_file_merging_strategy to merge_all.
state_top_saltenv: dev
top_file_merging_strategy Changed in version 2016.11.0: A merge_all strategy has been added.
Default: merge
When no specific fileserver environment (a.k.a. saltenv) has been specified for a highstate, all environments' top files are inspected. This config option determines how the SLS targets in those top files are handled.
When set to merge, the base environment's top file is evaluated first, followed by the other environments' top files. The first target expression (e.g. '*') for a given environment is kept, and when the same target expression is used in a different top file evaluated later, it is ignored.  Because base is evaluated first, it is authoritative. For example, if there is a target for '*' for the foo environment in both the base and foo environment's top files, the one in the foo environment would be ignored. The environments will be evaluated in no specific order (aside from base coming first). For greater control over the order in which the environments are evaluated, use env_order. Note that, aside from the base environment's top file, any sections in top files that do not match that top file's environment will be ignored. So, for example, a section for the qa environment would be ignored if it appears in the dev environment's top file. To keep use cases like this from being ignored, use the merge_all strategy.
When set to same, then for each environment, only that environment's top file is processed, with the others being ignored. For example, only the dev environment's top file will be processed for the dev environment, and any SLS targets defined for dev in the base environment's (or any other environment's) top file will be ignored. If an environment does not have a top file, then the top file from the default_top config parameter will be used as a fallback.
When set to merge_all, then all states in all environments in all top files will be applied. The order in which individual SLS files will be executed will depend on the order in which the top files were evaluated, and the environments will be evaluated in no specific order. For greater control over the order in which the environments are evaluated, use env_order.
top_file_merging_strategy: same
env_order Default: []
When top_file_merging_strategy is set to merge, and no environment is specified for a highstate, this config option allows for the order in which top files are evaluated to be explicitly defined.
env_order: - base - dev - qa
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>
renderer Default: jinja|yaml
The renderer to use on the minions to render the state data.
renderer: jinja|json
userdata_template New in version 2016.11.4.
The renderer to use for templating userdata files in salt-cloud, if the userdata_template is not set in the cloud profile. If no value is set in the cloud profile or master config file, no templating will be performed.
userdata_template: jinja
jinja_env New in version 2018.3.0.
Default: {}
jinja_env overrides the default Jinja environment options for all templates except sls templates.  To set the options for sls templates use jinja_sls_env.
NOTE: The Jinja2 Environment documentation is the official source for the default values.  Not all the options listed in the jinja documentation can be overridden using jinja_env or jinja_sls_env.
The default options are:
jinja_env: block_start_string: '{%' block_end_string: '%}' variable_start_string: '{{' variable_end_string: '}}' comment_start_string: '{#' comment_end_string: '#}' line_statement_prefix: line_comment_prefix: trim_blocks: False lstrip_blocks: False newline_sequence: '\n' keep_trailing_newline: False
jinja_sls_env New in version 2018.3.0.
jinja_sls_env sets the Jinja environment options for sls templates.  The defaults and accepted options are exactly the same as they are for jinja_env.
jinja_sls_env: block_start_string: '{%' block_end_string: '%}' variable_start_string: '{{' variable_end_string: '}}' comment_start_string: '{#' comment_end_string: '#}' line_statement_prefix: line_comment_prefix: trim_blocks: False lstrip_blocks: False newline_sequence: '\n' keep_trailing_newline: False
Example using line statements and line comments to increase ease of use:
If your configuration options are
jinja_sls_env: line_statement_prefix: '%' line_comment_prefix: '##'
With these options jinja will interpret anything after a % at the start of a line (ignoreing whitespace) as a jinja statement and will interpret anything after a ## as a comment.
This allows the following more convenient syntax to be used:
## (this comment will not stay once rendered) # (this comment remains in the rendered template) ## ensure all the formula services are running % for service in formula_services: enable_service_{{ service }}: service.running: name: {{ service }} % endfor
The following less convenient but equivalent syntax would have to be used if you had not set the line_statement and line_comment options:
{# (this comment will not stay once rendered) #} # (this comment remains in the rendered template) {# ensure all the formula services are running #} {% for service in formula_services %} enable_service_{{ service }}: service.running: name: {{ service }} {% endfor %}
jinja_trim_blocks Deprecated since version 2018.3.0: Replaced by jinja_env and jinja_sls_env
New in version 2014.1.0.
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_trim_blocks: False
jinja_lstrip_blocks Deprecated since version 2018.3.0: Replaced by jinja_env and jinja_sls_env
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.
failhard: False
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_verbose: False
state_output Default: full
The state_output setting controls which results will be output full multi line:
• full, terse - each state will be full/terse
• mixed - only states with errors will be full
• changes - states with changes and errors will be full
full_id, mixed_id, changes_id and terse_id are also allowed; when set, the state ID will be used as name in the output.
state_output: full
state_output_diff Default: False
The state_output_diff setting changes whether or not the output from successful states is returned. Useful when even the terse output of these states is cluttering the logs. Set it to True to ignore them.
state_output_diff: False
state_output_profile Default: True
The state_output_profile setting changes whether profile information will be shown for each state run.
state_output_profile: True
state_aggregate Default: False
Automatically aggregate all states that have support for mod_aggregate by setting to True.
state_aggregate: True
Or pass a list of state module names to automatically aggregate just those types.
state_aggregate: - pkg
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>.
state_events: True
yaml_utf8 Default: False
Enable extra routines for YAML renderer used states containing UTF characters.
yaml_utf8: False
runner_returns Default: False
If set to True, runner jobs will be saved to job cache (defined by master_job_cache).
runner_returns: True
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.
fileserver_backend: - roots - gitfs
NOTE: For masterless Salt, this parameter must be specified in the minion config file.
fileserver_followsymlinks New in version 2014.1.0.
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 New in version 2014.1.0.
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 New in version 2014.1.0.
Deprecated since version 2018.3.4: This option is now ignored. Firstly, it only traversed file_roots, which means it did not work for the other fileserver backends. Secondly, since this option was added we have added caching to the code that traverses the file_roots (and gitfs, etc.), which greatly reduces the amount of traversal that is done.
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
fileserver_list_cache_time New in version 2014.1.0.
Changed in version 2016.11.0: The default was changed from 30 seconds to 20.
Salt caches the list of files/symlinks/directories for each fileserver backend and environment as they are requested, to guard against a performance bottleneck at scale when many minions all ask the fileserver which files are available simultaneously. This configuration parameter allows for the max age of that cache to be altered.
Set this value to 0 to disable use of this cache altogether, but keep in mind that this may increase the CPU load on the master when running a highstate on a large number of minions.
NOTE: Rather than altering this configuration parameter, it may be advisable to use the fileserver.clear_file_list_cache runner to clear these caches.
fileserver_list_cache_time: 5
fileserver_verify_config New in version 2017.7.0.
By default, as the master starts it performs some sanity checks on the configured fileserver backends. If any of these sanity checks fail (such as when an invalid configuration is used), the master daemon will abort.
To skip these sanity checks, set this option to False.
fileserver_verify_config: False
hash_type Default: sha256
The hash_type is the hash to use when discovering the hash of a file on the master server. The default is sha256, but md5, sha1, sha224, sha384, and sha512 are also supported.
hash_type: sha256
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.
master_roots Default: ''
A master-only copy of the file_roots dictionary, used by the state compiler.
master_roots: base: - /srv/salt-master
roots: Master's Local File Server file_roots Default:
base: - /srv/salt
Salt runs a lightweight file server written in ZeroMQ to deliver files to minions. This file server is built into the master daemon and does not require a dedicated port.
The file server works on environments passed to the master. Each environment can have multiple root directories. The subdirectories in the multiple file roots cannot match, otherwise the downloaded files will not be able to be reliably ensured. A base environment is required to house the top file.
As of 2018.3.5 and 2019.2.1, it is possible to have __env__ as a catch-all environment.
file_roots: base: - /srv/salt dev: - /srv/salt/dev/services - /srv/salt/dev/states prod: - /srv/salt/prod/services - /srv/salt/prod/states __env__: - /srv/salt/default
roots_update_interval New in version 2018.3.0.
Default: 60
This option defines the update interval (in seconds) for file_roots.
NOTE: Since file_roots consists of files local to the minion, the update process for this fileserver backend just reaps the cache for this backend.
roots_update_interval: 120
gitfs: 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 New in version 2014.7.0.
Optional parameter used to specify the provider to be used for gitfs. More information can be found in the GitFS Walkthrough.
Must be either pygit2 or gitpython. 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_provider: gitpython
gitfs_ssl_verify Default: True
Specifies whether or not to ignore SSL certificate errors when fetching from the repositories configured in gitfs_remotes. 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_ssl_verify: False
NOTE: pygit2 only supports disabling SSL verification in versions 0.23.2 and newer.
Changed in version 2015.8.0: This option can now be configured on individual repositories as well. See here for more info.
Changed in version 2016.11.0: The default config value changed from False to True.
gitfs_mountpoint New in version 2014.7.0.
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 for an individual repository, 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: This option can now be configured on individual repositories as well. See here for more info.
gitfs_base Default: master
Defines which branch/tag should be used as the base environment.
gitfs_base: salt
gitfs_saltenv New in version 2016.11.0.
Global settings for per-saltenv configuration parameters. Though per-saltenv configuration parameters are typically one-off changes specific to a single gitfs remote, and thus more often configured on a per-remote basis, this parameter can be used to specify per-saltenv changes which should apply to all remotes. For example, the below configuration will map the develop branch to the dev saltenv for all gitfs remotes.
gitfs_saltenv: - dev: - ref: develop
gitfs_disable_saltenv_mapping New in version 2018.3.0.
When set to True, all saltenv mapping logic is disregarded (aside from which branch/tag is mapped to the base saltenv). To use any other environments, they must then be defined using per-saltenv configuration parameters.
gitfs_disable_saltenv_mapping: True
NOTE: This is is a global configuration option, see here for examples of configuring it for individual repositories.
gitfs_ref_types New in version 2018.3.0.
Default: ['branch', 'tag', 'sha']
This option defines what types of refs are mapped to fileserver environments (i.e. saltenvs). It also sets the order of preference when there are ambiguously-named refs (i.e. when a branch and tag both have the same name).  The below example disables mapping of both tags and SHAs, so that only branches are mapped as saltenvs:
gitfs_ref_types: - branch
NOTE: sha is special in that it will not show up when listing saltenvs (e.g. with the fileserver.envs runner), but works within states and with cp.cache_file to retrieve a file from a specific git SHA.
gitfs_saltenv_whitelist New in version 2014.7.0.
Changed in version 2018.3.0: Renamed from gitfs_env_whitelist to gitfs_saltenv_whitelist
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_saltenv_whitelist: - base - v1.* - 'mybranch\d+'
gitfs_saltenv_blacklist New in version 2014.7.0.
Changed in version 2018.3.0: Renamed from gitfs_env_blacklist to gitfs_saltenv_blacklist
gitfs_saltenv_blacklist: - base - v1.* - 'mybranch\d+'
gitfs_global_lock New in version 2015.8.9.
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_update_interval New in version 2018.3.0.
This option defines the default update interval (in seconds) for gitfs remotes.  The update interval can also be set for a single repository via a per-remote config option
gitfs_update_interval: 120
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 New in version 2014.7.0.
Along with gitfs_password, is used to authenticate to HTTPS remotes.
gitfs_user: git
gitfs_password New in version 2014.7.0.
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 New in version 2014.7.0.
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_pubkey New in version 2014.7.0.
Along with gitfs_privkey (and optionally gitfs_passphrase), is used to authenticate to SSH remotes.  Required for SSH remotes.
gitfs_pubkey: /path/to/key.pub
gitfs_privkey New in version 2014.7.0.
Along with gitfs_pubkey (and optionally gitfs_passphrase), is used to authenticate to SSH remotes.  Required for SSH remotes.
gitfs_privkey: /path/to/key
gitfs_passphrase New in version 2014.7.0.
This parameter is optional, required only when the SSH key being used to authenticate is protected by a passphrase.
gitfs_passphrase: mypassphrase
gitfs_refspecs New in version 2017.7.0.
Default: ['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']
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. More information on how this feature works can be found in the GitFS Walkthrough.
gitfs_refspecs: - '+refs/heads/*:refs/remotes/origin/*' - '+refs/tags/*:refs/tags/*' - '+refs/pull/*/head:refs/remotes/origin/pr/*' - '+refs/pull/*/merge:refs/remotes/origin/merge/*'
hgfs: Mercurial Remote File Server Backend hgfs_remotes New in version 0.17.0.
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 New in version 0.17.0.
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 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 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 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 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 New in version 2014.1.0.
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_base: salt
hgfs_saltenv_whitelist New in version 2014.7.0.
Changed in version 2018.3.0: Renamed from hgfs_env_whitelist to hgfs_saltenv_whitelist
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_saltenv_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_saltenv_whitelist: - base - v1.* - 'mybranch\d+'
hgfs_saltenv_blacklist New in version 2014.7.0.
Changed in version 2018.3.0: Renamed from hgfs_env_blacklist to hgfs_saltenv_blacklist
If used, branches/bookmarks/tags which match one of the specified expressions will not be exposed as fileserver environments.