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