mirror of
https://github.com/valitydev/salt.git
synced 2024-11-07 08:58:59 +00:00
112 lines
4.0 KiB
Plaintext
112 lines
4.0 KiB
Plaintext
##### Primary configuration settings #####
|
|
##########################################
|
|
# Set the location of the salt master server, if the master server cannot be
|
|
# resolved, then the minion will fail to start
|
|
#master: salt
|
|
|
|
# Set the post used by the master reply and authentication server
|
|
#master_port: 4506
|
|
|
|
# The root directory prepended to these options: pki_dir, cachedir, log_file.
|
|
#root_dir: /
|
|
|
|
# The directory to store the pki information in
|
|
#pki_dir: /etc/salt/pki
|
|
|
|
# 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:
|
|
|
|
# Where cache data goes
|
|
#cachedir: /var/cache/salt
|
|
|
|
|
|
##### Minion module management #####
|
|
##########################################
|
|
# Disable specific modules, this will allow the admin to limit the level os
|
|
# 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: []
|
|
# Enable Cython modules searching and loading. (Default: False)
|
|
#cython_enable: False
|
|
|
|
##### State Management Settings #####
|
|
###########################################
|
|
# The state management system executes all of the state templates on the minion
|
|
# to enable more granular control of system state management. The type of
|
|
# template and serialization used for state management needs to be configured
|
|
# on the minion, the default renderer is yaml_jinja. This is a yaml file
|
|
# rendered from a jinja template, the available options are:
|
|
# yaml_jinja
|
|
# yaml_mako
|
|
# json_jinja
|
|
# json_mako
|
|
#
|
|
#renderer: yaml_jinja
|
|
#
|
|
# Test allows for the state runs to only be test runs
|
|
#test: False
|
|
|
|
###### 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
|
|
|
|
|
|
###### 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
|
|
|
|
###### Logging settings #####
|
|
###########################################
|
|
# The location of the minion log file
|
|
#log_file: /var/log/salt/minion
|
|
# The level of messages to send to the log file.
|
|
# One of 'info', 'quiet', 'critical', 'error', 'debug', 'warning'.
|
|
# Default: 'warning'
|
|
#log_level: warning
|
|
#
|
|
# Logger levels can be used to tweak specific loggers logging levels.
|
|
# Imagine you want to have the salt library at the 'warning' level, but, you
|
|
# still wish to have 'salt.modules' at the 'debug' level:
|
|
# log_granular_levels: {
|
|
# 'salt': 'warning',
|
|
# 'salt.modules': 'debug'
|
|
# }
|
|
#
|
|
#log_granular_levels: {}
|
|
|
|
|
|
###### 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 allied via the yaml dict construct, some examples:
|
|
#
|
|
# 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}
|