neulab/tldr huggingface dataset:
# List of hosts to bypass HTTP proxy. This key does nothing unless proxy_host etc is # configured, it does not support any kind of wildcards. #no_proxy: []
# If multiple masters are specified in the 'master' setting, the default behavior # is to always try to connect to them in the order they are listed. If random_master # is set to True, the order will be randomized upon Minion startup instead. This can # be helpful in distributing the load of many minions executing salt-call requests, # for example, from a cron job. If only one master is listed, this setting is ignored # and a warning will be logged. #random_master: False
# NOTE: Deprecated in Salt 2019.2.0. Use 'random_master' instead. #master_shuffle: False
# Minions can connect to multiple masters simultaneously (all masters # are "hot"), or can be configured to failover if a master becomes # unavailable.  Multiple hot masters are configured by setting this # value to "str".  Failover masters can be requested by setting # to "failover".  MAKE SURE TO SET master_alive_interval if you are # using failover. # Setting master_type to 'disable' lets you have a running minion (with engines and # beacons) without a master connection # master_type: str
# Poll interval in seconds for checking if the master is still there.  Only # respected if master_type above is "failover". To disable the interval entirely, # set the value to -1. (This may be necessary on machines which have high numbers # of TCP connections, such as load balancers.) # master_alive_interval: 30
# If the minion is in multi-master mode and the master_type configuration option # is set to "failover", this setting can be set to "True" to force the minion # to fail back to the first master in the list if the first master is back online. #master_failback: False
# If the minion is in multi-master mode, the "master_type" configuration is set to # "failover", and the "master_failback" option is enabled, the master failback # interval can be set to ping the top master with this interval, in seconds. #master_failback_interval: 0
# Set whether the minion should connect to the master via IPv6: #ipv6: False
# Set the number of seconds to wait before attempting to resolve # the master hostname if name resolution fails. Defaults to 30 seconds. # Set to zero if the minion should shutdown and not retry. # retry_dns: 30
# Set the number of times to attempt to resolve # the master hostname if name resolution fails. Defaults to None, # which will attempt the resolution indefinitely. # retry_dns_count: 3
# Set the port used by the master reply and authentication server. #master_port: 4506
# The user to run salt. #user: root
# The user to run salt remote execution commands as via sudo. If this option is # enabled then sudo will be used to change the active user executing the remote # command. If enabled the user will need to be allowed access via the sudoers # file for the user that the salt minion is configured to run as. The most # common option would be to use the root user. If this option is set the user # option should also be set to a non-root user. If migrating from a root minion # to a non root minion the minion cache should be cleared and the minion pki # directory will need to be changed to the ownership of the new user. #sudo_user: root
# Specify the location of the daemon process ID file. #pidfile: /var/run/salt-minion.pid
# The root directory prepended to these options: pki_dir, cachedir, log_file, # sock_dir, pidfile. #root_dir: /
# The path to the minion's configuration file. #conf_file: /etc/salt/minion
# The directory to store the pki information in #pki_dir: /etc/salt/pki/minion
# Explicitly declare the id for this minion to use, if left commented the id # will be the hostname as returned by the python call: socket.getfqdn() # Since salt uses detached ids it is possible to run multiple minions on the # same machine but with different ids, this can be useful for salt compute # clusters. #id:
# Cache the minion id to a file when the minion's id is not statically defined # in the minion config. Defaults to "True". This setting prevents potential # problems when automatic minion id resolution changes, which can cause the # minion to lose connection with the master. To turn off minion id caching, # set this config to ``False``. #minion_id_caching: True
# Convert minion id to lowercase when it is being generated. Helpful when some # hosts get the minion id in uppercase. Cached ids will remain the same and # not converted. For example, Windows minions often have uppercase minion # names when they are set up but not always. To turn on, set this config to # ``True``. #minion_id_lowercase: False
# Append a domain to a hostname in the event that it does not exist.  This is # useful for systems where socket.getfqdn() does not actually result in a # FQDN (for instance, Solaris). #append_domain:
# Custom static grains for this minion can be specified here and used in SLS # files just like all other grains. This example sets 4 custom grains, with # the 'roles' grain having two values that can be matched against. #grains: #  roles: #    - webserver #    - memcache #  deployment: datacenter4 #  cabinet: 13 #  cab_u: 14-15 # # Where cache data goes. # This data may contain sensitive data and should be protected accordingly. #cachedir: /var/cache/salt/minion
# Append minion_id to these directories.  Helps with # multiple proxies and minions running on the same machine. # Allowed elements in the list: pki_dir, cachedir, extension_modules # Normally not needed unless running several proxies and/or minions on the same machine # Defaults to ['cachedir'] for proxies, [] (empty list) for regular minions #append_minionid_config_dirs:
# Verify and set permissions on configuration directories at startup. #verify_env: True
# The minion can locally cache the return data from jobs sent to it, this # can be a good way to keep track of jobs the minion has executed # (on the minion side). By default this feature is disabled, to enable, set # cache_jobs to True. #cache_jobs: False
# Set the directory used to hold unix sockets. #sock_dir: /var/run/salt/minion
# In order to calculate the fqdns grain, all the IP addresses from the minion # are processed with underlying calls to `socket.gethostbyaddr` which can take # 5 seconds to be released (after reaching `socket.timeout`) when there is no # fqdn for that IP. These calls to `socket.gethostbyaddr` are processed # asynchronously, however, it still adds 5 seconds every time grains are # generated if an IP does not resolve. In Windows grains are regenerated each # time a new process is spawned. Therefore, the default for Windows is `False`. # All other OSes default to `True` # enable_fqdns_grains: True
# The minion can take a while to start up when lspci and/or dmidecode is used # to populate the grains for the minion. Set this to False if you do not need # GPU hardware grains for your minion. # enable_gpu_grains: True
# Set the default outputter used by the salt-call command. The default is # "nested". #output: nested
# By default output is colored. To disable colored output, set the color value # to False. #color: True
# Backup files that are replaced by file.managed and file.recurse under # 'cachedir'/file_backup relative to their original location and appended # with a timestamp. The only valid setting is "minion". Disabled by default. # # Alternatively this can be specified for each file in state files: # /etc/ssh/sshd_config: #   file.managed: #     - source: salt://ssh/sshd_config #     - backup: minion # #backup_mode: minion
# When waiting for a master to accept the minion's public key, salt will # continuously attempt to reconnect until successful. This is the time, in # seconds, between those reconnection attempts. #acceptance_wait_time: 10
# If this is nonzero, the time between reconnection attempts will increase by # acceptance_wait_time seconds per iteration, up to this maximum. If this is # set to zero, the time between reconnection attempts will stay constant. #acceptance_wait_time_max: 0
# If the master rejects the minion's public key, retry instead of exiting. # Rejected keys will be handled the same as waiting on acceptance. #rejected_retry: False
# When the master key changes, the minion will try to re-auth itself to receive # the new master key. In larger environments this can cause a SYN flood on the # master because all minions try to re-auth immediately. To prevent this and # have a minion wait for a random amount of time, use this optional parameter. # The wait-time will be a random number of seconds between 0 and the defined value. #random_reauth_delay: 60
# To avoid overloading a master when many minions startup at once, a randomized # delay may be set to tell the minions to wait before connecting to the master. # This value is the number of seconds to choose from for a random number. For # example, setting this value to 60 will choose a random number of seconds to delay # on startup between zero seconds and sixty seconds. Setting to '0' will disable # this feature. #random_startup_delay: 0
# When waiting for a master to accept the minion's public key, salt will # continuously attempt to reconnect until successful. This is the timeout value, # in seconds, for each individual attempt. After this timeout expires, the minion # will wait for acceptance_wait_time seconds before trying again. Unless your master # is under unusually heavy load, this should be left at the default. #auth_timeout: 60
# Number of consecutive SaltReqTimeoutError that are acceptable when trying to # authenticate. #auth_tries: 7
# The number of attempts to connect to a master before giving up. # Set this to -1 for unlimited attempts. This allows for a master to have # downtime and the minion to reconnect to it later when it comes back up. # In 'failover' mode, it is the number of attempts for each set of masters. # In this mode, it will cycle through the list of masters for each attempt. # # This is different than auth_tries because auth_tries attempts to # retry auth attempts with a single master. auth_tries is under the # assumption that you can connect to the master but not gain # authorization from it. master_tries will still cycle through all # the masters in a given try, so it is appropriate if you expect # occasional downtime from the master(s). #master_tries: 1
# If authentication fails due to SaltReqTimeoutError during a ping_interval, # cause sub minion process to restart. #auth_safemode: False
# Ping Master to ensure connection is alive (minutes). #ping_interval: 0
# To auto recover minions if master changes IP address (DDNS) #    auth_tries: 10 #    auth_safemode: False #    ping_interval: 2 # # Minions won't know master is missing until a ping fails. After the ping fail, # the minion will attempt authentication and likely fails out and cause a restart. # When the minion restarts it will resolve the masters IP and attempt to reconnect.
# Some installations choose to start all job returns in a cache or a returner # and forgo sending the results back to a master. In this workflow, jobs # are most often executed with --async from the Salt CLI and then results # are evaluated by examining job caches on the minions or any configured returners. # WARNING: Setting this to False will **disable** returns back to the master. #pub_ret: True
# The grains can be merged, instead of overridden, using this option. # This allows custom grains to defined different subvalues of a dictionary # grain. By default this feature is disabled, to enable set grains_deep_merge # to ``True``. #grains_deep_merge: False
# The grains_refresh_every setting allows for a minion to periodically check # its grains to see if they have changed and, if so, to inform the master # of the new grains. This operation is moderately expensive, therefore # care should be taken not to set this value too low. # # Note: This value is expressed in __minutes__! # # A value of 10 minutes is a reasonable default. # # If the value is set to zero, this check is disabled. #grains_refresh_every: 1
# Cache grains on the minion. Default is False. #grains_cache: False
# Cache rendered pillar data on the minion. Default is False. # This may cause 'cachedir'/pillar to contain sensitive data that should be # protected accordingly. #minion_pillar_cache: False
# Grains cache expiration, in seconds. If the cache file is older than this # number of seconds then the grains cache will be dumped and fully re-populated # with fresh data. Defaults to 5 minutes. Will have no effect if 'grains_cache' # is not enabled. # grains_cache_expiration: 300
# Determines whether or not the salt minion should run scheduled mine updates. # Defaults to "True". Set to "False" to disable the scheduled mine updates # (this essentially just does not add the mine update function to the minion's # scheduler). #mine_enabled: True
# Determines whether or not scheduled mine updates should be accompanied by a job # return for the job cache. Defaults to "False". Set to "True" to include job # returns in the job cache for mine updates. #mine_return_job: False
# Example functions that can be run via the mine facility # NO mine functions are established by default. # Note these can be defined in the minion's pillar as well. #mine_functions: #  test.ping: [] #  network.ip_addrs: #    interface: eth0 #    cidr: '10.0.0.0/8'
# The number of minutes between mine updates. #mine_interval: 60
# Windows platforms lack posix IPC and must rely on slower TCP based inter- # process communications.  ipc_mode is set to 'tcp' on such systems. #ipc_mode: ipc
# Overwrite the default tcp ports used by the minion when ipc_mode is set to 'tcp' #tcp_pub_port: 4510 #tcp_pull_port: 4511
# Passing very large events can cause the minion to consume large amounts of # memory. This value tunes the maximum size of a message allowed onto the # minion event bus. The value is expressed in bytes. #max_event_size: 1048576
# When a minion starts up it sends a notification on the event bus with a tag # that looks like this: `salt/minion/<minion_id>/start`. For historical reasons # the minion also sends a similar event with an event tag like this: # `minion_start`. This duplication can cause a lot of clutter on the event bus # when there are many minions. Set `enable_legacy_startup_events: False` in the # minion config to ensure only the `salt/minion/<minion_id>/start` events are # sent. Beginning with the `Sodium` Salt release this option will default to # `False` #enable_legacy_startup_events: True
# To detect failed master(s) and fire events on connect/disconnect, set # master_alive_interval to the number of seconds to poll the masters for # connection events. # #master_alive_interval: 30
# The minion can include configuration from other files. To enable this, # pass a list of paths to this option. The paths can be either relative or # absolute; if relative, they are considered to be relative to the directory # the main minion configuration file lives in (this file). Paths can make use # of shell-style globbing. If no files are matched by a path passed to this # option then the minion will log a warning message. # # Include a config file from some other path: # include: /etc/salt/extra_config # # Include config from several files and directories: #include: #  - /etc/salt/extra_config #  - /etc/roles/webserver
# The syndic minion can verify that it is talking to the correct master via the # key fingerprint of the higher-level master with the "syndic_finger" config. #syndic_finger: '' # # # #####   Minion module management     ##### ########################################## # Disable specific modules. This allows the admin to limit the level of # access the master has to the minion.  The default here is the empty list, # below is an example of how this needs to be formatted in the config file #disable_modules: #  - cmdmod #  - test #disable_returners: []
# This is the reverse of disable_modules.  The default, like disable_modules, is the empty list, # but if this option is set to *anything* then *only* those modules will load. # Note that this is a very large hammer and it can be quite difficult to keep the minion working # the way you think it should since Salt uses many modules internally itself.  At a bare minimum # you need the following enabled or else the minion won't start. #whitelist_modules: #  - cmdmod #  - test #  - config
# Modules can be loaded from arbitrary paths. This enables the easy deployment # of third party modules. Modules for returners and minions can be loaded. # Specify a list of extra directories to search for minion modules and # returners. These paths must be fully qualified! #module_dirs: [] #returner_dirs: [] #states_dirs: [] #render_dirs: [] #utils_dirs: [] # # A module provider can be statically overwritten or extended for the minion # via the providers option, in this case the default module will be # overwritten by the specified module. In this example the pkg module will # be provided by the yumpkg5 module instead of the system default. #providers: #  pkg: yumpkg5 # # Enable Cython modules searching and loading. (Default: False) #cython_enable: False # # Specify a max size (in bytes) for modules on import. This feature is currently # only supported on *nix operating systems and requires psutil. # modules_max_memory: -1
#####    State Management Settings    ##### ########################################### # The default renderer to use in SLS files. This is configured as a # pipe-delimited expression. For example, jinja|yaml will first run jinja # templating on the SLS file, and then load the result as YAML. This syntax is # documented in further depth at the following URL: # # https://docs.saltproject.io/en/latest/ref/renderers/#composing-renderers # # NOTE: The "shebang" prefix (e.g. "#!jinja|yaml") described in the # documentation linked above is for use in an SLS file to override the default # renderer, it should not be used when configuring the renderer here. # #renderer: jinja|yaml # # The failhard option tells the minions to stop immediately after the first # failure detected in the state execution. Defaults to False. #failhard: False # # Reload the modules prior to a highstate run. #autoload_dynamic_modules: True # # clean_dynamic_modules keeps the dynamic modules on the minion in sync with # the dynamic modules on the master, this means that if a dynamic module is # not on the master it will be deleted from the minion. By default, this is # enabled and can be disabled by changing this value to False. #clean_dynamic_modules: True # # Renamed from ``environment`` to ``saltenv``. If ``environment`` is used, # ``saltenv`` will take its value. If both are used, ``environment`` will be # ignored and ``saltenv`` will be used. # Normally the minion is not isolated to any single environment on the master # when running states, but the environment can be isolated on the minion side # by statically setting it. Remember that the recommended way to manage # environments is to isolate via the top file. #saltenv: None # # Isolates the pillar environment on the minion side. This functions the same # as the environment setting, but for pillar instead of states. #pillarenv: None # # Set this option to True to force the pillarenv to be the same as the # effective saltenv when running states. Note that if pillarenv is specified, # this option will be ignored. #pillarenv_from_saltenv: False # # Set this option to 'True' to force a 'KeyError' to be raised whenever an # attempt to retrieve a named value from pillar fails. When this option is set # to 'False', the failed attempt returns an empty string. Default is 'False'. #pillar_raise_on_missing: False # # If using the local file directory, then the state top file name needs to be # defined, by default this is top.sls. #state_top: top.sls # # Run states when the minion daemon starts. To enable, set startup_states to: # 'highstate' -- Execute state.highstate # 'sls' -- Read in the sls_list option and execute the named sls files # 'top' -- Read top_file option and execute based on that file on the Master #startup_states: '' # # List of states to run when the minion starts up if startup_states is 'sls': #sls_list: #  - edit.vim #  - hyper # # List of grains to pass in start event when minion starts up: #start_event_grains: #  - machine_id #  - uuid # # Top file to execute if startup_states is 'top': #top_file: ''
# Automatically aggregate all states that have support for mod_aggregate by # setting to True. Or pass a list of state module names to automatically # aggregate just those types. # # state_aggregate: #   - pkg # #state_aggregate: False
# Disable requisites during state runs by specifying a single requisite # or a list of requisites to disable. # # disabled_requisites: require_in # # disabled_requisites: #     - require #     - require_in
#####     File Directory Settings    ##### ########################################## # The Salt Minion can redirect all file server operations to a local directory, # this allows for the same state tree that is on the master to be used if # copied completely onto the minion. This is a literal copy of the settings on # the master but used to reference a local directory on the minion.
# Set the file client. The client defaults to looking on the master server for # files, but can be directed to look at the local file directory setting # defined below by setting it to "local". Setting a local file_client runs the # minion in masterless mode. #file_client: remote
# The file directory works on environments passed to the minion, each environment # can have multiple root directories, the subdirectories in the multiple file # roots cannot match, otherwise the downloaded files will not be able to be # reliably ensured. A base environment is required to house the top file. # Example: # file_roots: #   base: #     - /srv/salt/ #   dev: #     - /srv/salt/dev/services #     - /srv/salt/dev/states #   prod: #     - /srv/salt/prod/services #     - /srv/salt/prod/states # #file_roots: #  base: #    - /srv/salt
# Uncomment the line below if you do not want the file_server to follow # symlinks when walking the filesystem tree. This is set to True # by default. Currently this only applies to the default roots # fileserver_backend. #fileserver_followsymlinks: False # # Uncomment the line below if you do not want symlinks to be # treated as the files they are pointing to. By default this is set to # False. By uncommenting the line below, any detected symlink while listing # files on the Master will not be returned to the Minion. #fileserver_ignoresymlinks: True # # By default, the Salt fileserver recurses fully into all defined environments # to attempt to find files. To limit this behavior so that the fileserver only # traverses directories with SLS files and special Salt directories like _modules, # enable the option below. This might be useful for installations where a file root # has a very large number of files and performance is negatively impacted. Default # is False. #fileserver_limit_traversal: False
# The hash_type is the hash to use when discovering the hash of a file on # the local fileserver. The default is sha256, but md5, sha1, sha224, sha384 # and sha512 are also supported. # # WARNING: While md5 and sha1 are also supported, do not use them due to the # high chance of possible collisions and thus security breach. # # Warning: Prior to changing this value, the minion should be stopped and all # Salt caches should be cleared. #hash_type: sha256
# The Salt pillar is searched for locally if file_client is set to local. If # this is the case, and pillar data is defined, then the pillar_roots need to # also be configured on the minion: #pillar_roots: #  base: #    - /srv/pillar
# Set a hard-limit on the size of the files that can be pushed to the master. # It will be interpreted as megabytes. Default: 100 #file_recv_max_size: 100 # # ######        Security settings       ##### ########################################### # Enable "open mode", this mode still maintains encryption, but turns off # authentication, this is only intended for highly secure environments or for # the situation where your keys end up in a bad state. If you run in open mode # you do so at your own risk! #open_mode: False
# Enable permissive access to the salt keys.  This allows you to run the # master or minion as root, but have a non-root group be given access to # your pki_dir.  To make the access explicit, root must belong to the group # you've given access to. This is potentially quite insecure. #permissive_pki_access: False
# Fingerprint of the master public key to validate the identity of your Salt master # before the initial key exchange. The master fingerprint can be found by running # "salt-key -f master.pub" on the Salt master. #master_finger: ''
# Grains to be sent to the master on authentication to check if the minion's key # will be accepted automatically. Needs to be configured on the master. #autosign_grains: #  - uuid #  - server_id
######         Thread settings        ##### ########################################### # Disable multiprocessing support, by default when a minion receives a # publication a new process is spawned and the command is executed therein. # # WARNING: Disabling multiprocessing may result in substantial slowdowns # when processing large pillars. See https://github.com/saltstack/salt/issues/38758 # for a full explanation. #multiprocessing: True
# Limit the maximum amount of processes or threads created by salt-minion. # This is useful to avoid resource exhaustion in case the minion receives more # publications than it is able to handle, as it limits the number of spawned # processes or threads. -1 is the default and disables the limit. #process_count_max: -1
#####         Logging settings       ##### ########################################## # The location of the minion log file # The minion log can be sent to a regular file, local path name, or network # location. Remote logging works best when configured to use rsyslogd(8) (e.g.: # ``file:///dev/log``), with rsyslogd(8) configured for network logging. The URI # format is: <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility> #log_file: /var/log/salt/minion #log_file: file:///dev/log #log_file: udp://loghost:10514 # #log_file: /var/log/salt/minion #key_logfile: /var/log/salt/key
# The level of messages to send to the console. # One of 'garbage', 'trace', 'debug', 'info', 'warning', 'error', 'critical'. # # The following log levels are considered INSECURE and may log sensitive data: # ['garbage', 'trace', 'debug'] # # Default: 'warning' #log_level: warning
# The level of messages to send to the log file. # One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'. # If using 'log_granular_levels' this must be set to the highest desired level. # Default: 'warning' #log_level_logfile:
# To diagnose issues with minions disconnecting or missing returns, ZeroMQ # supports the use of monitor sockets to log connection events. This # feature requires ZeroMQ 4.0 or higher. # # To enable ZeroMQ monitor sockets, set 'zmq_monitor' to 'True' and log at a # debug level or higher. # # A sample log event is as follows: # # [DEBUG   ] ZeroMQ event: {'endpoint': 'tcp://127.0.0.1:4505', 'event': 512, # 'value': 27, 'description': 'EVENT_DISCONNECTED'} # # All events logged will include the string 'ZeroMQ event'. A connection event # should be logged as the minion starts up and initially connects to the # master. If not, check for debug log level and that the necessary version of # ZeroMQ is installed. # #zmq_monitor: False
# Number of times to try to authenticate with the salt master when reconnecting # to the master #tcp_authentication_retries: 5
######      Module configuration      ##### ########################################### # Salt allows for modules to be passed arbitrary configuration data, any data # passed here in valid yaml format will be passed on to the salt minion modules # for use. It is STRONGLY recommended that a naming convention be used in which # the module name is followed by a . and then the value. Also, all top level # data must be applied via the yaml dict construct, some examples: # # You can specify that all modules should run in test mode: #test: True # # A simple value for the test module: #test.foo: foo # # A list for the test module: #test.bar: [baz,quo] # # A dict for the test module: #test.baz: {spam: sausage, cheese: bread} # # ######      Update settings          ###### ########################################### # Using the features in Esky, a salt minion can both run as a frozen app and # be updated on the fly. These options control how the update process # (saltutil.update()) behaves. # # The url for finding and downloading updates. Disabled by default. #update_url: False # # The list of services to restart after a successful update. Empty by default. #update_restart_services: []
######      Keepalive settings        ###### ############################################ # ZeroMQ now includes support for configuring SO_KEEPALIVE if supported by # the OS. If connections between the minion and the master pass through # a state tracking device such as a firewall or VPN gateway, there is # the risk that it could tear down the connection the master and minion # without informing either party that their connection has been taken away. # Enabling TCP Keepalives prevents this from happening.
######   Windows Software settings    ###### ############################################ # Location of the repository cache file on the master: #win_repo_cachefile: 'salt://win/repo/winrepo.p'
######      Returner  settings        ###### ############################################ # Default Minion returners. Can be a comma delimited string or a list: # #return: mysql # #return: mysql,slack,redis # #return: #  - mysql #  - hipchat #  - slack
Example proxy minion configuration file ##### Primary configuration settings ##### ########################################## # This configuration file is used to manage the behavior of all Salt Proxy # Minions on this host. # With the exception of the location of the Salt Master Server, values that are # commented out but have an empty line after the comment are defaults that need # not be set in the config. If there is no blank line after the comment, the # value is presented as an example and is not the default.
# Per default the proxy minion will automatically include all config files # from proxy.d/*.conf (proxy.d is a directory in the same directory # as the main minion config file). #default_include: proxy.d/*.conf
# Backwards compatibility option for proxymodules created before 2015.8.2 # This setting will default to 'False' in the 2016.3.0 release # Setting this to True adds proxymodules to the __opts__ dictionary. # This breaks several Salt features (basically anything that serializes # __opts__ over the wire) but retains backwards compatibility. #add_proxymodule_to_opts: True
# If a proxymodule has a function called 'grains', then call it during # regular grains loading and merge the results with the proxy's grains # dictionary.  Otherwise it is assumed that the module calls the grains # function in a custom way and returns the data elsewhere # # Default to False for 2016.3 and 2016.11. Switch to True for 2017.7.0. # proxy_merge_grains_in_module: True
# If a proxymodule has a function called 'alive' returning a boolean # flag reflecting the state of the connection with the remove device, # when this option is set as True, a scheduled job on the proxy will # try restarting the connection. The polling frequency depends on the # next option, 'proxy_keep_alive_interval'. Added in 2017.7.0. # proxy_keep_alive: True
# The polling interval (in minutes) to check if the underlying connection # with the remote device is still alive. This option requires # 'proxy_keep_alive' to be configured as True and the proxymodule to # implement the 'alive' function. Added in 2017.7.0. # proxy_keep_alive_interval: 1
# By default, any proxy opens the connection with the remote device when # initialized. Some proxymodules allow through this option to open/close # the session per command. This requires the proxymodule to have this # capability. Please consult the documentation to see if the proxy type # used can be that flexible. Added in 2017.7.0. # proxy_always_alive: True
# If multiple masters are specified in the 'master' setting, the default behavior # is to always try to connect to them in the order they are listed. If random_master is # set to True, the order will be randomized instead. This can be helpful in distributing # the load of many minions executing salt-call requests, for example, from a cron job. # If only one master is listed, this setting is ignored and a warning will be logged. #random_master: False
# Minions can connect to multiple masters simultaneously (all masters # are "hot"), or can be configured to failover if a master becomes # unavailable.  Multiple hot masters are configured by setting this # value to "str".  Failover masters can be requested by setting # to "failover".  MAKE SURE TO SET master_alive_interval if you are # using failover. # master_type: str
# Poll interval in seconds for checking if the master is still there.  Only # respected if master_type above is "failover". # master_alive_interval: 30
# Setting sudo_user will cause salt to run all execution modules under an sudo # to the user given in sudo_user.  The user under which the salt minion process # itself runs will still be that provided in the user config above, but all # execution modules run by the minion will be rerouted through sudo. #sudo_user: saltdev
# Where cache data goes. # This data may contain sensitive data and should be protected accordingly. #cachedir: /var/cache/salt/minion
# Append minion_id to these directories.  Helps with # multiple proxies and minions running on the same machine. # Allowed elements in the list: pki_dir, cachedir, extension_modules # Normally not needed unless running several proxies and/or minions on the same machine # Defaults to ['cachedir'] for proxies, [] (empty list) for regular minions # append_minionid_config_dirs: #   - cachedir
# Set the default outputter used by the salt-call command. The default is # "nested". #output: nested # # By default output is colored. To disable colored output, set the color value # to False. #color: True
# To auto recover minions if master changes IP address (DDNS) #    auth_tries: 10 #    auth_safemode: False #    ping_interval: 90 # # Minions won't know master is missing until a ping fails. After the ping fail, # the minion will attempt authentication and likely fails out and cause a restart. # When the minion restarts it will resolve the masters IP and attempt to reconnect.
# Overwrite the default tcp ports used by the minion when in tcp mode #tcp_pub_port: 4510 #tcp_pull_port: 4511
# The minion can include configuration from other files. To enable this, # pass a list of paths to this option. The paths can be either relative or # absolute; if relative, they are considered to be relative to the directory # the main minion configuration file lives in (this file). Paths can make use # of shell-style globbing. If no files are matched by a path passed to this # option then the minion will log a warning message. # # Include a config file from some other path: # include: /etc/salt/extra_config # # Include config from several files and directories: #include: #  - /etc/salt/extra_config #  - /etc/roles/webserver # # # #####   Minion module management     ##### ########################################## # Disable specific modules. This allows the admin to limit the level of # access the master has to the minion. #disable_modules: [cmd,test] #disable_returners: [] # # Modules can be loaded from arbitrary paths. This enables the easy deployment # of third party modules. Modules for returners and minions can be loaded. # Specify a list of extra directories to search for minion modules and # returners. These paths must be fully qualified! #module_dirs: [] #returner_dirs: [] #states_dirs: [] #render_dirs: [] #utils_dirs: [] # # A module provider can be statically overwritten or extended for the minion # via the providers option, in this case the default module will be # overwritten by the specified module. In this example the pkg module will # be provided by the yumpkg5 module instead of the system default. #providers: #  pkg: yumpkg5 # # Enable Cython modules searching and loading. (Default: False) #cython_enable: False # # Specify a max size (in bytes) for modules on import. This feature is currently # only supported on *nix operating systems and requires psutil. # modules_max_memory: -1
#####    State Management Settings    ##### ########################################### # The default renderer to use in SLS files. This is configured as a # pipe-delimited expression. For example, jinja|yaml will first run jinja # templating on the SLS file, and then load the result as YAML. This syntax is # documented in further depth at the following URL: # # https://docs.saltproject.io/en/latest/ref/renderers/#composing-renderers # # NOTE: The "shebang" prefix (e.g. "#!jinja|yaml") described in the # documentation linked above is for use in an SLS file to override the default # renderer, it should not be used when configuring the renderer here. # #renderer: jinja|yaml # # The failhard option tells the minions to stop immediately after the first # failure detected in the state execution. Defaults to False. #failhard: False # # Reload the modules prior to a highstate run. #autoload_dynamic_modules: True # # clean_dynamic_modules keeps the dynamic modules on the minion in sync with # the dynamic modules on the master, this means that if a dynamic module is # not on the master it will be deleted from the minion. By default, this is # enabled and can be disabled by changing this value to False. #clean_dynamic_modules: True # # Normally, the minion is not isolated to any single environment on the master # when running states, but the environment can be isolated on the minion side # by statically setting it. Remember that the recommended way to manage # environments is to isolate via the top file. #environment: None # # If using the local file directory, then the state top file name needs to be # defined, by default this is top.sls. #state_top: top.sls # # Run states when the minion daemon starts. To enable, set startup_states to: # 'highstate' -- Execute state.highstate # 'sls' -- Read in the sls_list option and execute the named sls files # 'top' -- Read top_file option and execute based on that file on the Master #startup_states: '' # # List of states to run when the minion starts up if startup_states is 'sls': #sls_list: #  - edit.vim #  - hyper # # Top file to execute if startup_states is 'top': #top_file: ''
# By default, the Salt fileserver recurses fully into all defined environments # to attempt to find files. To limit this behavior so that the fileserver only # traverses directories with SLS files and special Salt directories like _modules, # enable the option below. This might be useful for installations where a file root # has a very large number of files and performance is negatively impacted. Default # is False. #fileserver_limit_traversal: False
# The hash_type is the hash to use when discovering the hash of a file in # the local fileserver. The default is sha256 but sha224, sha384 and sha512 # are also supported. # # WARNING: While md5 and sha1 are also supported, do not use it due to the high chance # of possible collisions and thus security breach. # # WARNING: While md5 is also supported, do not use it due to the high chance # of possible collisions and thus security breach. # # Warning: Prior to changing this value, the minion should be stopped and all # Salt caches should be cleared. #hash_type: sha256
# The Salt pillar is searched for locally if file_client is set to local. If # this is the case, and pillar data is defined, then the pillar_roots need to # also be configured on the minion: #pillar_roots: #  base: #    - /srv/pillar # # ######        Security settings       ##### ########################################### # Enable "open mode", this mode still maintains encryption, but turns off # authentication, this is only intended for highly secure environments or for # the situation where your keys end up in a bad state. If you run in open mode # you do so at your own risk! #open_mode: False
# Fingerprint of the master public key to validate the identity of your Salt master # before the initial key exchange. The master fingerprint can be found by running # "salt-key -F master" on the Salt master. #master_finger: ''
######         Thread settings        ##### ########################################### # Disable multiprocessing support, by default when a minion receives a # publication a new process is spawned and the command is executed therein. #multiprocessing: True
# To diagnose issues with minions disconnecting or missing returns, ZeroMQ # supports the use of monitor sockets # to log connection events. This # feature requires ZeroMQ 4.0 or higher. # # To enable ZeroMQ monitor sockets, set 'zmq_monitor' to 'True' and log at a # debug level or higher. # # A sample log event is as follows: # # [DEBUG   ] ZeroMQ event: {'endpoint': 'tcp://127.0.0.1:4505', 'event': 512, # 'value': 27, 'description': 'EVENT_DISCONNECTED'} # # All events logged will include the string 'ZeroMQ event'. A connection event # should be logged on the as the minion starts up and initially connects to the # master. If not, check for debug log level and that the necessary version of # ZeroMQ is installed. # #zmq_monitor: False
######      Returner  settings        ###### ############################################ # Which returner(s) will be used for minion's result: #return: mysql
Minion Blackout Configuration New in version 2016.3.0.
Salt supports minion blackouts. When a minion is in blackout mode, all remote execution commands are disabled. This allows production minions to be put "on hold", eliminating the risk of an untimely configuration change.
Minion blackouts are configured via a special pillar key, minion_blackout.  If this key is set to True, then the minion will reject all incoming commands, except for saltutil.refresh_pillar. (The exception is important, so minions can be brought out of blackout mode)
Salt also supports an explicit whitelist of additional functions that will be allowed during blackout. This is configured with the special pillar key minion_blackout_whitelist, which is formed as a list:
minion_blackout_whitelist: - test.version - pillar.get
Access Control System New in version 0.10.4.
Salt maintains a standard system used to open granular control to non administrative users to execute Salt commands. The access control system has been applied to all systems used to configure access to non administrative control interfaces in Salt.
These interfaces include, the peer system, the external auth system and the publisher acl system.
The access control system mandated a standard configuration syntax used in all of the three aforementioned systems. While this adds functionality to the configuration in 0.10.4, it does not negate the old configuration.
Now specific functions can be opened up to specific minions from specific users in the case of external auth and publisher ACLs, and for specific minions in the case of the peer system.
Publisher ACL system The salt publisher ACL system is a means to allow system users other than root to have access to execute select salt commands on minions from the master.
NOTE: publisher_acl is useful for allowing local system users to run Salt commands without giving them root access. If you can log into the Salt master directly, then publisher_acl allows you to use Salt without root privileges. If the local system is configured to authenticate against a remote system, like LDAP or Active Directory, then publisher_acl will interact with the remote system transparently.
external_auth is useful for salt-api or for making your own scripts that use Salt's Python API. It can be used at the CLI (with the -a flag) but it is more cumbersome as there are more steps involved.  The only time it is useful at the CLI is when the local system is not configured to authenticate against an external service but you still want Salt to authenticate against an external service.
For more information and examples, see this Access Control System section.
The publisher ACL system is configured in the master configuration file via the publisher_acl configuration option. Under the publisher_acl configuration option the users open to send commands are specified and then a list of the minion functions which will be made available to specified user.  Both users and functions could be specified by exact match, shell glob or regular expression. This configuration is much like the external_auth configuration:
publisher_acl: # Allow thatch to execute anything. thatch: - .* # Allow fred to use test and pkg, but only on "web*" minions. fred: - web*: - test.* - pkg.* # Allow admin and managers to use saltutil module functions admin|manager_.*: - saltutil.* # Allow users to use only my_mod functions on "web*" minions with specific arguments. user_.*: - web*: - 'my_mod.*': args: - 'a.*' - 'b.*' kwargs: 'kwa': 'kwa.*' 'kwb': 'kwb'
Permission Issues Directories required for publisher_acl must be modified to be readable by the users specified:
chmod 755 /var/cache/salt /var/cache/salt/master /var/cache/salt/master/jobs /var/run/salt /var/run/salt/master
NOTE: In addition to the changes above you will also need to modify the permissions of /var/log/salt and the existing log file to be writable by the user(s) which will be running the commands. If you do not wish to do this then you must disable logging or Salt will generate errors as it cannot write to the logs as the system users.
If you are upgrading from earlier versions of salt you must also remove any existing user keys and re-start the Salt master:
rm /var/cache/salt/.*key service salt-master restart
Whitelist and Blacklist Salt's authentication systems can be configured by specifying what is allowed using a whitelist, or by specifying what is disallowed using a blacklist. If you specify a whitelist, only specified operations are allowed. If you specify a blacklist, all operations are allowed except those that are blacklisted.
See publisher_acl and publisher_acl_blacklist.
External Authentication System Salt's External Authentication System (eAuth) allows for Salt to pass through command authorization to any external authentication system, such as PAM or LDAP.
NOTE: eAuth using the PAM external auth system requires salt-master to be run as root as this system needs root access to check authentication.
External Authentication System Configuration The external authentication system allows for specific users to be granted access to execute specific functions on specific minions. Access is configured in the master configuration file and uses the access control system:
external_auth: pam: thatch: - 'web*': - test.* - network.* steve|admin.*: - .*
The above configuration allows the user thatch to execute functions in the test and network modules on the minions that match the web* target. User steve and the users whose logins start with admin, are granted unrestricted access to minion commands.
Salt respects the current PAM configuration in place, and uses the 'login' service to authenticate.
NOTE: The PAM module does not allow authenticating as root.
NOTE: state.sls and state.highstate will return "Failed to authenticate!" if the request timeout is reached.  Use -t flag to increase the timeout
To allow access to wheel modules or runner modules the following @ syntax must be used:
external_auth: pam: thatch: - '@wheel'   # to allow access to all wheel modules - '@runner'  # to allow access to all runner modules - '@jobs'    # to allow access to the jobs runner and/or wheel module
NOTE: The runner/wheel markup is different, since there are no minions to scope the acl to.
NOTE: Globs will not match wheel or runners! They must be explicitly allowed with @wheel or @runner.
WARNING: All users that have external authentication privileges are allowed to run saltutil.findjob. Be aware that this could inadvertently expose some data such as minion IDs.
Matching syntax The structure of the external_auth dictionary can take the following shapes. User and function matches are exact matches, shell glob patterns or regular expressions; minion matches are compound targets.
By user:
external_auth: <eauth backend>: <user or group%>: - <regex to match function>
By user, by minion:
external_auth: <eauth backend>: <user or group%>: <minion compound target>: - <regex to match function>
By user, by runner/wheel: