neulab/tldr huggingface dataset:
NOTE: When the failover, master_failback, and random_master options are used together, only the "secondary masters" will be shuffled. The first master in the list is ignored in the random.shuffle call. See master_failback for more information.
retry_dns Default: 30
Set the number of seconds to wait before attempting to resolve the master hostname if name resolution fails. Defaults to 30 seconds.  Set to zero if the minion should shutdown and not retry.
retry_dns: 30
retry_dns_count New in version 2018.3.4.
Set the number of attempts to perform when resolving the master hostname if name resolution fails.  By default the minion will retry indefinitely.
retry_dns_count: 3
master_port Default: 4506
The port of the master ret server, this needs to coincide with the ret_port option on the Salt master.
master_port: 4506
The port of the master publish server, this needs to coincide with the publish_port option on the Salt master.
source_interface_name New in version 2018.3.0.
The name of the interface to use when establishing the connection to the Master.
NOTE: If multiple IP addresses are configured on the named interface, the first one will be selected. In that case, for a better selection, consider using the source_address option.
NOTE: To use an IPv6 address from the named interface, make sure the option ipv6 is enabled, i.e., ipv6: true.
NOTE: If the interface is down, it will avoid using it, and the Minion will bind to 0.0.0.0 (all interfaces).
WARNING: This option requires modern version of the underlying libraries used by the selected transport:
• zeromq requires pyzmq >= 16.0.1 and libzmq >= 4.1.6
• tcp requires tornado >= 4.5
Configuration example:
source_interface_name: bond0.1234
source_address New in version 2018.3.0.
The source IP address or the domain name to be used when connecting the Minion to the Master.  See ipv6 for IPv6 connections to the Master.
source_address: if-bond0-1234.sjc.us-west.internal
source_ret_port New in version 2018.3.0.
The source port to be used when connecting the Minion to the Master ret server.
source_ret_port: 49017
source_publish_port New in version 2018.3.0.
The source port to be used when connecting the Minion to the Master publish server.
source_publish_port: 49018
sudo_user Default: ''
The user to run salt remote execution commands as via sudo. If this option is enabled then sudo will be used to change the active user executing the remote command. If enabled the user will need to be allowed access via the sudoers file for the user that the salt minion is configured to run as. The most common option would be to use the root user. If this option is set the user option should also be set to a non-root user. If migrating from a root minion to a non root minion the minion cache should be cleared and the minion pki directory will need to be changed to the ownership of the new user.
sudo_user: root
pidfile Default: /var/run/salt-minion.pid
The location of the daemon's process ID file
pidfile: /var/run/salt-minion.pid
This directory is prepended to the following options: pki_dir, cachedir, log_file, sock_dir, and pidfile.
conf_file Default: /etc/salt/minion
The path to the minion's configuration file.
conf_file: /etc/salt/minion
pki_dir Default: /etc/salt/pki/minion
The directory used to store the minion's public and private keys.
pki_dir: /etc/salt/pki/minion
id Default: the system's hostname
SEE ALSO: Salt Walkthrough
The Setting up a Salt Minion section contains detailed information on how the hostname is determined.
Explicitly declare the id for this minion to use. Since Salt uses detached ids it is possible to run multiple minions on the same machine but with different ids.
id: foo.bar.com
minion_id_caching New in version 0.17.2.
Caches the minion id to a file when the minion's id is not statically defined in the minion config. This setting prevents potential problems when automatic minion id resolution changes, which can cause the minion to lose connection with the master. To turn off minion id caching, set this config to False.
For more information, please see Issue #7558 and Pull Request #8488.
minion_id_caching: True
append_domain Default: None
Append a domain to a hostname in the event that it does not exist. This is useful for systems where socket.getfqdn() does not actually result in a FQDN (for instance, Solaris).
append_domain: foo.org
minion_id_remove_domain New in version 3000.
Remove a domain when the minion id is generated as a fully qualified domain name (either by the user provided id_function, or by Salt). This is useful when the minions shall be named like hostnames. Can be a single domain (to prevent name clashes), or True, to remove all domains.
• minion_id_remove_domain = foo.org - FQDN = king_bob.foo.org --> minion_id = king_bob - FQDN = king_bob.bar.org --> minion_id = king_bob.bar.org
• minion_id_remove_domain = True - FQDN = king_bob.foo.org --> minion_id = king_bob - FQDN = king_bob.bar.org --> minion_id = king_bob
For more information, please see issue #49212 and  PR #49378.
minion_id_remove_domain: foo.org
minion_id_lowercase Default: False
Convert minion id to lowercase when it is being generated. Helpful when some hosts get the minion id in uppercase. Cached ids will remain the same and not converted.
minion_id_lowercase: True
cachedir Default: /var/cache/salt/minion
The location for minion cache data.
cachedir: /var/cache/salt/minion
append_minionid_config_dirs Default: [] (the empty list) for regular minions, ['cachedir'] for proxy minions.
Append minion_id to these configuration directories.  Helps with multiple proxies and minions running on the same machine. Allowed elements in the list: pki_dir, cachedir, extension_modules.  Normally not needed unless running several proxies and/or minions on the same machine.
append_minionid_config_dirs: - pki_dir - cachedir
NOTE: When set to True the verify_env option requires WRITE access to the configuration directory (/etc/salt/). In certain situations such as mounting /etc/salt/ as read-only for templating this will create a stack trace when state.apply is called.
cache_jobs Default: False
The minion can locally cache the return data from jobs sent to it, this can be a good way to keep track of the minion side of the jobs the minion has executed. By default this feature is disabled, to enable set cache_jobs to True.
cache_jobs: False
grains Default: (empty)
SEE ALSO: static-custom-grains
Statically assigns grains to the minion.
grains: roles: - webserver - memcache deployment: datacenter4 cabinet: 13 cab_u: 14-15
grains_blacklist Default: []
Each grains key will be compared against each of the expressions in this list.  Any keys which match will be filtered from the grains. Exact matches, glob matches, and regular expressions are supported.
NOTE: Some states and execution modules depend on grains. Filtering may cause them to be unavailable or run unreliably.
New in version 3000.
grains_blacklist: - cpu_flags - zmq* - ipv[46]
grains_cache Default: False
The minion can locally cache grain data instead of refreshing the data each time the grain is referenced. By default this feature is disabled, to enable set grains_cache to True.
grains_cache: False
grains_cache_expiration Default: 300
Grains cache expiration, in seconds. If the cache file is older than this number of seconds then the grains cache will be dumped and fully re-populated with fresh data. Defaults to 5 minutes. Will have no effect if grains_cache is not enabled.
grains_cache_expiration: 300
grains_deep_merge New in version 2016.3.0.
The grains can be merged, instead of overridden, using this option.  This allows custom grains to defined different subvalues of a dictionary grain. By default this feature is disabled, to enable set grains_deep_merge to True.
grains_deep_merge: False
For example, with these custom grains functions:
def custom1_k1(): return {"custom1": {"k1": "v1"}}
def custom1_k2(): return {"custom1": {"k2": "v2"}}
Without grains_deep_merge, the result would be:
custom1: k1: v1
With grains_deep_merge, the result will be:
custom1: k1: v1 k2: v2
grains_refresh_every Default: 0
The grains_refresh_every setting allows for a minion to periodically check its grains to see if they have changed and, if so, to inform the master of the new grains. This operation is moderately expensive, therefore care should be taken not to set this value too low.
Note: This value is expressed in minutes.
A value of 10 minutes is a reasonable default.
grains_refresh_every: 0
metadata_server_grains New in version 2017.7.0.
Set this option to enable gathering of cloud metadata from http://169.254.169.254/latest for use in grains (see here for more information).
metadata_server_grains: True
fibre_channel_grains Default: False
The fibre_channel_grains setting will enable the fc_wwn grain for Fibre Channel WWN's on the minion. Since this grain is expensive, it is disabled by default.
fibre_channel_grains: True
iscsi_grains Default: False
The iscsi_grains setting will enable the iscsi_iqn grain on the minion. Since this grain is expensive, it is disabled by default.
iscsi_grains: True
nvme_grains Default: False
The nvme_grains setting will enable the nvme_nqn grain on the minion. Since this grain is expensive, it is disabled by default.
nvme_grains: True
mine_enabled New in version 2015.8.10.
Determines whether or not the salt minion should run scheduled mine updates.  If this is set to False then the mine update function will not get added to the scheduler for the minion.
mine_enabled: True
mine_return_job New in version 2015.8.10.
Determines whether or not scheduled mine updates should be accompanied by a job return for the job cache.
mine_return_job: False
mine_functions Default: Empty
Designate which functions should be executed at mine_interval intervals on each minion.  See this documentation on the Salt Mine for more information.  Note these can be defined in the pillar for a minion as well. example minion configuration file
mine_functions: test.ping: [] network.ip_addrs: interface: eth0 cidr: '10.0.0.0/8'
mine_interval Default: 60
The number of minutes between mine updates.
mine_interval: 60
sock_dir Default: /var/run/salt/minion
The directory where Unix sockets will be kept.
sock_dir: /var/run/salt/minion
enable_fqdns_grains Default: True
In order to calculate the fqdns grain, all the IP addresses from the minion are processed with underlying calls to socket.gethostbyaddr which can take 5 seconds to be released (after reaching socket.timeout) when there is no fqdn for that IP.  These calls to socket.gethostbyaddr are processed asynchronously, however, it still adds 5 seconds every time grains are generated if an IP does not resolve. In Windows grains are regenerated each time a new process is spawned. Therefore, the default for Windows is False. In many cases this value does not make sense to include for proxy minions as it will be FQDN for the host running the proxy minion process, so the default for proxy minions is False`. All other OSes default to True. This options was added here.
enable_fqdns_grains: False
enable_gpu_grains Default: True
Enable GPU hardware data for your master. Be aware that the minion can take a while to start up when lspci and/or dmidecode is used to populate the grains for the minion, so this can be set to False if you do not need these grains.
enable_gpu_grains: False
backup_mode Default: ''
Make backups of files replaced by file.managed and file.recurse state modules under cachedir in file_backup subdirectory preserving original paths.  Refer to File State Backups documentation for more details.
backup_mode: minion
acceptance_wait_time Default: 10
The number of seconds to wait until attempting to re-authenticate with the master.
acceptance_wait_time: 10
acceptance_wait_time_max Default: 0
The maximum number of seconds to wait until attempting to re-authenticate with the master. If set, the wait will increase by acceptance_wait_time seconds each iteration.
acceptance_wait_time_max: 0
rejected_retry Default: False
If the master rejects the minion's public key, retry instead of exiting. Rejected keys will be handled the same as waiting on acceptance.
rejected_retry: False
random_reauth_delay Default: 10
When the master key changes, the minion will try to re-auth itself to receive the new master key. In larger environments this can cause a syn-flood on the master because all minions try to re-auth immediately. To prevent this and have a minion wait for a random amount of time, use this optional parameter. The wait-time will be a random number of seconds between 0 and the defined value.
random_reauth_delay: 60
master_tries New in version 2016.3.0.
Default: 1
The number of attempts to connect to a master before giving up. Set this to -1 for unlimited attempts. This allows for a master to have downtime and the minion to reconnect to it later when it comes back up. In 'failover' mode, which is set in the master_type configuration, this value is the number of attempts for each set of masters. In this mode, it will cycle through the list of masters for each attempt.
master_tries is different than auth_tries because auth_tries attempts to retry auth attempts with a single master. auth_tries is under the assumption that you can connect to the master but not gain authorization from it.  master_tries will still cycle through all of the masters in a given try, so it is appropriate if you expect occasional downtime from the master(s).
master_tries: 1
auth_tries New in version 2014.7.0.
Default: 7
The number of attempts to authenticate to a master before giving up. Or, more technically, the number of consecutive SaltReqTimeoutErrors that are acceptable when trying to authenticate to the master.
auth_tries: 7
auth_timeout New in version 2014.7.0.
When waiting for a master to accept the minion's public key, salt will continuously attempt to reconnect until successful. This is the timeout value, in seconds, for each individual attempt. After this timeout expires, the minion will wait for acceptance_wait_time seconds before trying again.  Unless your master is under unusually heavy load, this should be left at the default.
NOTE: For high latency networks try increasing this value
auth_timeout: 5
auth_safemode New in version 2014.7.0.
If authentication fails due to SaltReqTimeoutError during a ping_interval, this setting, when set to True, will cause a sub-minion process to restart.
auth_safemode: False
ping_interval Default: 0
Instructs the minion to ping its master(s) every n number of minutes. Used primarily as a mitigation technique against minion disconnects.
ping_interval: 0
random_startup_delay Default: 0
The maximum bound for an interval in which a minion will randomly sleep upon starting up prior to attempting to connect to a master. This can be used to splay connection attempts for cases where many minions starting up at once may place undue load on a master.
For example, setting this to 5 will tell a minion to sleep for a value between 0 and 5 seconds.
random_startup_delay: 5
recon_default Default: 1000
The interval in milliseconds that the socket should wait before trying to reconnect to the master (1000ms = 1 second).
recon_default: 1000
recon_max Default: 10000
The maximum time a socket should wait. Each interval the time to wait is calculated by doubling the previous time. If recon_max is reached, it starts again at the recon_default.
Short example:
• reconnect 1: the socket will wait 'recon_default' milliseconds
• reconnect 2: 'recon_default' * 2
• reconnect 3: ('recon_default' * 2) * 2
• reconnect 4: value from previous interval * 2
• reconnect 5: value from previous interval * 2
• reconnect x: if value >= recon_max, it starts again with recon_default
recon_max: 10000
recon_randomize Default: True
Generate a random wait time on minion start. The wait time will be a random value between recon_default and recon_default + recon_max. Having all minions reconnect with the same recon_default and recon_max value kind of defeats the purpose of being able to change these settings. If all minions have the same values and the setup is quite large (several thousand minions), they will still flood the master. The desired behavior is to have time-frame within all minions try to reconnect.
recon_randomize: True
loop_interval Default: 1
The loop_interval sets how long in seconds the minion will wait between evaluating the scheduler and running cleanup tasks. This defaults to 1 second on the minion scheduler.
loop_interval: 1
pub_ret Default: True
Some installations choose to start all job returns in a cache or a returner and forgo sending the results back to a master. In this workflow, jobs are most often executed with --async from the Salt CLI and then results are evaluated by examining job caches on the minions or any configured returners.  WARNING: Setting this to False will disable returns back to the master.
pub_ret: True
return_retry_timer Default: 5
The default timeout for a minion return attempt.
return_retry_timer: 5
return_retry_timer_max Default: 10
The maximum timeout for a minion return attempt. If non-zero the minion return retry timeout will be a random int between return_retry_timer and return_retry_timer_max
return_retry_timer_max: 10
return_retry_tries Default: 3
The maximum number of retries for a minion return attempt.
return_retry_tries: 3
cache_sreqs Default: True
The connection to the master ret_port is kept open. When set to False, the minion creates a new connection for every return to the master.
cache_sreqs: True
Windows platforms lack POSIX IPC and must rely on slower TCP based inter- process communications. ipc_mode is set to tcp on such systems.
tcp_pub_port Default: 4510
Publish port used when ipc_mode is set to tcp.
tcp_pub_port: 4510
tcp_pull_port Default: 4511
Pull port used when ipc_mode is set to tcp.
tcp_pull_port: 4511
syndic_finger Default: ''
The key fingerprint of the higher-level master for the syndic to verify it is talking to the intended master.
syndic_finger: 'ab:30:65:2a:d6:9e:20:4f:d8:b2:f3:a7:d4:65:50:10'
proxy_host Default: ''
The hostname used for HTTP proxy access.
proxy_host: proxy.my-domain
proxy_port Default: 0
The port number used for HTTP proxy access.
proxy_port: 31337
proxy_username Default: ''
The username used for HTTP proxy access.
proxy_username: charon
proxy_password Default: ''
The password used for HTTP proxy access.
proxy_password: obolus
no_proxy New in version 2019.2.0.
List of hosts to bypass HTTP proxy
NOTE: This key does nothing unless proxy_host etc is configured, it does not support any kind of wildcards.
no_proxy: [ '127.0.0.1', 'foo.tld' ]
Docker Configuration docker.update_mine New in version 2017.7.8,2018.3.3.
Changed in version 2019.2.0: The default value is now False
If enabled, when containers are added, removed, stopped, started, etc., the mine will be updated with the results of docker.ps verbose=True all=True host=True. This mine data is used by mine.get_docker. Set this option to False to keep Salt from updating the mine with this information.
NOTE: This option can also be set in Grains or Pillar data, with Grains overriding Pillar and the minion config file overriding Grains.
NOTE: Disabling this will of course keep mine.get_docker from returning any information for a given minion.
docker.update_mine: False
docker.compare_container_networks New in version 2018.3.0.
Default: {'static': ['Aliases', 'Links', 'IPAMConfig'], 'automatic': ['IPAddress', 'Gateway', 'GlobalIPv6Address', 'IPv6Gateway']}
Specifies which keys are examined by docker.compare_container_networks.
NOTE: This should not need to be modified unless new features added to Docker result in new keys added to the network configuration which must be compared to determine if two containers have different network configs.  This config option exists solely as a way to allow users to continue using Salt to manage their containers after an API change, without waiting for a new Salt release to catch up to the changes in the Docker API.
docker.compare_container_networks: static: - Aliases - Links - IPAMConfig automatic: - IPAddress - Gateway - GlobalIPv6Address - IPv6Gateway
Minion Execution Module Management disable_modules Default: [] (all execution modules are enabled by default)
The event may occur in which the administrator desires that a minion should not be able to execute a certain module.
However, the sys module is built into the minion and cannot be disabled.
This setting can also tune the minion. Because all modules are loaded into system memory, disabling modules will lower the minion's memory footprint.
Modules should be specified according to their file name on the system and not by their virtual name. For example, to disable cmd, use the string cmdmod which corresponds to salt.modules.cmdmod.
disable_modules: - test - solr
disable_returners Default: [] (all returners are enabled by default)
If certain returners should be disabled, this is the place
disable_returners: - mongo_return
whitelist_modules Default: [] (Module whitelisting is disabled.  Adding anything to the config option will cause only the listed modules to be enabled.  Modules not in the list will not be loaded.)
This option is the reverse of disable_modules. If enabled, only execution modules in this list will be loaded and executed on the minion.
Note that this is a very large hammer and it can be quite difficult to keep the minion working the way you think it should since Salt uses many modules internally itself.  At a bare minimum you need the following enabled or else the minion won't start.
whitelist_modules: - cmdmod - test - config
A list of extra directories to search for Salt modules
module_dirs: - /var/lib/salt/modules
returner_dirs Default: []
A list of extra directories to search for Salt returners
returner_dirs: - /var/lib/salt/returners
states_dirs Default: []
A list of extra directories to search for Salt states
states_dirs: - /var/lib/salt/states
grains_dirs Default: []
A list of extra directories to search for Salt grains
grains_dirs: - /var/lib/salt/grains
render_dirs Default: []
A list of extra directories to search for Salt renderers
render_dirs: - /var/lib/salt/renderers
utils_dirs Default: []
A list of extra directories to search for Salt utilities
Set this value to true to enable auto-loading and compiling of .pyx modules, This setting requires that gcc and cython are installed on the minion.
enable_zip_modules New in version 2015.8.0.
Set this value to true to enable loading of zip archives as extension modules.  This allows for packing module code with specific dependencies to avoid conflicts and/or having to install specific modules' dependencies in system libraries.
enable_zip_modules: False
providers Default: (empty)
A module provider can be statically overwritten or extended for the minion via the providers option. This can be done on an individual basis in an SLS file, or globally here in the minion config, like below.
providers: service: systemd
modules_max_memory Default: -1
Specify a max size (in bytes) for modules on import. This feature is currently only supported on *NIX operating systems and requires psutil.
modules_max_memory: -1
By using this dictionary, the modules that are synced to the minion's extmod cache using saltutil.sync_* can be limited.  If nothing is set to a specific type, then all modules are accepted.  To block all modules of a specific type, whitelist an empty list.
• beacons
Top File Settings These parameters only have an effect if running a masterless minion.
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.
default_top Default: base
When top_file_merging_strategy is set to same, and no environment is specified for a highstate (i.e.  environment is not set for the minion), this config option specifies a fallback environment in which to look for a top file if an environment lacks one.
default_top: dev
startup_states Default: ''
States to run when the minion daemon starts. To enable, set startup_states to:
• highstate: Execute state.highstate
• sls: Read in the sls_list option and execute the named sls files
• top: Read top_file option and execute based on that file on the Master
startup_states: ''
sls_list Default: []
List of states to run when the minion starts up if startup_states is set to sls.
sls_list: - edit.vim - hyper
start_event_grains Default: []
List of grains to pass in start event when minion starts up.
start_event_grains: - machine_id - uuid
top_file Default: ''
Top file to execute if startup_states is set to top.
top_file: ''
State Management Settings renderer Default: jinja|yaml
The default renderer used for local state executions
test Default: False
Set all state calls to only test if they are going to actually make changes or just post what changes are going to be made.
test: False
state_verbose: True
autoload_dynamic_modules Default: True
autoload_dynamic_modules turns on automatic loading of modules found in the environments on the master. This is turned on by default. To turn off auto-loading modules when states run, set this value to False.
autoload_dynamic_modules: True
clean_dynamic_modules Default: True
clean_dynamic_modules keeps the dynamic modules on the minion in sync with the dynamic modules on the master. This means that if a dynamic module is not on the master it will be deleted from the minion. By default this is enabled and can be disabled by changing this value to False.
clean_dynamic_modules: True
NOTE: If extmod_whitelist is specified, modules which are not whitelisted will also be cleaned here.
saltenv Changed in version 2018.3.0: Renamed from environment to saltenv. If environment is used, saltenv will take its value. If both are used, environment will be ignored and saltenv will be used.
Normally the minion is not isolated to any single environment on the master when running states, but the environment can be isolated on the minion side by statically setting it. Remember that the recommended way to manage environments is to isolate via the top file.
saltenv: dev
lock_saltenv New in version 2018.3.0.
For purposes of running states, this option prevents using the saltenv argument to manually set the environment. This is useful to keep a minion which has the saltenv option set to dev from running states from an environment other than dev.
lock_saltenv: True
snapper_states Default: False
The snapper_states value is used to enable taking snapper snapshots before and after salt state runs. This allows for state runs to be rolled back.
For snapper states to function properly snapper needs to be installed and enabled.
snapper_states: True
snapper_states_config Default: root
Snapper can execute based on a snapper configuration. The configuration needs to be set up before snapper can use it. The default configuration is root, this default makes snapper run on SUSE systems using the default configuration set up at install time.
snapper_states_config: root
File Directory Settings file_client Default: remote
The client defaults to looking on the master server for files, but can be directed to look on the minion by setting this parameter to local.
file_client: remote
use_master_when_local Default: False
When using a local file_client, this parameter is used to allow the client to connect to a master for remote execution.
use_master_when_local: False
file_roots Default:
When using a local file_client, this parameter is used to setup the fileserver's environments. This parameter operates identically to the master config parameter of the same name.
file_roots: base: - /srv/salt dev: - /srv/salt/dev/services - /srv/salt/dev/states prod: - /srv/salt/prod/services - /srv/salt/prod/states
The hash_type is the hash to use when discovering the hash of a file on the local fileserver. The default is sha256, but md5, sha1, sha224, sha384, and sha512 are also supported.
When using a local file_client, this parameter is used to setup the pillar environments.
pillar_roots: base: - /srv/pillar dev: - /srv/pillar/dev prod: - /srv/pillar/prod
When using a local file_client, this option controls which external pillars are permitted to be used on-demand using pillar.ext.
WARNING: This will allow a masterless minion 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.
pillarenv Default: None
Isolates the pillar environment on the minion side. This functions the same as the environment setting, but for pillar instead of states.
pillarenv: dev
pillarenv_from_saltenv New in version 2017.7.0.
When set to True, the pillarenv value will assume the value of the effective saltenv when running states. This essentially makes salt '*' state.sls mysls saltenv=dev equivalent to salt '*' state.sls mysls saltenv=dev pillarenv=dev. If pillarenv is set, either in the minion config file or via the CLI, it will override this option.
minion_pillar_cache New in version 2016.3.0.
The minion can locally cache rendered pillar data under cachedir/pillar. This allows a temporarily disconnected minion to access previously cached pillar data by invoking salt-call with the --local and --pillar_root=:conf_minion:cachedir/pillar options. Before enabling this setting consider that the rendered pillar may contain security sensitive data.  Appropriate access restrictions should be in place. By default the saved pillar data will be readable only by the user account running salt. By default this feature is disabled, to enable set minion_pillar_cache to True.
minion_pillar_cache: False
pass_to_ext_pillars Specify a list of configuration keys whose values are to be passed to external pillar functions.
Suboptions can be specified using the ':' notation (i.e. option:suboption)
The values are merged and included in the extra_minion_data optional parameter of the external pillar function.  The extra_minion_data parameter is passed only to the external pillar functions that have it explicitly specified in their definition.
If the config contains
opt1: value1 opt2: subopt1: value2 subopt2: value3
pass_to_ext_pillars: - opt1 - opt2: subopt1
the extra_minion_data parameter will be
{"opt1": "value1", "opt2": {"subopt1": "value2"}}
ssh_merge_pillar New in version 2018.3.2.
Merges the compiled pillar data with the pillar data already available globally.  This is useful when using salt-ssh or salt-call --local and overriding the pillar data in a state file:
apply_showpillar: module.run: - name: state.apply - mods: - showpillar - kwargs: pillar: test: "foo bar"
If set to True, the showpillar state will have access to the global pillar data.
If set to False, only the overriding pillar data will be available to the showpillar state.
Security Settings open_mode Default: False
Open mode can be used to clean out the PKI key received from the Salt master, turn on open mode, restart the minion, then turn off open mode and restart the minion to clean the keys.
master_finger Default: ''
Fingerprint of the master public key to validate the identity of your Salt master before the initial key exchange. The master fingerprint can be found as master.pub by running "salt-key -F master" on the Salt master.
master_finger: 'ba:30:65:2a:d6:9e:20:4f:d8:b2:f3:a7:d4:65:11:13'
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.
verify_master_pubkey_sign Default: False
Enables verification of the master-public-signature returned by the master in auth-replies. Please see the tutorial on how to configure this properly Multimaster-PKI with Failover Tutorial
New in version 2014.7.0.
verify_master_pubkey_sign: True
If this is set to True, master_sign_pubkey must be also set to True in the master configuration file.
The filename without the .pub suffix of the public key that should be used for verifying the signature from the master. The file must be located in the minion's pki directory.
autosign_grains New in version 2018.3.0.
The grains that should be sent to the master on authentication to decide if the minion's key should be accepted automatically.
autosign_grains: - uuid - server_id
always_verify_signature Default: False
If verify_master_pubkey_sign is enabled, the signature is only verified if the public-key of the master changes. If the signature should always be verified, this can be set to True.
always_verify_signature: True
cmd_blacklist_glob Default: []
If cmd_blacklist_glob is enabled then any shell command called over remote execution or via salt-call will be checked against the glob matches found in the cmd_blacklist_glob list and any matched shell command will be blocked.
NOTE: This blacklist is only applied to direct executions made by the salt and salt-call commands. This does NOT blacklist commands called from states or shell commands executed from other modules.
New in version 2016.11.0.
cmd_blacklist_glob: - 'rm * ' - 'cat /etc/* '
cmd_whitelist_glob Default: []
If cmd_whitelist_glob is enabled then any shell command called over remote execution or via salt-call will be checked against the glob matches found in the cmd_whitelist_glob list and any shell command NOT found in the list will be blocked. If cmd_whitelist_glob is NOT SET, then all shell commands are permitted.
NOTE: This whitelist is only applied to direct executions made by the salt and salt-call commands. This does NOT restrict commands called from states or shell commands executed from other modules.
cmd_whitelist_glob: - 'ls * ' - 'cat /etc/fstab'
Reactor Settings reactor Default: []
reactor: []
Thread Settings multiprocessing Default: True
If multiprocessing is enabled when a minion receives a publication a new process is spawned and the command is executed therein.  Conversely, if multiprocessing is disabled the new publication will be run executed in a thread.
multiprocessing: True
process_count_max New in version 2018.3.0.
Default: -1
Limit the maximum amount of processes or threads created by salt-minion. This is useful to avoid resource exhaustion in case the minion receives more publications than it is able to handle, as it limits the number of spawned processes or threads. -1 is the default and disables the limit.
process_count_max: -1
Minion Logging Settings log_file Default: /var/log/salt/minion
The minion log can be sent to a regular file, local path name, or network location.  See also log_file.
log_file: /var/log/salt/minion
NOTE: Log colors are enabled in log_fmt_console rather than the color config since the logging system is loaded before the minion config.
zmq_monitor Default: False
To diagnose issues with minions disconnecting or missing returns, ZeroMQ supports the use of monitor sockets to log connection events. This feature requires ZeroMQ 4.0 or higher.
To enable ZeroMQ monitor sockets, set 'zmq_monitor' to 'True' and log at a debug level or higher.
A sample log event is as follows:
[DEBUG   ] ZeroMQ event: {'endpoint': 'tcp://127.0.0.1:4505', 'event': 512, 'value': 27, 'description': 'EVENT_DISCONNECTED'}
All events logged will include the string ZeroMQ event. A connection event should be logged as the minion starts up and initially connects to the master. If not, check for debug log level and that the necessary version of ZeroMQ is installed.
tcp_authentication_retries Default: 5
The number of times to retry authenticating with the salt master when it comes back online.
Zeromq does a lot to make sure when connections come back online that they reauthenticate. The tcp transport should try to connect with a new connection if the old one times out on reauthenticating.
-1 for infinite tries.
tcp_reconnect_backoff Default: 1
The time in seconds to wait before attempting another connection with salt master when the previous connection fails while on TCP transport.
Set the global failhard flag. This informs all states to stop running states at the moment a single state fails
1. The minion config file itself
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 minion config file, and any options defined in include would override both.
default_include Default: minion.d/*.conf
The minion can include configuration from other files. Per default the minion will automatically include all config files from minion.d/*.conf where minion.d is relative to the directory of the minion configuration file.
NOTE: Salt creates files in the minion.d directory for its own use. These files are prefixed with an underscore. A common example of this is the _schedule.conf file.
The minion 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 minion will log a warning message.
# Include files from a minion.d directory in the same # directory as the minion config file include: minion.d/*.conf
# Include several files and the minion.d directory include: - extra_config - minion.d/* - /etc/roles/webserver
Frozen Build Update Settings These options control how salt.modules.saltutil.update() works with esky frozen apps. For more information look at https://github.com/cloudmatrix/esky/.
update_url Default: False (Update feature is disabled)
The url to use when looking for application updates. Esky depends on directory listings to search for new versions. A webserver running on your Master is a good starting point for most setups.
update_url: 'http://salt.example.com/minion-updates'
update_restart_services Default: [] (service restarting on update is disabled)
A list of services to restart when the minion software is updated. This would typically just be a list containing the minion's service name, but you may have other services that need to go with it.
update_restart_services: ['salt-minion']
Windows Software Repo Settings These settings apply to all minions, whether running in masterless or master-minion mode.
winrepo_cache_expire_min New in version 2016.11.0.
Default: 1800
If set to a nonzero integer, then passing refresh=True to functions in the windows pkg module will not refresh the windows repo metadata if the age of the metadata is less than this value. The exception to this is pkg.refresh_db, which will always refresh the metadata, regardless of age.
winrepo_cache_expire_min: 1800
winrepo_cache_expire_max New in version 2016.11.0.
Default: 21600
If the windows repo metadata is older than this value, and the metadata is needed by a function in the windows pkg module, the metadata will be refreshed.
winrepo_cache_expire_max: 86400
winrepo_source_dir Default: salt://win/repo-ng/
The source location for the winrepo sls files.
winrepo_source_dir: salt://win/repo-ng/
Standalone Minion Windows Software Repo Settings The following settings are for configuring the Windows Software Repository (winrepo) on a masterless minion. To run in masterless minion mode, set the file_client to local or run salt-call with the --local option
IMPORTANT: These config options are only valid for minions running in masterless mode
winrepo_dir Changed in version 2015.8.0: Renamed from win_repo to winrepo_dir. This option did not have a default value until this version.
Default: C:\salt\srv\salt\win\repo
Location on the minion file_roots where winrepo files are kept.  This is also where the winrepo_remotes are cloned to by winrepo.update_git_repos.
winrepo_dir: 'D:\winrepo'
Default: C:\salt\srv\salt\win\repo-ng
Location on the minion file_roots where winrepo files are kept for 2018.8.0 and later minions. This is also where the winrepo_remotes are cloned to by winrepo.update_git_repos.
winrepo_cachefile Changed in version 2015.8.0: Renamed from win_repo_cachefile to winrepo_cachefile. Also, this option did not have a default value until this version.
The name of the winrepo cache file. The file will be created at root of the directory specified by winrepo_dir_ng.
winrepo_remotes Changed in version 2015.8.0: Renamed from win_gitrepos to winrepo_remotes. Also, this option did not have a default value until this version.
New in version 2015.8.0.
List of git repositories to checkout and include in the winrepo
Configuring the Salt Proxy 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-proxy is configured via the proxy configuration file.
SEE ALSO: example proxy 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 proxy knows where to locate its master.
By default, the salt-proxy configuration will be in /etc/salt/proxy.  A notable exception is FreeBSD, where the configuration will be in /usr/local/etc/salt/proxy.
Proxy-specific Configuration Options add_proxymodule_to_opts New in version 2015.8.2.
Changed in version 2016.3.0.
Add the proxymodule LazyLoader object to opts.
add_proxymodule_to_opts: True
proxy_merge_grains_in_module New in version 2016.3.0.
Changed in version 2017.7.0.
If a proxymodule has a function called grains, then call it during regular grains loading and merge the results with the proxy's grains dictionary.  Otherwise it is assumed that the module calls the grains function in a custom way and returns the data elsewhere.
proxy_merge_grains_in_module: False
proxy_keep_alive New in version 2017.7.0.
Whether the connection with the remote device should be restarted when dead. The proxy module must implement the alive function, otherwise the connection is considered alive.
proxy_keep_alive: False
proxy_keep_alive_interval New in version 2017.7.0.
The frequency of keepalive checks, in minutes. It requires the proxy_keep_alive option to be enabled (and the proxy module to implement the alive function).
proxy_keep_alive_interval: 5
proxy_always_alive New in version 2017.7.0.
Whether the proxy should maintain the connection with the remote device. Similarly to proxy_keep_alive, this option is very specific to the design of the proxy module.  When proxy_always_alive is set to False, the connection with the remote device is not maintained and has to be closed after every command.
proxy_always_alive: False
proxy_merge_pillar_in_opts New in version 2017.7.3.
Default: False.
Whether the pillar data to be merged into the proxy configuration options.  As multiple proxies can run on the same server, we may need different configuration options for each, while there's one single configuration file.  The solution is merging the pillar data of each proxy minion into the opts.
proxy_merge_pillar_in_opts: True
proxy_deep_merge_pillar_in_opts New in version 2017.7.3.
Deep merge of pillar data into configuration opts.  This option is evaluated only when proxy_merge_pillar_in_opts is enabled.
proxy_merge_pillar_in_opts_strategy New in version 2017.7.3.
Default: smart.
The strategy used when merging pillar configuration into opts.  This option is evaluated only when proxy_merge_pillar_in_opts is enabled.
proxy_mines_pillar New in version 2017.7.3.
Default: True.
Allow enabling mine details using pillar data. This evaluates the mine configuration under the pillar, for the following regular minion options that are also equally available on the proxy minion: mine_interval, and mine_functions.
Configuration file examples • Example master configuration file
• Example minion configuration file
• Example proxy minion configuration file
Example master configuration file ##### Primary configuration settings ##### ########################################## # This configuration file is used to manage the behavior of the Salt Master. # Values that are commented out but have an empty line after the comment are # defaults that do not need to be set in the config. If there is no blank line # after the comment then the value is presented as an example and is not the # default.
# Per default, the master will automatically include all config files # from master.d/*.conf (master.d is a directory in the same directory # as the main master config file). #default_include: master.d/*.conf
# The address of the interface to bind to: #interface: 0.0.0.0
# Whether the master should listen for IPv6 connections. If this is set to True, # the interface option must be adjusted, too. (For example: "interface: '::'") #ipv6: False
# The tcp port used by the publisher: #publish_port: 4505
# The user under which the salt master will run. Salt will update all # permissions to allow the specified user to run the master. The exception is # the job cache, which must be deleted if this user is changed. If the # modified files cause conflicts, set verify_env to False. #user: root
# Tell the master to also use salt-ssh when running commands against minions. #enable_ssh_minions: False
# The port used by the communication interface. The ret (return) port is the # interface used for the file server, authentication, job returns, etc. #ret_port: 4506
# Specify the location of the daemon process ID file: #pidfile: /var/run/salt-master.pid
# The root directory prepended to these options: pki_dir, cachedir, # sock_dir, log_file, autosign_file, autoreject_file, extension_modules, # key_logfile, pidfile, autosign_grains_dir: #root_dir: /
# The path to the master's configuration file. #conf_file: /etc/salt/master
# Directory used to store public key data: #pki_dir: /etc/salt/pki/master
# Key cache. Increases master speed for large numbers of accepted # keys. Available options: 'sched'. (Updates on a fixed schedule.) # Note that enabling this feature means that minions will not be # available to target for up to the length of the maintanence loop # which by default is 60s. #key_cache: ''
# Directory to store job and cache data: # This directory may contain sensitive data and should be protected accordingly. # #cachedir: /var/cache/salt/master
# Directory for custom modules. This directory can contain subdirectories for # each of Salt's module types such as "runners", "output", "wheel", "modules", # "states", "returners", "engines", "utils", etc. #extension_modules: /var/cache/salt/master/extmods
# Directory for custom modules. This directory can contain subdirectories for # each of Salt's module types such as "runners", "output", "wheel", "modules", # "states", "returners", "engines", "utils", etc. # Like 'extension_modules' but can take an array of paths #module_dirs: []
# Verify and set permissions on configuration directories at startup: #verify_env: True
# Set the number of hours to keep old job information in the job cache: #keep_jobs: 24
# The number of seconds to wait when the client is requesting information # about running jobs. #gather_job_timeout: 10
# Set the default timeout for the salt command and api. The default is 5 # seconds. #timeout: 5
# The loop_interval option controls the seconds for the master's maintenance # process check cycle. This process updates file server backends, cleans the # job cache and executes the scheduler. #loop_interval: 60
# Set the default outputter used by the salt command. The default is "nested". #output: nested
# To set a list of additional directories to search for salt outputters, set the # outputter_dirs option. #outputter_dirs: []
# Set the default output file used by the salt command. Default is to output # to the CLI and not to a file. Functions the same way as the "--out-file" # CLI option, only sets this to a single file for all salt commands. #output_file: None
# Return minions that timeout when running commands like test.ping #show_timeout: True
# Tell the client to display the jid when a job is published. #show_jid: False
# By default, output is colored. To disable colored output, set the color value # to False. #color: True
# Do not strip off the colored output from nested results and state outputs # (true by default). # strip_colors: False
# To display a summary of the number of minions targeted, the number of # minions returned, and the number of minions that did not return, set the # cli_summary value to True. (False by default.) # #cli_summary: False
# Set the directory used to hold unix sockets: #sock_dir: /var/run/salt/master