1##### Primary configuration settings #####
2##########################################
3# This configuration file is used to manage the behavior of the Salt Master.
4# Values that are commented out but have an empty line after the comment are
5# defaults that do not need to be set in the config. If there is no blank line
6# after the comment then the value is presented as an example and is not the
7# default.
8
9# Per default, the master will automatically include all config files
10# from master.d/*.conf (master.d is a directory in the same directory
11# as the main master config file).
12#default_include: master.d/*.conf
13
14# The address of the interface to bind to:
15#interface: 0.0.0.0
16
17# Whether the master should listen for IPv6 connections. If this is set to True,
18# the interface option must be adjusted, too. (For example: "interface: '::'")
19#ipv6: False
20
21# The tcp port used by the publisher:
22#publish_port: 4505
23
24# The user under which the salt master will run. Salt will update all
25# permissions to allow the specified user to run the master. The exception is
26# the job cache, which must be deleted if this user is changed. If the
27# modified files cause conflicts, set verify_env to False.
28#user: root
29
30# Tell the master to also use salt-ssh when running commands against minions.
31#enable_ssh_minions: False
32
33# The port used by the communication interface. The ret (return) port is the
34# interface used for the file server, authentication, job returns, etc.
35#ret_port: 4506
36
37# Specify the location of the daemon process ID file:
38#pidfile: /var/run/salt-master.pid
39
40# The root directory prepended to these options: pki_dir, cachedir,
41# sock_dir, log_file, autosign_file, autoreject_file, extension_modules,
42# key_logfile, pidfile, autosign_grains_dir:
43#root_dir: /
44
45# The path to the master's configuration file.
46#conf_file: /usr/local/etc/salt/master
47
48# Directory used to store public key data:
49#pki_dir: /usr/local/etc/salt/pki/master
50
51# Key cache. Increases master speed for large numbers of accepted
52# keys. Available options: 'sched'. (Updates on a fixed schedule.)
53# Note that enabling this feature means that minions will not be
54# available to target for up to the length of the maintanence loop
55# which by default is 60s.
56#key_cache: ''
57
58# Directory to store job and cache data:
59# This directory may contain sensitive data and should be protected accordingly.
60#
61#cachedir: /var/cache/salt/master
62
63# Directory for custom modules. This directory can contain subdirectories for
64# each of Salt's module types such as "runners", "output", "wheel", "modules",
65# "states", "returners", "engines", "utils", etc.
66#extension_modules: /var/cache/salt/master/extmods
67
68# Directory for custom modules. This directory can contain subdirectories for
69# each of Salt's module types such as "runners", "output", "wheel", "modules",
70# "states", "returners", "engines", "utils", etc.
71# Like 'extension_modules' but can take an array of paths
72#module_dirs: []
73
74# Verify and set permissions on configuration directories at startup:
75#verify_env: True
76
77# Set the number of hours to keep old job information in the job cache:
78#keep_jobs: 24
79
80# The number of seconds to wait when the client is requesting information
81# about running jobs.
82#gather_job_timeout: 10
83
84# Set the default timeout for the salt command and api. The default is 5
85# seconds.
86#timeout: 5
87
88# The loop_interval option controls the seconds for the master's maintenance
89# process check cycle. This process updates file server backends, cleans the
90# job cache and executes the scheduler.
91#loop_interval: 60
92
93# Set the default outputter used by the salt command. The default is "nested".
94#output: nested
95
96# To set a list of additional directories to search for salt outputters, set the
97# outputter_dirs option.
98#outputter_dirs: []
99
100# Set the default output file used by the salt command. Default is to output
101# to the CLI and not to a file. Functions the same way as the "--out-file"
102# CLI option, only sets this to a single file for all salt commands.
103#output_file: None
104
105# Return minions that timeout when running commands like test.ping
106#show_timeout: True
107
108# Tell the client to display the jid when a job is published.
109#show_jid: False
110
111# By default, output is colored. To disable colored output, set the color value
112# to False.
113#color: True
114
115# Do not strip off the colored output from nested results and state outputs
116# (true by default).
117# strip_colors: False
118
119# To display a summary of the number of minions targeted, the number of
120# minions returned, and the number of minions that did not return, set the
121# cli_summary value to True. (False by default.)
122#
123#cli_summary: False
124
125# Set the directory used to hold unix sockets:
126#sock_dir: /var/run/salt/master
127
128# The master can take a while to start up when lspci and/or dmidecode is used
129# to populate the grains for the master. Enable if you want to see GPU hardware
130# data for your master.
131# enable_gpu_grains: False
132
133# The master maintains a job cache. While this is a great addition, it can be
134# a burden on the master for larger deployments (over 5000 minions).
135# Disabling the job cache will make previously executed jobs unavailable to
136# the jobs system and is not generally recommended.
137#job_cache: True
138
139# Cache minion grains, pillar and mine data via the cache subsystem in the
140# cachedir or a database.
141#minion_data_cache: True
142
143# Cache subsystem module to use for minion data cache.
144#cache: localfs
145# Enables a fast in-memory cache booster and sets the expiration time.
146#memcache_expire_seconds: 0
147# Set a memcache limit in items (bank + key) per cache storage (driver + driver_opts).
148#memcache_max_items: 1024
149# Each time a cache storage got full cleanup all the expired items not just the oldest one.
150#memcache_full_cleanup: False
151# Enable collecting the memcache stats and log it on `debug` log level.
152#memcache_debug: False
153
154# Store all returns in the given returner.
155# Setting this option requires that any returner-specific configuration also
156# be set. See various returners in salt/returners for details on required
157# configuration values. (See also, event_return_queue, and event_return_queue_max_seconds below.)
158#
159#event_return: mysql
160
161# On busy systems, enabling event_returns can cause a considerable load on
162# the storage system for returners. Events can be queued on the master and
163# stored in a batched fashion using a single transaction for multiple events.
164# By default, events are not queued.
165#event_return_queue: 0
166
167# In some cases enabling event return queueing can be very helpful, but the bus
168# may not busy enough to flush the queue consistently.  Setting this to a reasonable
169# value (1-30 seconds) will cause the queue to be flushed when the oldest event is older
170# than `event_return_queue_max_seconds` regardless of how many events are in the queue.
171#event_return_queue_max_seconds: 0
172
173# Only return events matching tags in a whitelist, supports glob matches.
174#event_return_whitelist:
175#  - salt/master/a_tag
176#  - salt/run/*/ret
177
178# Store all event returns **except** the tags in a blacklist, supports globs.
179#event_return_blacklist:
180#  - salt/master/not_this_tag
181#  - salt/wheel/*/ret
182
183# Passing very large events can cause the minion to consume large amounts of
184# memory. This value tunes the maximum size of a message allowed onto the
185# master event bus. The value is expressed in bytes.
186#max_event_size: 1048576
187
188# Windows platforms lack posix IPC and must rely on slower TCP based inter-
189# process communications. Set ipc_mode to 'tcp' on such systems
190#ipc_mode: ipc
191
192# Overwrite the default tcp ports used by the minion when ipc_mode is set to 'tcp'
193#tcp_master_pub_port: 4510
194#tcp_master_pull_port: 4511
195
196# By default, the master AES key rotates every 24 hours. The next command
197# following a key rotation will trigger a key refresh from the minion which may
198# result in minions which do not respond to the first command after a key refresh.
199#
200# To tell the master to ping all minions immediately after an AES key refresh, set
201# ping_on_rotate to True. This should mitigate the issue where a minion does not
202# appear to initially respond after a key is rotated.
203#
204# Note that ping_on_rotate may cause high load on the master immediately after
205# the key rotation event as minions reconnect. Consider this carefully if this
206# salt master is managing a large number of minions.
207#
208# If disabled, it is recommended to handle this event by listening for the
209# 'aes_key_rotate' event with the 'key' tag and acting appropriately.
210# ping_on_rotate: False
211
212# By default, the master deletes its cache of minion data when the key for that
213# minion is removed. To preserve the cache after key deletion, set
214# 'preserve_minion_cache' to True.
215#
216# WARNING: This may have security implications if compromised minions auth with
217# a previous deleted minion ID.
218#preserve_minion_cache: False
219
220# Allow or deny minions from requesting their own key revocation
221#allow_minion_key_revoke: True
222
223# If max_minions is used in large installations, the master might experience
224# high-load situations because of having to check the number of connected
225# minions for every authentication. This cache provides the minion-ids of
226# all connected minions to all MWorker-processes and greatly improves the
227# performance of max_minions.
228# con_cache: False
229
230# The master can include configuration from other files. To enable this,
231# pass a list of paths to this option. The paths can be either relative or
232# absolute; if relative, they are considered to be relative to the directory
233# the main master configuration file lives in (this file). Paths can make use
234# of shell-style globbing. If no files are matched by a path passed to this
235# option, then the master will log a warning message.
236#
237# Include a config file from some other path:
238# include: /usr/local/etc/salt/extra_config
239#
240# Include config from several files and directories:
241# include:
242#   - /usr/local/etc/salt/extra_config
243
244
245#####  Large-scale tuning settings   #####
246##########################################
247# Max open files
248#
249# Each minion connecting to the master uses AT LEAST one file descriptor, the
250# master subscription connection. If enough minions connect you might start
251# seeing on the console (and then salt-master crashes):
252#   Too many open files (tcp_listener.cpp:335)
253#   Aborted (core dumped)
254#
255# By default this value will be the one of `ulimit -Hn`, ie, the hard limit for
256# max open files.
257#
258# If you wish to set a different value than the default one, uncomment and
259# configure this setting. Remember that this value CANNOT be higher than the
260# hard limit. Raising the hard limit depends on your OS and/or distribution,
261# a good way to find the limit is to search the internet. For example:
262#   raise max open files hard limit debian
263#
264#max_open_files: 100000
265
266# The number of worker threads to start. These threads are used to manage
267# return calls made from minions to the master. If the master seems to be
268# running slowly, increase the number of threads. This setting can not be
269# set lower than 3.
270#worker_threads: 5
271
272# Set the ZeroMQ high water marks
273# http://api.zeromq.org/3-2:zmq-setsockopt
274
275# The listen queue size / backlog
276#zmq_backlog: 1000
277
278# The publisher interface ZeroMQPubServerChannel
279#pub_hwm: 1000
280
281# The master may allocate memory per-event and not
282# reclaim it.
283# To set a high-water mark for memory allocation, use
284# ipc_write_buffer to set a high-water mark for message
285# buffering.
286# Value: In bytes. Set to 'dynamic' to have Salt select
287# a value for you. Default is disabled.
288# ipc_write_buffer: 'dynamic'
289
290# These two batch settings, batch_safe_limit and batch_safe_size, are used to
291# automatically switch to a batch mode execution. If a command would have been
292# sent to more than <batch_safe_limit> minions, then run the command in
293# batches of <batch_safe_size>. If no batch_safe_size is specified, a default
294# of 8 will be used. If no batch_safe_limit is specified, then no automatic
295# batching will occur.
296#batch_safe_limit: 100
297#batch_safe_size: 8
298
299# Master stats enables stats events to be fired from the master at close
300# to the defined interval
301#master_stats: False
302#master_stats_event_iter: 60
303
304
305#####        Security settings       #####
306##########################################
307# Enable passphrase protection of Master private key.  Although a string value
308# is acceptable; passwords should be stored in an external vaulting mechanism
309# and retrieved via sdb. See https://docs.saltproject.io/en/latest/topics/sdb/.
310# Passphrase protection is off by default but an example of an sdb profile and
311# query is as follows.
312# masterkeyring:
313#  driver: keyring
314#  service: system
315#
316# key_pass: sdb://masterkeyring/key_pass
317
318# Enable passphrase protection of the Master signing_key. This only applies if
319# master_sign_pubkey is set to True.  This is disabled by default.
320# master_sign_pubkey: True
321# signing_key_pass: sdb://masterkeyring/signing_pass
322
323# Enable "open mode", this mode still maintains encryption, but turns off
324# authentication, this is only intended for highly secure environments or for
325# the situation where your keys end up in a bad state. If you run in open mode
326# you do so at your own risk!
327#open_mode: False
328
329# Enable auto_accept, this setting will automatically accept all incoming
330# public keys from the minions. Note that this is insecure.
331#auto_accept: False
332
333# The size of key that should be generated when creating new keys.
334#keysize: 2048
335
336# Time in minutes that an incoming public key with a matching name found in
337# pki_dir/minion_autosign/keyid is automatically accepted. Expired autosign keys
338# are removed when the master checks the minion_autosign directory.
339# 0 equals no timeout
340# autosign_timeout: 120
341
342# If the autosign_file is specified, incoming keys specified in the
343# autosign_file will be automatically accepted. This is insecure.  Regular
344# expressions as well as globing lines are supported. The file must be readonly
345# except for the owner. Use permissive_pki_access to allow the group write access.
346#autosign_file: /usr/local/etc/salt/autosign.conf
347
348# Works like autosign_file, but instead allows you to specify minion IDs for
349# which keys will automatically be rejected. Will override both membership in
350# the autosign_file and the auto_accept setting.
351#autoreject_file: /usr/local/etc/salt/autoreject.conf
352
353# If the autosign_grains_dir is specified, incoming keys from minions with grain
354# values matching those defined in files in this directory will be accepted
355# automatically. This is insecure. Minions need to be configured to send the grains.
356#autosign_grains_dir: /usr/local/etc/salt/autosign_grains
357
358# Enable permissive access to the salt keys. This allows you to run the
359# master or minion as root, but have a non-root group be given access to
360# your pki_dir. To make the access explicit, root must belong to the group
361# you've given access to. This is potentially quite insecure. If an autosign_file
362# is specified, enabling permissive_pki_access will allow group access to that
363# specific file.
364#permissive_pki_access: False
365
366# Allow users on the master access to execute specific commands on minions.
367# This setting should be treated with care since it opens up execution
368# capabilities to non root users. By default this capability is completely
369# disabled.
370#publisher_acl:
371#  larry:
372#    - test.ping
373#    - network.*
374#
375# Blacklist any of the following users or modules
376#
377# This example would blacklist all non sudo users, including root from
378# running any commands. It would also blacklist any use of the "cmd"
379# module. This is completely disabled by default.
380#
381#
382# Check the list of configured users in client ACL against users on the
383# system and throw errors if they do not exist.
384#client_acl_verify: True
385#
386#publisher_acl_blacklist:
387#  users:
388#    - root
389#    - '^(?!sudo_).*$'   #  all non sudo users
390#  modules:
391#    - cmd
392
393# Enforce publisher_acl & publisher_acl_blacklist when users have sudo
394# access to the salt command.
395#
396#sudo_acl: False
397
398# The external auth system uses the Salt auth modules to authenticate and
399# validate users to access areas of the Salt system.
400#external_auth:
401#  pam:
402#    fred:
403#      - test.*
404#
405# Time (in seconds) for a newly generated token to live. Default: 12 hours
406#token_expire: 43200
407#
408# Allow eauth users to specify the expiry time of the tokens they generate.
409# A boolean applies to all users or a dictionary of whitelisted eauth backends
410# and usernames may be given.
411# token_expire_user_override:
412#   pam:
413#     - fred
414#     - tom
415#   ldap:
416#     - gary
417#
418#token_expire_user_override: False
419
420# Set to True to enable keeping the calculated user's auth list in the token
421# file. This is disabled by default and the auth list is calculated or requested
422# from the eauth driver each time.
423#keep_acl_in_token: False
424
425# Auth subsystem module to use to get authorized access list for a user. By default it's
426# the same module used for external authentication.
427#eauth_acl_module: django
428
429# Allow minions to push files to the master. This is disabled by default, for
430# security purposes.
431#file_recv: False
432
433# Set a hard-limit on the size of the files that can be pushed to the master.
434# It will be interpreted as megabytes. Default: 100
435#file_recv_max_size: 100
436
437# Signature verification on messages published from the master.
438# This causes the master to cryptographically sign all messages published to its event
439# bus, and minions then verify that signature before acting on the message.
440#
441# This is False by default.
442#
443# Note that to facilitate interoperability with masters and minions that are different
444# versions, if sign_pub_messages is True but a message is received by a minion with
445# no signature, it will still be accepted, and a warning message will be logged.
446# Conversely, if sign_pub_messages is False, but a minion receives a signed
447# message it will be accepted, the signature will not be checked, and a warning message
448# will be logged. This behavior went away in Salt 2014.1.0 and these two situations
449# will cause minion to throw an exception and drop the message.
450# sign_pub_messages: False
451
452# Signature verification on messages published from minions
453# This requires that minions cryptographically sign the messages they
454# publish to the master.  If minions are not signing, then log this information
455# at loglevel 'INFO' and drop the message without acting on it.
456# require_minion_sign_messages: False
457
458# The below will drop messages when their signatures do not validate.
459# Note that when this option is False but `require_minion_sign_messages` is True
460# minions MUST sign their messages but the validity of their signatures
461# is ignored.
462# These two config options exist so a Salt infrastructure can be moved
463# to signing minion messages gradually.
464# drop_messages_signature_fail: False
465
466# Use TLS/SSL encrypted connection between master and minion.
467# Can be set to a dictionary containing keyword arguments corresponding to Python's
468# 'ssl.wrap_socket' method.
469# Default is None.
470#ssl:
471#    keyfile: <path_to_keyfile>
472#    certfile: <path_to_certfile>
473#    ssl_version: PROTOCOL_TLSv1_2
474
475#####     Salt-SSH Configuration     #####
476##########################################
477# Define the default salt-ssh roster module to use
478#roster: flat
479
480# Pass in an alternative location for the salt-ssh `flat` roster file
481#roster_file: /usr/local/etc/salt/roster
482
483# Define locations for `flat` roster files so they can be chosen when using Salt API.
484# An administrator can place roster files into these locations. Then when
485# calling Salt API, parameter 'roster_file' should contain a relative path to
486# these locations. That is, "roster_file=/foo/roster" will be resolved as
487# "/usr/local/etc/salt/roster.d/foo/roster" etc. This feature prevents passing insecure
488# custom rosters through the Salt API.
489#
490#rosters:
491# - /usr/local/etc/salt/roster.d
492# - /opt/salt/some/more/rosters
493
494# The ssh password to log in with.
495#ssh_passwd: ''
496
497#The target system's ssh port number.
498#ssh_port: 22
499
500# Comma-separated list of ports to scan.
501#ssh_scan_ports: 22
502
503# Scanning socket timeout for salt-ssh.
504#ssh_scan_timeout: 0.01
505
506# Boolean to run command via sudo.
507#ssh_sudo: False
508
509# Boolean to run ssh_pre_flight script defined in roster. By default
510# the script will only run if the thin_dir does not exist on the targeted
511# minion. This forces the script to run regardless of the thin dir existing
512# or not.
513#ssh_run_pre_flight: True
514
515# Number of seconds to wait for a response when establishing an SSH connection.
516#ssh_timeout: 60
517
518# The user to log in as.
519#ssh_user: root
520
521# The log file of the salt-ssh command:
522#ssh_log_file: /var/log/salt/ssh
523
524# Pass in minion option overrides that will be inserted into the SHIM for
525# salt-ssh calls. The local minion config is not used for salt-ssh. Can be
526# overridden on a per-minion basis in the roster (`minion_opts`)
527#ssh_minion_opts:
528#  gpg_keydir: /root/gpg
529
530# Set this to True to default to using ~/.ssh/id_rsa for salt-ssh
531# authentication with minions
532#ssh_use_home_key: False
533
534# Set this to True to default salt-ssh to run with ``-o IdentitiesOnly=yes``.
535# This option is intended for situations where the ssh-agent offers many
536# different identities and allows ssh to ignore those identities and use the
537# only one specified in options.
538#ssh_identities_only: False
539
540# List-only nodegroups for salt-ssh. Each group must be formed as either a
541# comma-separated list, or a YAML list. This option is useful to group minions
542# into easy-to-target groups when using salt-ssh. These groups can then be
543# targeted with the normal -N argument to salt-ssh.
544#ssh_list_nodegroups: {}
545
546# salt-ssh has the ability to update the flat roster file if a minion is not
547# found in the roster.  Set this to True to enable it.
548#ssh_update_roster: False
549
550#####    Master Module Management    #####
551##########################################
552# Manage how master side modules are loaded.
553
554# Add any additional locations to look for master runners:
555#runner_dirs: []
556
557# Add any additional locations to look for master utils:
558#utils_dirs: []
559
560# Enable Cython for master side modules:
561#cython_enable: False
562
563
564#####      State System settings     #####
565##########################################
566# The state system uses a "top" file to tell the minions what environment to
567# use and what modules to use. The state_top file is defined relative to the
568# root of the base environment as defined in "File Server settings" below.
569#state_top: top.sls
570
571# The master_tops option replaces the external_nodes option by creating
572# a plugable system for the generation of external top data. The external_nodes
573# option is deprecated by the master_tops option.
574#
575# To gain the capabilities of the classic external_nodes system, use the
576# following configuration:
577# master_tops:
578#   ext_nodes: <Shell command which returns yaml>
579#
580#master_tops: {}
581
582# The renderer to use on the minions to render the state data
583#renderer: jinja|yaml
584
585# Default Jinja environment options for all templates except sls templates
586#jinja_env:
587#  block_start_string: '{%'
588#  block_end_string: '%}'
589#  variable_start_string: '{{'
590#  variable_end_string: '}}'
591#  comment_start_string: '{#'
592#  comment_end_string: '#}'
593#  line_statement_prefix:
594#  line_comment_prefix:
595#  trim_blocks: False
596#  lstrip_blocks: False
597#  newline_sequence: '\n'
598#  keep_trailing_newline: False
599
600# Jinja environment options for sls templates
601#jinja_sls_env:
602#  block_start_string: '{%'
603#  block_end_string: '%}'
604#  variable_start_string: '{{'
605#  variable_end_string: '}}'
606#  comment_start_string: '{#'
607#  comment_end_string: '#}'
608#  line_statement_prefix:
609#  line_comment_prefix:
610#  trim_blocks: False
611#  lstrip_blocks: False
612#  newline_sequence: '\n'
613#  keep_trailing_newline: False
614
615# The failhard option tells the minions to stop immediately after the first
616# failure detected in the state execution, defaults to False
617#failhard: False
618
619# The state_verbose and state_output settings can be used to change the way
620# state system data is printed to the display. By default all data is printed.
621# The state_verbose setting can be set to True or False, when set to False
622# all data that has a result of True and no changes will be suppressed.
623#state_verbose: True
624
625# The state_output setting controls which results will be output full multi line
626# full, terse - each state will be full/terse
627# mixed - only states with errors will be full
628# changes - states with changes and errors will be full
629# full_id, mixed_id, changes_id and terse_id are also allowed;
630# when set, the state ID will be used as name in the output
631#state_output: full
632
633# The state_output_diff setting changes whether or not the output from
634# successful states is returned. Useful when even the terse output of these
635# states is cluttering the logs. Set it to True to ignore them.
636#state_output_diff: False
637
638# The state_output_profile setting changes whether profile information
639# will be shown for each state run.
640#state_output_profile: True
641
642# Automatically aggregate all states that have support for mod_aggregate by
643# setting to 'True'. Or pass a list of state module names to automatically
644# aggregate just those types.
645#
646# state_aggregate:
647#   - pkg
648#
649#state_aggregate: False
650
651# Send progress events as each function in a state run completes execution
652# by setting to 'True'. Progress events are in the format
653# 'salt/job/<JID>/prog/<MID>/<RUN NUM>'.
654#state_events: False
655
656#####      File Server settings      #####
657##########################################
658# Salt runs a lightweight file server written in zeromq to deliver files to
659# minions. This file server is built into the master daemon and does not
660# require a dedicated port.
661
662# The file server works on environments passed to the master, each environment
663# can have multiple root directories, the subdirectories in the multiple file
664# roots cannot match, otherwise the downloaded files will not be able to be
665# reliably ensured. A base environment is required to house the top file.
666# Example:
667# file_roots:
668#   base:
669#     - /usr/local/etc/salt/states/
670#   dev:
671#     - /usr/local/etc/salt/states/dev/services
672#     - /usr/local/etc/salt/states/dev/states
673#   prod:
674#     - /usr/local/etc/salt/states/prod/services
675#     - /usr/local/etc/salt/states/prod/states
676#
677#file_roots:
678#  base:
679#    - /usr/local/etc/salt/states
680#
681
682# The master_roots setting configures a master-only copy of the file_roots dictionary,
683# used by the state compiler.
684#master_roots:
685#  base:
686#    - /usr/local/etc/salt/states-master
687
688# When using multiple environments, each with their own top file, the
689# default behaviour is an unordered merge. To prevent top files from
690# being merged together and instead to only use the top file from the
691# requested environment, set this value to 'same'.
692#top_file_merging_strategy: merge
693
694# To specify the order in which environments are merged, set the ordering
695# in the env_order option. Given a conflict, the last matching value will
696# win.
697#env_order: ['base', 'dev', 'prod']
698
699# If top_file_merging_strategy is set to 'same' and an environment does not
700# contain a top file, the top file in the environment specified by default_top
701# will be used instead.
702#default_top: base
703
704# The hash_type is the hash to use when discovering the hash of a file on
705# the master server. The default is sha256, but md5, sha1, sha224, sha384 and
706# sha512 are also supported.
707#
708# WARNING: While md5 and sha1 are also supported, do not use them due to the
709# high chance of possible collisions and thus security breach.
710#
711# Prior to changing this value, the master should be stopped and all Salt
712# caches should be cleared.
713#hash_type: sha256
714
715# The buffer size in the file server can be adjusted here:
716#file_buffer_size: 1048576
717
718# A regular expression (or a list of expressions) that will be matched
719# against the file path before syncing the modules and states to the minions.
720# This includes files affected by the file.recurse state.
721# For example, if you manage your custom modules and states in subversion
722# and don't want all the '.svn' folders and content synced to your minions,
723# you could set this to '/\.svn($|/)'. By default nothing is ignored.
724#file_ignore_regex:
725#  - '/\.svn($|/)'
726#  - '/\.git($|/)'
727
728# A file glob (or list of file globs) that will be matched against the file
729# path before syncing the modules and states to the minions. This is similar
730# to file_ignore_regex above, but works on globs instead of regex. By default
731# nothing is ignored.
732# file_ignore_glob:
733#  - '*.pyc'
734#  - '*/somefolder/*.bak'
735#  - '*.swp'
736
737# File Server Backend
738#
739# Salt supports a modular fileserver backend system, this system allows
740# the salt master to link directly to third party systems to gather and
741# manage the files available to minions. Multiple backends can be
742# configured and will be searched for the requested file in the order in which
743# they are defined here. The default setting only enables the standard backend
744# "roots" which uses the "file_roots" option.
745#fileserver_backend:
746#  - roots
747#
748# To use multiple backends list them in the order they are searched:
749#fileserver_backend:
750#  - git
751#  - roots
752#
753# Uncomment the line below if you do not want the file_server to follow
754# symlinks when walking the filesystem tree. This is set to True
755# by default. Currently this only applies to the default roots
756# fileserver_backend.
757#fileserver_followsymlinks: False
758#
759# Uncomment the line below if you do not want symlinks to be
760# treated as the files they are pointing to. By default this is set to
761# False. By uncommenting the line below, any detected symlink while listing
762# files on the Master will not be returned to the Minion.
763#fileserver_ignoresymlinks: True
764#
765# By default, the Salt fileserver recurses fully into all defined environments
766# to attempt to find files. To limit this behavior so that the fileserver only
767# traverses directories with SLS files and special Salt directories like _modules,
768# enable the option below. This might be useful for installations where a file root
769# has a very large number of files and performance is impacted. Default is False.
770# fileserver_limit_traversal: False
771#
772# The fileserver can fire events off every time the fileserver is updated,
773# these are disabled by default, but can be easily turned on by setting this
774# flag to True
775#fileserver_events: False
776
777# Git File Server Backend Configuration
778#
779# Optional parameter used to specify the provider to be used for gitfs. Must be
780# either pygit2 or gitpython. If unset, then both will be tried (in that
781# order), and the first one with a compatible version installed will be the
782# provider that is used.
783#
784#gitfs_provider: pygit2
785
786# Along with gitfs_password, is used to authenticate to HTTPS remotes.
787# gitfs_user: ''
788
789# Along with gitfs_user, is used to authenticate to HTTPS remotes.
790# This parameter is not required if the repository does not use authentication.
791#gitfs_password: ''
792
793# By default, Salt will not authenticate to an HTTP (non-HTTPS) remote.
794# This parameter enables authentication over HTTP. Enable this at your own risk.
795#gitfs_insecure_auth: False
796
797# Along with gitfs_privkey (and optionally gitfs_passphrase), is used to
798# authenticate to SSH remotes. This parameter (or its per-remote counterpart)
799# is required for SSH remotes.
800#gitfs_pubkey: ''
801
802# Along with gitfs_pubkey (and optionally gitfs_passphrase), is used to
803# authenticate to SSH remotes. This parameter (or its per-remote counterpart)
804# is required for SSH remotes.
805#gitfs_privkey: ''
806
807# This parameter is optional, required only when the SSH key being used to
808# authenticate is protected by a passphrase.
809#gitfs_passphrase: ''
810
811# When using the git fileserver backend at least one git remote needs to be
812# defined. The user running the salt master will need read access to the repo.
813#
814# The repos will be searched in order to find the file requested by a client
815# and the first repo to have the file will return it.
816# When using the git backend branches and tags are translated into salt
817# environments.
818# Note: file:// repos will be treated as a remote, so refs you want used must
819# exist in that repo as *local* refs.
820#gitfs_remotes:
821#  - git://github.com/saltstack/salt-states.git
822#  - file:///var/git/saltmaster
823#
824# The gitfs_ssl_verify option specifies whether to ignore ssl certificate
825# errors when contacting the gitfs backend. You might want to set this to
826# false if you're using a git backend that uses a self-signed certificate but
827# keep in mind that setting this flag to anything other than the default of True
828# is a security concern, you may want to try using the ssh transport.
829#gitfs_ssl_verify: True
830#
831# The gitfs_root option gives the ability to serve files from a subdirectory
832# within the repository. The path is defined relative to the root of the
833# repository and defaults to the repository root.
834#gitfs_root: somefolder/otherfolder
835#
836# The refspecs fetched by gitfs remotes
837#gitfs_refspecs:
838#  - '+refs/heads/*:refs/remotes/origin/*'
839#  - '+refs/tags/*:refs/tags/*'
840#
841#
842#####         Pillar settings        #####
843##########################################
844# Salt Pillars allow for the building of global data that can be made selectively
845# available to different minions based on minion grain filtering. The Salt
846# Pillar is laid out in the same fashion as the file server, with environments,
847# a top file and sls files. However, pillar data does not need to be in the
848# highstate format, and is generally just key/value pairs.
849#pillar_roots:
850#  base:
851#    - /usr/local/etc/salt/pillar
852#
853#ext_pillar:
854#  - hiera: /etc/hiera.yaml
855#  - cmd_yaml: cat /usr/local/etc/salt/yaml
856
857
858# A list of paths to be recursively decrypted during pillar compilation.
859# Entries in this list can be formatted either as a simple string, or as a
860# key/value pair, with the key being the pillar location, and the value being
861# the renderer to use for pillar decryption. If the former is used, the
862# renderer specified by decrypt_pillar_default will be used.
863#decrypt_pillar:
864#  - 'foo:bar': gpg
865#  - 'lorem:ipsum:dolor'
866
867# The delimiter used to distinguish nested data structures in the
868# decrypt_pillar option.
869#decrypt_pillar_delimiter: ':'
870
871# The default renderer used for decryption, if one is not specified for a given
872# pillar key in decrypt_pillar.
873#decrypt_pillar_default: gpg
874
875# List of renderers which are permitted to be used for pillar decryption.
876#decrypt_pillar_renderers:
877#  - gpg
878
879# The ext_pillar_first option allows for external pillar sources to populate
880# before file system pillar. This allows for targeting file system pillar from
881# ext_pillar.
882#ext_pillar_first: False
883
884# The external pillars permitted to be used on-demand using pillar.ext
885#on_demand_ext_pillar:
886#  - libvirt
887#  - virtkey
888
889# The pillar_gitfs_ssl_verify option specifies whether to ignore ssl certificate
890# errors when contacting the pillar gitfs backend. You might want to set this to
891# false if you're using a git backend that uses a self-signed certificate but
892# keep in mind that setting this flag to anything other than the default of True
893# is a security concern, you may want to try using the ssh transport.
894#pillar_gitfs_ssl_verify: True
895
896# The pillar_opts option adds the master configuration file data to a dict in
897# the pillar called "master". This is used to set simple configurations in the
898# master config file that can then be used on minions.
899#pillar_opts: False
900
901# The pillar_safe_render_error option prevents the master from passing pillar
902# render errors to the minion. This is set on by default because the error could
903# contain templating data which would give that minion information it shouldn't
904# have, like a password! When set true the error message will only show:
905#   Rendering SLS 'my.sls' failed. Please see master log for details.
906#pillar_safe_render_error: True
907
908# The pillar_source_merging_strategy option allows you to configure merging strategy
909# between different sources. It accepts five values: none, recurse, aggregate, overwrite,
910# or smart. None will not do any merging at all. Recurse will merge recursively mapping of data.
911# Aggregate instructs aggregation of elements between sources that use the #!yamlex renderer. Overwrite
912# will overwrite elements according the order in which they are processed. This is
913# behavior of the 2014.1 branch and earlier. Smart guesses the best strategy based
914# on the "renderer" setting and is the default value.
915#pillar_source_merging_strategy: smart
916
917# Recursively merge lists by aggregating them instead of replacing them.
918#pillar_merge_lists: False
919
920# Set this option to True to force the pillarenv to be the same as the effective
921# saltenv when running states. If pillarenv is specified this option will be
922# ignored.
923#pillarenv_from_saltenv: False
924
925# Set this option to 'True' to force a 'KeyError' to be raised whenever an
926# attempt to retrieve a named value from pillar fails. When this option is set
927# to 'False', the failed attempt returns an empty string. Default is 'False'.
928#pillar_raise_on_missing: False
929
930# Git External Pillar (git_pillar) Configuration Options
931#
932# Specify the provider to be used for git_pillar. Must be either pygit2 or
933# gitpython. If unset, then both will be tried in that same order, and the
934# first one with a compatible version installed will be the provider that
935# is used.
936#git_pillar_provider: pygit2
937
938# If the desired branch matches this value, and the environment is omitted
939# from the git_pillar configuration, then the environment for that git_pillar
940# remote will be base.
941#git_pillar_base: master
942
943# If the branch is omitted from a git_pillar remote, then this branch will
944# be used instead
945#git_pillar_branch: master
946
947# Environment to use for git_pillar remotes. This is normally derived from
948# the branch/tag (or from a per-remote env parameter), but if set this will
949# override the process of deriving the env from the branch/tag name.
950#git_pillar_env: ''
951
952# Path relative to the root of the repository where the git_pillar top file
953# and SLS files are located.
954#git_pillar_root: ''
955
956# Specifies whether or not to ignore SSL certificate errors when contacting
957# the remote repository.
958#git_pillar_ssl_verify: False
959
960# When set to False, if there is an update/checkout lock for a git_pillar
961# remote and the pid written to it is not running on the master, the lock
962# file will be automatically cleared and a new lock will be obtained.
963#git_pillar_global_lock: True
964
965# Git External Pillar Authentication Options
966#
967# Along with git_pillar_password, is used to authenticate to HTTPS remotes.
968#git_pillar_user: ''
969
970# Along with git_pillar_user, is used to authenticate to HTTPS remotes.
971# This parameter is not required if the repository does not use authentication.
972#git_pillar_password: ''
973
974# By default, Salt will not authenticate to an HTTP (non-HTTPS) remote.
975# This parameter enables authentication over HTTP.
976#git_pillar_insecure_auth: False
977
978# Along with git_pillar_privkey (and optionally git_pillar_passphrase),
979# is used to authenticate to SSH remotes.
980#git_pillar_pubkey: ''
981
982# Along with git_pillar_pubkey (and optionally git_pillar_passphrase),
983# is used to authenticate to SSH remotes.
984#git_pillar_privkey: ''
985
986# This parameter is optional, required only when the SSH key being used
987# to authenticate is protected by a passphrase.
988#git_pillar_passphrase: ''
989
990# The refspecs fetched by git_pillar remotes
991#git_pillar_refspecs:
992#  - '+refs/heads/*:refs/remotes/origin/*'
993#  - '+refs/tags/*:refs/tags/*'
994
995# A master can cache pillars locally to bypass the expense of having to render them
996# for each minion on every request. This feature should only be enabled in cases
997# where pillar rendering time is known to be unsatisfactory and any attendant security
998# concerns about storing pillars in a master cache have been addressed.
999#
1000# When enabling this feature, be certain to read through the additional ``pillar_cache_*``
1001# configuration options to fully understand the tunable parameters and their implications.
1002#
1003# Note: setting ``pillar_cache: True`` has no effect on targeting Minions with Pillars.
1004# See https://docs.saltproject.io/en/latest/topics/targeting/pillar.html
1005#pillar_cache: False
1006
1007# If and only if a master has set ``pillar_cache: True``, the cache TTL controls the amount
1008# of time, in seconds, before the cache is considered invalid by a master and a fresh
1009# pillar is recompiled and stored.
1010#pillar_cache_ttl: 3600
1011
1012# If and only if a master has set `pillar_cache: True`, one of several storage providers
1013# can be utilized.
1014#
1015# `disk`: The default storage backend. This caches rendered pillars to the master cache.
1016#         Rendered pillars are serialized and deserialized as msgpack structures for speed.
1017#         Note that pillars are stored UNENCRYPTED. Ensure that the master cache
1018#         has permissions set appropriately. (Same defaults are provided.)
1019#
1020# memory: [EXPERIMENTAL] An optional backend for pillar caches which uses a pure-Python
1021#         in-memory data structure for maximal performance. There are several caveats,
1022#         however. First, because each master worker contains its own in-memory cache,
1023#         there is no guarantee of cache consistency between minion requests. This
1024#         works best in situations where the pillar rarely if ever changes. Secondly,
1025#         and perhaps more importantly, this means that unencrypted pillars will
1026#         be accessible to any process which can examine the memory of the ``salt-master``!
1027#         This may represent a substantial security risk.
1028#
1029#pillar_cache_backend: disk
1030
1031# A master can also cache GPG data locally to bypass the expense of having to render them
1032# for each minion on every request. This feature should only be enabled in cases
1033# where pillar rendering time is known to be unsatisfactory and any attendant security
1034# concerns about storing decrypted GPG data in a master cache have been addressed.
1035#
1036# When enabling this feature, be certain to read through the additional ``gpg_cache_*``
1037# configuration options to fully understand the tunable parameters and their implications.
1038#gpg_cache: False
1039
1040# If and only if a master has set ``gpg_cache: True``, the cache TTL controls the amount
1041# of time, in seconds, before the cache is considered invalid by a master and a fresh
1042# pillar is recompiled and stored.
1043#gpg_cache_ttl: 86400
1044
1045# If and only if a master has set `gpg_cache: True`, one of several storage providers
1046# can be utilized. Available options are the same as ``pillar_cache_backend``.
1047#gpg_cache_backend: disk
1048
1049
1050######        Reactor Settings        #####
1051###########################################
1052# Define a salt reactor. See https://docs.saltproject.io/en/latest/topics/reactor/
1053#reactor: []
1054
1055#Set the TTL for the cache of the reactor configuration.
1056#reactor_refresh_interval: 60
1057
1058#Configure the number of workers for the runner/wheel in the reactor.
1059#reactor_worker_threads: 10
1060
1061#Define the queue size for workers in the reactor.
1062#reactor_worker_hwm: 10000
1063
1064
1065#####          Syndic settings       #####
1066##########################################
1067# The Salt syndic is used to pass commands through a master from a higher
1068# master. Using the syndic is simple. If this is a master that will have
1069# syndic servers(s) below it, then set the "order_masters" setting to True.
1070#
1071# If this is a master that will be running a syndic daemon for passthrough, then
1072# the "syndic_master" setting needs to be set to the location of the master server
1073# to receive commands from.
1074
1075# Set the order_masters setting to True if this master will command lower
1076# masters' syndic interfaces.
1077#order_masters: False
1078
1079# If this master will be running a salt syndic daemon, syndic_master tells
1080# this master where to receive commands from.
1081#syndic_master: masterofmasters
1082
1083# This is the 'ret_port' of the MasterOfMaster:
1084#syndic_master_port: 4506
1085
1086# PID file of the syndic daemon:
1087#syndic_pidfile: /var/run/salt-syndic.pid
1088
1089# The log file of the salt-syndic daemon:
1090#syndic_log_file: /var/log/salt/syndic
1091
1092# The behaviour of the multi-syndic when connection to a master of masters failed.
1093# Can specify ``random`` (default) or ``ordered``. If set to ``random``, masters
1094# will be iterated in random order. If ``ordered`` is specified, the configured
1095# order will be used.
1096#syndic_failover: random
1097
1098# The number of seconds for the salt client to wait for additional syndics to
1099# check in with their lists of expected minions before giving up.
1100#syndic_wait: 5
1101
1102
1103#####      Peer Publish settings     #####
1104##########################################
1105# Salt minions can send commands to other minions, but only if the minion is
1106# allowed to. By default "Peer Publication" is disabled, and when enabled it
1107# is enabled for specific minions and specific commands. This allows secure
1108# compartmentalization of commands based on individual minions.
1109
1110# The configuration uses regular expressions to match minions and then a list
1111# of regular expressions to match functions. The following will allow the
1112# minion authenticated as foo.example.com to execute functions from the test
1113# and pkg modules.
1114#peer:
1115#  foo.example.com:
1116#    - test.*
1117#    - pkg.*
1118#
1119# This will allow all minions to execute all commands:
1120#peer:
1121#  .*:
1122#    - .*
1123#
1124# This is not recommended, since it would allow anyone who gets root on any
1125# single minion to instantly have root on all of the minions!
1126
1127# Minions can also be allowed to execute runners from the salt master.
1128# Since executing a runner from the minion could be considered a security risk,
1129# it needs to be enabled. This setting functions just like the peer setting
1130# except that it opens up runners instead of module functions.
1131#
1132# All peer runner support is turned off by default and must be enabled before
1133# using. This will enable all peer runners for all minions:
1134#peer_run:
1135#  .*:
1136#    - .*
1137#
1138# To enable just the manage.up runner for the minion foo.example.com:
1139#peer_run:
1140#  foo.example.com:
1141#    - manage.up
1142#
1143#
1144#####         Mine settings     #####
1145#####################################
1146# Restrict mine.get access from minions. By default any minion has a full access
1147# to get all mine data from master cache. In acl definion below, only pcre matches
1148# are allowed.
1149# mine_get:
1150#   .*:
1151#     - .*
1152#
1153# The example below enables minion foo.example.com to get 'network.interfaces' mine
1154# data only, minions web* to get all network.* and disk.* mine data and all other
1155# minions won't get any mine data.
1156# mine_get:
1157#   foo.example.com:
1158#     - network.interfaces
1159#   web.*:
1160#     - network.*
1161#     - disk.*
1162
1163
1164#####         Logging settings       #####
1165##########################################
1166# The location of the master log file
1167# The master log can be sent to a regular file, local path name, or network
1168# location. Remote logging works best when configured to use rsyslogd(8) (e.g.:
1169# ``file:///dev/log``), with rsyslogd(8) configured for network logging. The URI
1170# format is: <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>
1171#log_file: /var/log/salt/master
1172#log_file: file:///dev/log
1173#log_file: udp://loghost:10514
1174
1175#log_file: /var/log/salt/master
1176#key_logfile: /var/log/salt/key
1177
1178# The level of messages to send to the console.
1179# One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
1180#
1181# The following log levels are considered INSECURE and may log sensitive data:
1182# ['garbage', 'trace', 'debug']
1183#
1184#log_level: warning
1185
1186# The level of messages to send to the log file.
1187# One of 'garbage', 'trace', 'debug', 'info', 'warning', 'error', 'critical'.
1188# If using 'log_granular_levels' this must be set to the highest desired level.
1189#log_level_logfile: warning
1190
1191# The date and time format used in log messages. Allowed date/time formatting
1192# can be seen here: http://docs.python.org/library/time.html#time.strftime
1193#log_datefmt: '%H:%M:%S'
1194#log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'
1195
1196# The format of the console logging messages. Allowed formatting options can
1197# be seen here: http://docs.python.org/library/logging.html#logrecord-attributes
1198#
1199# Console log colors are specified by these additional formatters:
1200#
1201# %(colorlevel)s
1202# %(colorname)s
1203# %(colorprocess)s
1204# %(colormsg)s
1205#
1206# Since it is desirable to include the surrounding brackets, '[' and ']', in
1207# the coloring of the messages, these color formatters also include padding as
1208# well.  Color LogRecord attributes are only available for console logging.
1209#
1210#log_fmt_console: '%(colorlevel)s %(colormsg)s'
1211#log_fmt_console: '[%(levelname)-8s] %(message)s'
1212#
1213#log_fmt_logfile: '%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s'
1214
1215# This can be used to control logging levels more specificically.  This
1216# example sets the main salt library at the 'warning' level, but sets
1217# 'salt.modules' to log at the 'debug' level:
1218#   log_granular_levels:
1219#     'salt': 'warning'
1220#     'salt.modules': 'debug'
1221#
1222#log_granular_levels: {}
1223
1224
1225#####         Node Groups           ######
1226##########################################
1227# Node groups allow for logical groupings of minion nodes. A group consists of
1228# a group name and a compound target. Nodgroups can reference other nodegroups
1229# with 'N@' classifier. Ensure that you do not have circular references.
1230#
1231#nodegroups:
1232#  group1: 'L@foo.domain.com,bar.domain.com,baz.domain.com or bl*.domain.com'
1233#  group2: 'G@os:Debian and foo.domain.com'
1234#  group3: 'G@os:Debian and N@group1'
1235#  group4:
1236#    - 'G@foo:bar'
1237#    - 'or'
1238#    - 'G@foo:baz'
1239
1240
1241#####     Range Cluster settings     #####
1242##########################################
1243# The range server (and optional port) that serves your cluster information
1244# https://github.com/ytoolshed/range/wiki/%22yamlfile%22-module-file-spec
1245#
1246#range_server: range:80
1247
1248
1249#####  Windows Software Repo settings #####
1250###########################################
1251# Location of the repo on the master:
1252#winrepo_dir_ng: '/usr/local/etc/salt/states/win/repo-ng'
1253#
1254# List of git repositories to include with the local repo:
1255#winrepo_remotes_ng:
1256#  - 'https://github.com/saltstack/salt-winrepo-ng.git'
1257
1258
1259#####  Windows Software Repo settings - Pre 2015.8 #####
1260########################################################
1261# Legacy repo settings for pre-2015.8 Windows minions.
1262#
1263# Location of the repo on the master:
1264#winrepo_dir: '/usr/local/etc/salt/states/win/repo'
1265#
1266# Location of the master's repo cache file:
1267#winrepo_mastercachefile: '/usr/local/etc/salt/states/win/repo/winrepo.p'
1268#
1269# List of git repositories to include with the local repo:
1270#winrepo_remotes:
1271#  - 'https://github.com/saltstack/salt-winrepo.git'
1272
1273# The refspecs fetched by winrepo remotes
1274#winrepo_refspecs:
1275#  - '+refs/heads/*:refs/remotes/origin/*'
1276#  - '+refs/tags/*:refs/tags/*'
1277#
1278
1279#####      Returner settings          ######
1280############################################
1281# Which returner(s) will be used for minion's result:
1282#return: mysql
1283
1284
1285######    Miscellaneous  settings     ######
1286############################################
1287# Default match type for filtering events tags: startswith, endswith, find, regex, fnmatch
1288#event_match_type: startswith
1289
1290# Save runner returns to the job cache
1291#runner_returns: True
1292
1293# Permanently include any available Python 3rd party modules into thin and minimal Salt
1294# when they are generated for Salt-SSH or other purposes.
1295# The modules should be named by the names they are actually imported inside the Python.
1296# The value of the parameters can be either one module or a comma separated list of them.
1297#thin_extra_mods: foo,bar
1298#min_extra_mods: foo,bar,baz
1299
1300
1301######      Keepalive settings        ######
1302############################################
1303# Warning: Failure to set TCP keepalives on the salt-master can result in
1304# not detecting the loss of a minion when the connection is lost or when
1305# its host has been terminated without first closing the socket.
1306# Salt's Presence System depends on this connection status to know if a minion
1307# is "present".
1308# ZeroMQ now includes support for configuring SO_KEEPALIVE if supported by
1309# the OS. If connections between the minion and the master pass through
1310# a state tracking device such as a firewall or VPN gateway, there is
1311# the risk that it could tear down the connection the master and minion
1312# without informing either party that their connection has been taken away.
1313# Enabling TCP Keepalives prevents this from happening.
1314
1315# Overall state of TCP Keepalives, enable (1 or True), disable (0 or False)
1316# or leave to the OS defaults (-1), on Linux, typically disabled. Default True, enabled.
1317#tcp_keepalive: True
1318
1319# How long before the first keepalive should be sent in seconds. Default 300
1320# to send the first keepalive after 5 minutes, OS default (-1) is typically 7200 seconds
1321# on Linux see /proc/sys/net/ipv4/tcp_keepalive_time.
1322#tcp_keepalive_idle: 300
1323
1324# How many lost probes are needed to consider the connection lost. Default -1
1325# to use OS defaults, typically 9 on Linux, see /proc/sys/net/ipv4/tcp_keepalive_probes.
1326#tcp_keepalive_cnt: -1
1327
1328# How often, in seconds, to send keepalives after the first one. Default -1 to
1329# use OS defaults, typically 75 seconds on Linux, see
1330# /proc/sys/net/ipv4/tcp_keepalive_intvl.
1331#tcp_keepalive_intvl: -1
1332
1333
1334#####         NetAPI settings          #####
1335############################################
1336# Allow the raw_shell parameter to be used when calling Salt SSH client via API
1337#netapi_allow_raw_shell: True
1338