2012-01-16 19:36:39 +00:00
|
|
|
# DO NOT MODIFY THIS FILE. Copy it to: /etc/salt/minion
|
2011-03-29 05:10:49 +00:00
|
|
|
##### Primary configuration settings #####
|
|
|
|
##########################################
|
|
|
|
# Set the location of the salt master server, if the master server cannot be
|
2012-02-04 05:10:29 +00:00
|
|
|
# resolved, then the minion will fail to start.
|
2011-05-20 02:45:18 +00:00
|
|
|
#master: salt
|
2011-03-29 05:10:49 +00:00
|
|
|
|
2012-01-30 14:55:02 +00:00
|
|
|
# Set the port used by the master reply and authentication server
|
2011-03-05 03:27:32 +00:00
|
|
|
#master_port: 4506
|
2011-03-29 05:10:49 +00:00
|
|
|
|
2012-01-18 20:29:38 +00:00
|
|
|
# The user to run salt
|
|
|
|
#user: root
|
|
|
|
|
2011-06-21 01:29:26 +00:00
|
|
|
# The root directory prepended to these options: pki_dir, cachedir, log_file.
|
|
|
|
#root_dir: /
|
|
|
|
|
2011-03-05 03:27:32 +00:00
|
|
|
# The directory to store the pki information in
|
|
|
|
#pki_dir: /etc/salt/pki
|
2011-03-29 05:10:49 +00:00
|
|
|
|
2011-04-12 19:56:03 +00:00
|
|
|
# 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()
|
2011-05-26 10:22:37 +00:00
|
|
|
# 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
|
2011-04-12 19:56:03 +00:00
|
|
|
# clusters.
|
|
|
|
#id:
|
2011-03-29 05:10:49 +00:00
|
|
|
|
2012-02-04 05:10:29 +00:00
|
|
|
# If the the connection to the server is interrupted, the minion will
|
|
|
|
# attempt to reconnect. sub_timeout allows you to control the rate
|
|
|
|
# of reconnection attempts (in seconds). To disable reconnects, set
|
|
|
|
# this value to 0.
|
2011-10-25 04:48:55 +00:00
|
|
|
#sub_timeout: 60
|
|
|
|
|
2011-03-29 05:10:49 +00:00
|
|
|
# Where cache data goes
|
2011-03-05 03:27:32 +00:00
|
|
|
#cachedir: /var/cache/salt
|
2011-03-29 05:10:49 +00:00
|
|
|
|
2012-01-18 06:59:01 +00:00
|
|
|
# The minion can locally cache the return data from jobs sent to it, this
|
2012-02-04 05:10:29 +00:00
|
|
|
# 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
|
2012-01-18 06:59:01 +00:00
|
|
|
#cache_jobs: False
|
|
|
|
|
2012-01-13 22:29:24 +00:00
|
|
|
# When waiting for a master to accept the minion's public key, salt will
|
2012-01-18 06:59:01 +00:00
|
|
|
# continuously attempt to reconnect until successful. This is the time, in
|
2012-01-13 22:29:24 +00:00
|
|
|
# seconds, between those reconnection attempts.
|
2012-01-18 06:59:01 +00:00
|
|
|
#acceptance_wait_time = 10
|
2012-01-13 22:29:24 +00:00
|
|
|
|
2012-03-01 17:24:19 +00:00
|
|
|
# When healing a dns_check is run, this is to make sure that the originally
|
|
|
|
# resolved dns has not changed, if this is something that does not happen in
|
|
|
|
# your environment then set this value to False.
|
|
|
|
#dns_check: True
|
2012-01-13 22:29:24 +00:00
|
|
|
|
|
|
|
|
2011-03-29 05:10:49 +00:00
|
|
|
##### Minion module management #####
|
|
|
|
##########################################
|
2012-02-04 05:10:29 +00:00
|
|
|
# Disable specific modules. This allows the admin to limit the level of
|
2011-03-15 04:28:30 +00:00
|
|
|
# access the master has to the minion
|
|
|
|
#disable_modules: [cmd,test]
|
2011-05-14 04:07:27 +00:00
|
|
|
#disable_returners: []
|
2012-02-04 05:10:29 +00:00
|
|
|
#
|
|
|
|
# Modules can be loaded from arbitrary paths. This enables the easy deployment
|
|
|
|
# of third party modules. Modules for returners and minions can be loaded.
|
2011-04-22 14:52:55 +00:00
|
|
|
# Specify a list of extra directories to search for minion modules and
|
|
|
|
# returners. These paths must be fully qualified!
|
|
|
|
#module_dirs: []
|
|
|
|
#returner_dirs: []
|
2011-05-10 20:14:10 +00:00
|
|
|
#states_dirs: []
|
|
|
|
#render_dirs: []
|
2012-02-04 05:10:29 +00:00
|
|
|
#
|
2011-09-14 23:14:56 +00:00
|
|
|
# Enable Cython modules searching and loading. (Default: False)
|
|
|
|
#cython_enable: False
|
2011-03-29 05:10:49 +00:00
|
|
|
|
2011-05-17 04:37:54 +00:00
|
|
|
##### 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
|
2011-05-23 03:06:26 +00:00
|
|
|
#
|
2011-12-10 07:15:57 +00:00
|
|
|
# state_verbose allows for the data returned from the minion to be more
|
|
|
|
# verbose. Normaly only states that fail or states that have changes are
|
|
|
|
# returned, but setting state_verbose to True will return all states that
|
|
|
|
# were checked
|
|
|
|
#state_verbose: False
|
2012-01-13 22:29:24 +00:00
|
|
|
#
|
|
|
|
# autoload_dynamic_modules Turns on automatic loading of modules found in the
|
|
|
|
# environments on the master. This is turned on by default, to turn of
|
|
|
|
# autoloading modules when states run set this value to False
|
|
|
|
#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
|
2012-02-01 05:21:06 +00:00
|
|
|
#
|
|
|
|
# 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 issolate via the top file.
|
|
|
|
#environment: None
|
2011-05-17 04:37:54 +00:00
|
|
|
|
2012-03-05 04:59:39 +00:00
|
|
|
##### 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
|
|
|
|
# coppied 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.
|
|
|
|
#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
|
|
|
|
#
|
|
|
|
# Default:
|
|
|
|
#file_roots:
|
|
|
|
# base:
|
|
|
|
# - /srv/salt
|
|
|
|
|
|
|
|
# The hash_type is the hash to use when discovering the hash of a file in
|
|
|
|
# the minion directory, the default is md5, but sha1, sha224, sha256, sha384
|
|
|
|
# and sha512 are also supported.
|
|
|
|
#hash_type: md5
|
|
|
|
|
2011-03-29 05:10:49 +00:00
|
|
|
###### Security settings #####
|
|
|
|
###########################################
|
2011-03-10 15:55:48 +00:00
|
|
|
# Enable "open mode", this mode still maintains encryption, but turns off
|
|
|
|
# authentication, this is only intended for highly secure environments or for
|
2011-03-29 05:10:49 +00:00
|
|
|
# the situation where your keys end up in a bad state. If you run in open mode
|
2011-03-10 15:55:48 +00:00
|
|
|
# you do so at your own risk!
|
|
|
|
#open_mode: False
|
2011-03-29 05:10:49 +00:00
|
|
|
|
|
|
|
|
2011-04-11 16:46:26 +00:00
|
|
|
###### Thread settings #####
|
|
|
|
###########################################
|
2011-07-30 02:54:55 +00:00
|
|
|
# Disable multiprocessing support, by default when a minion receives a
|
|
|
|
# publication a new process is spawned and the command is executed therein.
|
|
|
|
#multiprocessing: True
|
2011-04-11 16:46:26 +00:00
|
|
|
|
2011-03-29 05:10:49 +00:00
|
|
|
###### Logging settings #####
|
|
|
|
###########################################
|
2011-05-26 10:22:37 +00:00
|
|
|
# The location of the minion log file
|
2011-03-29 05:10:49 +00:00
|
|
|
#log_file: /var/log/salt/minion
|
2012-02-04 05:10:29 +00:00
|
|
|
#
|
2011-05-26 10:22:37 +00:00
|
|
|
# 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.
|
2012-02-04 05:10:29 +00:00
|
|
|
# For example, if you want to have the salt library at the 'warning' level,
|
|
|
|
# but you still wish to have 'salt.modules' at the 'debug' level:
|
2011-05-26 10:22:37 +00:00
|
|
|
# log_granular_levels: {
|
|
|
|
# 'salt': 'warning',
|
|
|
|
# 'salt.modules': 'debug'
|
|
|
|
# }
|
|
|
|
#
|
|
|
|
#log_granular_levels: {}
|
2011-03-25 03:53:47 +00:00
|
|
|
|
2011-04-07 17:33:48 +00:00
|
|
|
###### Module configuration #####
|
|
|
|
###########################################
|
2011-05-26 10:22:37 +00:00
|
|
|
# Salt allows for modules to be passed arbitrary configuration data, any data
|
2011-04-07 17:33:48 +00:00
|
|
|
# passed here in valid yaml format will be passed on to the salt minion modules
|
2011-05-26 10:22:37 +00:00
|
|
|
# for use. It is STRONGLY recommended that a naming convention be used in which
|
2011-04-07 17:33:48 +00:00
|
|
|
# the module name is followed by a . and then the value. Also, all top level
|
2012-02-04 05:10:29 +00:00
|
|
|
# data must be applied via the yaml dict construct, some examples:
|
2011-04-07 17:33:48 +00:00
|
|
|
#
|
|
|
|
# A simple value for the test module:
|
|
|
|
#test.foo: foo
|
|
|
|
#
|
|
|
|
# A list for the test module:
|
|
|
|
#test.bar: [baz,quo]
|
|
|
|
#
|
2011-05-26 10:22:37 +00:00
|
|
|
# A dict for the test module:
|
2011-04-07 17:33:48 +00:00
|
|
|
#test.baz: {spam: sausage, cheese: bread}
|