summaryrefslogtreecommitdiffstats
path: root/meta-openstack/recipes-support/salt/files/master
diff options
context:
space:
mode:
Diffstat (limited to 'meta-openstack/recipes-support/salt/files/master')
-rw-r--r--meta-openstack/recipes-support/salt/files/master1034
1 files changed, 0 insertions, 1034 deletions
diff --git a/meta-openstack/recipes-support/salt/files/master b/meta-openstack/recipes-support/salt/files/master
deleted file mode 100644
index 4ecb160..0000000
--- a/meta-openstack/recipes-support/salt/files/master
+++ /dev/null
@@ -1,1034 +0,0 @@
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# The port used by the communication interface. The ret (return) port is the
31# interface used for the file server, authentication, job returns, etc.
32#ret_port: 4506
33
34# Specify the location of the daemon process ID file:
35#pidfile: /var/run/salt-master.pid
36
37# The root directory prepended to these options: pki_dir, cachedir,
38# sock_dir, log_file, autosign_file, autoreject_file, extension_modules,
39# key_logfile, pidfile:
40#root_dir: /
41
42# The path to the master's configuration file.
43#conf_file: /etc/salt/master
44
45# Directory used to store public key data:
46#pki_dir: /etc/salt/pki/master
47
48# Key cache. Increases master speed for large numbers of accepted
49# keys. Available options: 'sched'. (Updates on a fixed schedule.)
50# Note that enabling this feature means that minions will not be
51# available to target for up to the length of the maintanence loop
52# which by default is 60s.
53#key_cache: ''
54
55# Directory to store job and cache data:
56# This directory may contain sensitive data and should be protected accordingly.
57#
58#cachedir: /var/cache/salt/master
59
60# Directory for custom modules. This directory can contain subdirectories for
61# each of Salt's module types such as "runners", "output", "wheel", "modules",
62# "states", "returners", etc.
63#extension_modules: <no default>
64
65# Directory for custom modules. This directory can contain subdirectories for
66# each of Salt's module types such as "runners", "output", "wheel", "modules",
67# "states", "returners", "engines", etc.
68# Like 'extension_modules' but can take an array of paths
69#module_dirs: <no default>
70# - /var/cache/salt/minion/extmods
71
72# Verify and set permissions on configuration directories at startup:
73#verify_env: True
74
75# Set the number of hours to keep old job information in the job cache:
76#keep_jobs: 24
77
78# The number of seconds to wait when the client is requesting information
79# about running jobs.
80#gather_job_timeout: 10
81
82# Set the default timeout for the salt command and api. The default is 5
83# seconds.
84#timeout: 5
85
86# The loop_interval option controls the seconds for the master's maintenance
87# process check cycle. This process updates file server backends, cleans the
88# job cache and executes the scheduler.
89#loop_interval: 60
90
91# Set the default outputter used by the salt command. The default is "nested".
92#output: nested
93
94# Set the default output file used by the salt command. Default is to output
95# to the CLI and not to a file. Functions the same way as the "--out-file"
96# CLI option, only sets this to a single file for all salt commands.
97#output_file: None
98
99# Return minions that timeout when running commands like test.ping
100#show_timeout: True
101
102# By default, output is colored. To disable colored output, set the color value
103# to False.
104#color: True
105
106# Do not strip off the colored output from nested results and state outputs
107# (true by default).
108# strip_colors: False
109
110# To display a summary of the number of minions targeted, the number of
111# minions returned, and the number of minions that did not return, set the
112# cli_summary value to True. (False by default.)
113#
114#cli_summary: False
115
116# Set the directory used to hold unix sockets:
117#sock_dir: /var/run/salt/master
118
119# The master can take a while to start up when lspci and/or dmidecode is used
120# to populate the grains for the master. Enable if you want to see GPU hardware
121# data for your master.
122# enable_gpu_grains: False
123
124# The master maintains a job cache. While this is a great addition, it can be
125# a burden on the master for larger deployments (over 5000 minions).
126# Disabling the job cache will make previously executed jobs unavailable to
127# the jobs system and is not generally recommended.
128#job_cache: True
129
130# Cache minion grains and pillar data in the cachedir.
131#minion_data_cache: True
132
133# Store all returns in the given returner.
134# Setting this option requires that any returner-specific configuration also
135# be set. See various returners in salt/returners for details on required
136# configuration values. (See also, event_return_queue below.)
137#
138#event_return: mysql
139
140# On busy systems, enabling event_returns can cause a considerable load on
141# the storage system for returners. Events can be queued on the master and
142# stored in a batched fashion using a single transaction for multiple events.
143# By default, events are not queued.
144#event_return_queue: 0
145
146# Only return events matching tags in a whitelist, supports glob matches.
147#event_return_whitelist:
148# - salt/master/a_tag
149# - salt/run/*/ret
150
151# Store all event returns **except** the tags in a blacklist, supports globs.
152#event_return_blacklist:
153# - salt/master/not_this_tag
154# - salt/wheel/*/ret
155
156# Passing very large events can cause the minion to consume large amounts of
157# memory. This value tunes the maximum size of a message allowed onto the
158# master event bus. The value is expressed in bytes.
159#max_event_size: 1048576
160
161# By default, the master AES key rotates every 24 hours. The next command
162# following a key rotation will trigger a key refresh from the minion which may
163# result in minions which do not respond to the first command after a key refresh.
164#
165# To tell the master to ping all minions immediately after an AES key refresh, set
166# ping_on_rotate to True. This should mitigate the issue where a minion does not
167# appear to initially respond after a key is rotated.
168#
169# Note that ping_on_rotate may cause high load on the master immediately after
170# the key rotation event as minions reconnect. Consider this carefully if this
171# salt master is managing a large number of minions.
172#
173# If disabled, it is recommended to handle this event by listening for the
174# 'aes_key_rotate' event with the 'key' tag and acting appropriately.
175# ping_on_rotate: False
176
177# By default, the master deletes its cache of minion data when the key for that
178# minion is removed. To preserve the cache after key deletion, set
179# 'preserve_minion_cache' to True.
180#
181# WARNING: This may have security implications if compromised minions auth with
182# a previous deleted minion ID.
183#preserve_minion_cache: False
184
185# If max_minions is used in large installations, the master might experience
186# high-load situations because of having to check the number of connected
187# minions for every authentication. This cache provides the minion-ids of
188# all connected minions to all MWorker-processes and greatly improves the
189# performance of max_minions.
190# con_cache: False
191
192# The master can include configuration from other files. To enable this,
193# pass a list of paths to this option. The paths can be either relative or
194# absolute; if relative, they are considered to be relative to the directory
195# the main master configuration file lives in (this file). Paths can make use
196# of shell-style globbing. If no files are matched by a path passed to this
197# option, then the master will log a warning message.
198#
199# Include a config file from some other path:
200# include: /etc/salt/extra_config
201#
202# Include config from several files and directories:
203# include:
204# - /etc/salt/extra_config
205
206
207##### Large-scale tuning settings #####
208##########################################
209# Max open files
210#
211# Each minion connecting to the master uses AT LEAST one file descriptor, the
212# master subscription connection. If enough minions connect you might start
213# seeing on the console (and then salt-master crashes):
214# Too many open files (tcp_listener.cpp:335)
215# Aborted (core dumped)
216#
217# By default this value will be the one of `ulimit -Hn`, ie, the hard limit for
218# max open files.
219#
220# If you wish to set a different value than the default one, uncomment and
221# configure this setting. Remember that this value CANNOT be higher than the
222# hard limit. Raising the hard limit depends on your OS and/or distribution,
223# a good way to find the limit is to search the internet. For example:
224# raise max open files hard limit debian
225#
226#max_open_files: 100000
227
228# The number of worker threads to start. These threads are used to manage
229# return calls made from minions to the master. If the master seems to be
230# running slowly, increase the number of threads. This setting can not be
231# set lower than 3.
232#worker_threads: 5
233
234# Set the ZeroMQ high water marks
235# http://api.zeromq.org/3-2:zmq-setsockopt
236
237# The publisher interface ZeroMQPubServerChannel
238#pub_hwm: 1000
239
240# These two ZMQ HWM settings, salt_event_pub_hwm and event_publisher_pub_hwm
241# are significant for masters with thousands of minions. When these are
242# insufficiently high it will manifest in random responses missing in the CLI
243# and even missing from the job cache. Masters that have fast CPUs and many
244# cores with appropriate worker_threads will not need these set as high.
245
246# On deployment with 8,000 minions, 2.4GHz CPUs, 24 cores, 32GiB memory has
247# these settings:
248#
249# salt_event_pub_hwm: 128000
250# event_publisher_pub_hwm: 64000
251
252# ZMQ high-water-mark for SaltEvent pub socket
253#salt_event_pub_hwm: 20000
254
255# ZMQ high-water-mark for EventPublisher pub socket
256#event_publisher_pub_hwm: 10000
257
258# The master may allocate memory per-event and not
259# reclaim it.
260# To set a high-water mark for memory allocation, use
261# ipc_write_buffer to set a high-water mark for message
262# buffering.
263# Value: In bytes. Set to 'dynamic' to have Salt select
264# a value for you. Default is disabled.
265# ipc_write_buffer: 'dynamic'
266
267
268##### Security settings #####
269##########################################
270# Enable "open mode", this mode still maintains encryption, but turns off
271# authentication, this is only intended for highly secure environments or for
272# the situation where your keys end up in a bad state. If you run in open mode
273# you do so at your own risk!
274#open_mode: False
275
276# Enable auto_accept, this setting will automatically accept all incoming
277# public keys from the minions. Note that this is insecure.
278#auto_accept: False
279
280# Time in minutes that an incoming public key with a matching name found in
281# pki_dir/minion_autosign/keyid is automatically accepted. Expired autosign keys
282# are removed when the master checks the minion_autosign directory.
283# 0 equals no timeout
284# autosign_timeout: 120
285
286# If the autosign_file is specified, incoming keys specified in the
287# autosign_file will be automatically accepted. This is insecure. Regular
288# expressions as well as globing lines are supported.
289#autosign_file: /etc/salt/autosign.conf
290
291# Works like autosign_file, but instead allows you to specify minion IDs for
292# which keys will automatically be rejected. Will override both membership in
293# the autosign_file and the auto_accept setting.
294#autoreject_file: /etc/salt/autoreject.conf
295
296# Enable permissive access to the salt keys. This allows you to run the
297# master or minion as root, but have a non-root group be given access to
298# your pki_dir. To make the access explicit, root must belong to the group
299# you've given access to. This is potentially quite insecure. If an autosign_file
300# is specified, enabling permissive_pki_access will allow group access to that
301# specific file.
302#permissive_pki_access: False
303
304# Allow users on the master access to execute specific commands on minions.
305# This setting should be treated with care since it opens up execution
306# capabilities to non root users. By default this capability is completely
307# disabled.
308#publisher_acl:
309# larry:
310# - test.ping
311# - network.*
312#
313# Blacklist any of the following users or modules
314#
315# This example would blacklist all non sudo users, including root from
316# running any commands. It would also blacklist any use of the "cmd"
317# module. This is completely disabled by default.
318#
319#
320# Check the list of configured users in client ACL against users on the
321# system and throw errors if they do not exist.
322#client_acl_verify: True
323#
324#publisher_acl_blacklist:
325# users:
326# - root
327# - '^(?!sudo_).*$' # all non sudo users
328# modules:
329# - cmd
330#
331# WARNING: client_acl and client_acl_blacklist options are deprecated and will
332# be removed in the future releases. Use publisher_acl and
333# publisher_acl_blacklist instead.
334
335# Enforce publisher_acl & publisher_acl_blacklist when users have sudo
336# access to the salt command.
337#
338#sudo_acl: False
339
340# The external auth system uses the Salt auth modules to authenticate and
341# validate users to access areas of the Salt system.
342#external_auth:
343# pam:
344# fred:
345# - test.*
346#
347# Time (in seconds) for a newly generated token to live. Default: 12 hours
348#token_expire: 43200
349#
350# Allow eauth users to specify the expiry time of the tokens they generate.
351# A boolean applies to all users or a dictionary of whitelisted eauth backends
352# and usernames may be given.
353# token_expire_user_override:
354# pam:
355# - fred
356# - tom
357# ldap:
358# - gary
359#
360#token_expire_user_override: False
361
362# Allow minions to push files to the master. This is disabled by default, for
363# security purposes.
364#file_recv: False
365
366# Set a hard-limit on the size of the files that can be pushed to the master.
367# It will be interpreted as megabytes. Default: 100
368#file_recv_max_size: 100
369
370# Signature verification on messages published from the master.
371# This causes the master to cryptographically sign all messages published to its event
372# bus, and minions then verify that signature before acting on the message.
373#
374# This is False by default.
375#
376# Note that to facilitate interoperability with masters and minions that are different
377# versions, if sign_pub_messages is True but a message is received by a minion with
378# no signature, it will still be accepted, and a warning message will be logged.
379# Conversely, if sign_pub_messages is False, but a minion receives a signed
380# message it will be accepted, the signature will not be checked, and a warning message
381# will be logged. This behavior went away in Salt 2014.1.0 and these two situations
382# will cause minion to throw an exception and drop the message.
383# sign_pub_messages: False
384
385##### Salt-SSH Configuration #####
386##########################################
387
388# Pass in an alternative location for the salt-ssh roster file
389#roster_file: /etc/salt/roster
390
391# Pass in minion option overrides that will be inserted into the SHIM for
392# salt-ssh calls. The local minion config is not used for salt-ssh. Can be
393# overridden on a per-minion basis in the roster (`minion_opts`)
394#ssh_minion_opts:
395# gpg_keydir: /root/gpg
396
397# Set this to True to default to using ~/.ssh/id_rsa for salt-ssh
398# authentication with minions
399#ssh_use_home_key: False
400
401##### Master Module Management #####
402##########################################
403# Manage how master side modules are loaded.
404
405# Add any additional locations to look for master runners:
406#runner_dirs: []
407
408# Enable Cython for master side modules:
409#cython_enable: False
410
411
412##### State System settings #####
413##########################################
414# The state system uses a "top" file to tell the minions what environment to
415# use and what modules to use. The state_top file is defined relative to the
416# root of the base environment as defined in "File Server settings" below.
417#state_top: top.sls
418
419# The master_tops option replaces the external_nodes option by creating
420# a plugable system for the generation of external top data. The external_nodes
421# option is deprecated by the master_tops option.
422#
423# To gain the capabilities of the classic external_nodes system, use the
424# following configuration:
425# master_tops:
426# ext_nodes: <Shell command which returns yaml>
427#
428#master_tops: {}
429
430# The external_nodes option allows Salt to gather data that would normally be
431# placed in a top file. The external_nodes option is the executable that will
432# return the ENC data. Remember that Salt will look for external nodes AND top
433# files and combine the results if both are enabled!
434#external_nodes: None
435
436# The renderer to use on the minions to render the state data
437#renderer: yaml_jinja
438
439# The Jinja renderer can strip extra carriage returns and whitespace
440# See http://jinja.pocoo.org/docs/api/#high-level-api
441#
442# If this is set to True the first newline after a Jinja block is removed
443# (block, not variable tag!). Defaults to False, corresponds to the Jinja
444# environment init variable "trim_blocks".
445#jinja_trim_blocks: False
446#
447# If this is set to True leading spaces and tabs are stripped from the start
448# of a line to a block. Defaults to False, corresponds to the Jinja
449# environment init variable "lstrip_blocks".
450#jinja_lstrip_blocks: False
451
452# The failhard option tells the minions to stop immediately after the first
453# failure detected in the state execution, defaults to False
454#failhard: False
455
456# The state_verbose and state_output settings can be used to change the way
457# state system data is printed to the display. By default all data is printed.
458# The state_verbose setting can be set to True or False, when set to False
459# all data that has a result of True and no changes will be suppressed.
460#state_verbose: True
461
462# The state_output setting changes if the output is the full multi line
463# output for each changed state if set to 'full', but if set to 'terse'
464# the output will be shortened to a single line. If set to 'mixed', the output
465# will be terse unless a state failed, in which case that output will be full.
466# If set to 'changes', the output will be full unless the state didn't change.
467#state_output: full
468
469# Automatically aggregate all states that have support for mod_aggregate by
470# setting to 'True'. Or pass a list of state module names to automatically
471# aggregate just those types.
472#
473# state_aggregate:
474# - pkg
475#
476#state_aggregate: False
477
478# Send progress events as each function in a state run completes execution
479# by setting to 'True'. Progress events are in the format
480# 'salt/job/<JID>/prog/<MID>/<RUN NUM>'.
481#state_events: False
482
483##### File Server settings #####
484##########################################
485# Salt runs a lightweight file server written in zeromq to deliver files to
486# minions. This file server is built into the master daemon and does not
487# require a dedicated port.
488
489# The file server works on environments passed to the master, each environment
490# can have multiple root directories, the subdirectories in the multiple file
491# roots cannot match, otherwise the downloaded files will not be able to be
492# reliably ensured. A base environment is required to house the top file.
493# Example:
494# file_roots:
495# base:
496# - /srv/salt/
497# dev:
498# - /srv/salt/dev/services
499# - /srv/salt/dev/states
500# prod:
501# - /srv/salt/prod/services
502# - /srv/salt/prod/states
503#
504#file_roots:
505# base:
506# - /srv/salt
507#
508
509# When using multiple environments, each with their own top file, the
510# default behaviour is an unordered merge. To prevent top files from
511# being merged together and instead to only use the top file from the
512# requested environment, set this value to 'same'.
513#top_file_merging_strategy: merge
514
515# To specify the order in which environments are merged, set the ordering
516# in the env_order option. Given a conflict, the last matching value will
517# win.
518#env_order: ['base', 'dev', 'prod']
519
520# If top_file_merging_strategy is set to 'same' and an environment does not
521# contain a top file, the top file in the environment specified by default_top
522# will be used instead.
523#default_top: base
524
525# The hash_type is the hash to use when discovering the hash of a file on
526# the master server. The default is md5 but sha1, sha224, sha256, sha384
527# and sha512 are also supported.
528#
529# WARNING: While md5 is also supported, do not use it due to the high chance
530# of possible collisions and thus security breach.
531#
532# Prior to changing this value, the master should be stopped and all Salt
533# caches should be cleared.
534#hash_type: sha256
535
536# The buffer size in the file server can be adjusted here:
537#file_buffer_size: 1048576
538
539# A regular expression (or a list of expressions) that will be matched
540# against the file path before syncing the modules and states to the minions.
541# This includes files affected by the file.recurse state.
542# For example, if you manage your custom modules and states in subversion
543# and don't want all the '.svn' folders and content synced to your minions,
544# you could set this to '/\.svn($|/)'. By default nothing is ignored.
545#file_ignore_regex:
546# - '/\.svn($|/)'
547# - '/\.git($|/)'
548
549# A file glob (or list of file globs) that will be matched against the file
550# path before syncing the modules and states to the minions. This is similar
551# to file_ignore_regex above, but works on globs instead of regex. By default
552# nothing is ignored.
553# file_ignore_glob:
554# - '*.pyc'
555# - '*/somefolder/*.bak'
556# - '*.swp'
557
558# File Server Backend
559#
560# Salt supports a modular fileserver backend system, this system allows
561# the salt master to link directly to third party systems to gather and
562# manage the files available to minions. Multiple backends can be
563# configured and will be searched for the requested file in the order in which
564# they are defined here. The default setting only enables the standard backend
565# "roots" which uses the "file_roots" option.
566#fileserver_backend:
567# - roots
568#
569# To use multiple backends list them in the order they are searched:
570#fileserver_backend:
571# - git
572# - roots
573#
574# Uncomment the line below if you do not want the file_server to follow
575# symlinks when walking the filesystem tree. This is set to True
576# by default. Currently this only applies to the default roots
577# fileserver_backend.
578#fileserver_followsymlinks: False
579#
580# Uncomment the line below if you do not want symlinks to be
581# treated as the files they are pointing to. By default this is set to
582# False. By uncommenting the line below, any detected symlink while listing
583# files on the Master will not be returned to the Minion.
584#fileserver_ignoresymlinks: True
585#
586# By default, the Salt fileserver recurses fully into all defined environments
587# to attempt to find files. To limit this behavior so that the fileserver only
588# traverses directories with SLS files and special Salt directories like _modules,
589# enable the option below. This might be useful for installations where a file root
590# has a very large number of files and performance is impacted. Default is False.
591# fileserver_limit_traversal: False
592#
593# The fileserver can fire events off every time the fileserver is updated,
594# these are disabled by default, but can be easily turned on by setting this
595# flag to True
596#fileserver_events: False
597
598# Git File Server Backend Configuration
599#
600# Optional parameter used to specify the provider to be used for gitfs. Must
601# be one of the following: pygit2, gitpython, or dulwich. If unset, then each
602# will be tried in that same order, and the first one with a compatible
603# version installed will be the provider that is used.
604#gitfs_provider: pygit2
605
606# Along with gitfs_password, is used to authenticate to HTTPS remotes.
607# gitfs_user: ''
608
609# Along with gitfs_user, is used to authenticate to HTTPS remotes.
610# This parameter is not required if the repository does not use authentication.
611#gitfs_password: ''
612
613# By default, Salt will not authenticate to an HTTP (non-HTTPS) remote.
614# This parameter enables authentication over HTTP. Enable this at your own risk.
615#gitfs_insecure_auth: False
616
617# Along with gitfs_privkey (and optionally gitfs_passphrase), is used to
618# authenticate to SSH remotes. This parameter (or its per-remote counterpart)
619# is required for SSH remotes.
620#gitfs_pubkey: ''
621
622# Along with gitfs_pubkey (and optionally gitfs_passphrase), is used to
623# authenticate to SSH remotes. This parameter (or its per-remote counterpart)
624# is required for SSH remotes.
625#gitfs_privkey: ''
626
627# This parameter is optional, required only when the SSH key being used to
628# authenticate is protected by a passphrase.
629#gitfs_passphrase: ''
630
631# When using the git fileserver backend at least one git remote needs to be
632# defined. The user running the salt master will need read access to the repo.
633#
634# The repos will be searched in order to find the file requested by a client
635# and the first repo to have the file will return it.
636# When using the git backend branches and tags are translated into salt
637# environments.
638# Note: file:// repos will be treated as a remote, so refs you want used must
639# exist in that repo as *local* refs.
640#gitfs_remotes:
641# - git://github.com/saltstack/salt-states.git
642# - file:///var/git/saltmaster
643#
644# The gitfs_ssl_verify option specifies whether to ignore ssl certificate
645# errors when contacting the gitfs backend. You might want to set this to
646# false if you're using a git backend that uses a self-signed certificate but
647# keep in mind that setting this flag to anything other than the default of True
648# is a security concern, you may want to try using the ssh transport.
649#gitfs_ssl_verify: True
650#
651# The gitfs_root option gives the ability to serve files from a subdirectory
652# within the repository. The path is defined relative to the root of the
653# repository and defaults to the repository root.
654#gitfs_root: somefolder/otherfolder
655#
656#
657##### Pillar settings #####
658##########################################
659# Salt Pillars allow for the building of global data that can be made selectively
660# available to different minions based on minion grain filtering. The Salt
661# Pillar is laid out in the same fashion as the file server, with environments,
662# a top file and sls files. However, pillar data does not need to be in the
663# highstate format, and is generally just key/value pairs.
664#pillar_roots:
665# base:
666# - /srv/pillar
667#
668#ext_pillar:
669# - hiera: /etc/hiera.yaml
670# - cmd_yaml: cat /etc/salt/yaml
671
672# The ext_pillar_first option allows for external pillar sources to populate
673# before file system pillar. This allows for targeting file system pillar from
674# ext_pillar.
675#ext_pillar_first: False
676
677# The pillar_gitfs_ssl_verify option specifies whether to ignore ssl certificate
678# errors when contacting the pillar gitfs backend. You might want to set this to
679# false if you're using a git backend that uses a self-signed certificate but
680# keep in mind that setting this flag to anything other than the default of True
681# is a security concern, you may want to try using the ssh transport.
682#pillar_gitfs_ssl_verify: True
683
684# The pillar_opts option adds the master configuration file data to a dict in
685# the pillar called "master". This is used to set simple configurations in the
686# master config file that can then be used on minions.
687#pillar_opts: False
688
689# The pillar_safe_render_error option prevents the master from passing pillar
690# render errors to the minion. This is set on by default because the error could
691# contain templating data which would give that minion information it shouldn't
692# have, like a password! When set true the error message will only show:
693# Rendering SLS 'my.sls' failed. Please see master log for details.
694#pillar_safe_render_error: True
695
696# The pillar_source_merging_strategy option allows you to configure merging strategy
697# between different sources. It accepts five values: none, recurse, aggregate, overwrite,
698# or smart. None will not do any merging at all. Recurse will merge recursively mapping of data.
699# Aggregate instructs aggregation of elements between sources that use the #!yamlex renderer. Overwrite
700# will overwrite elements according the order in which they are processed. This is
701# behavior of the 2014.1 branch and earlier. Smart guesses the best strategy based
702# on the "renderer" setting and is the default value.
703#pillar_source_merging_strategy: smart
704
705# Recursively merge lists by aggregating them instead of replacing them.
706#pillar_merge_lists: False
707
708# Set this option to 'True' to force a 'KeyError' to be raised whenever an
709# attempt to retrieve a named value from pillar fails. When this option is set
710# to 'False', the failed attempt returns an empty string. Default is 'False'.
711#pillar_raise_on_missing: False
712
713# Git External Pillar (git_pillar) Configuration Options
714#
715# Specify the provider to be used for git_pillar. Must be either pygit2 or
716# gitpython. If unset, then both will be tried in that same order, and the
717# first one with a compatible version installed will be the provider that
718# is used.
719#git_pillar_provider: pygit2
720
721# If the desired branch matches this value, and the environment is omitted
722# from the git_pillar configuration, then the environment for that git_pillar
723# remote will be base.
724#git_pillar_base: master
725
726# If the branch is omitted from a git_pillar remote, then this branch will
727# be used instead
728#git_pillar_branch: master
729
730# Environment to use for git_pillar remotes. This is normally derived from
731# the branch/tag (or from a per-remote env parameter), but if set this will
732# override the process of deriving the env from the branch/tag name.
733#git_pillar_env: ''
734
735# Path relative to the root of the repository where the git_pillar top file
736# and SLS files are located.
737#git_pillar_root: ''
738
739# Specifies whether or not to ignore SSL certificate errors when contacting
740# the remote repository.
741#git_pillar_ssl_verify: False
742
743# When set to False, if there is an update/checkout lock for a git_pillar
744# remote and the pid written to it is not running on the master, the lock
745# file will be automatically cleared and a new lock will be obtained.
746#git_pillar_global_lock: True
747
748# Git External Pillar Authentication Options
749#
750# Along with git_pillar_password, is used to authenticate to HTTPS remotes.
751#git_pillar_user: ''
752
753# Along with git_pillar_user, is used to authenticate to HTTPS remotes.
754# This parameter is not required if the repository does not use authentication.
755#git_pillar_password: ''
756
757# By default, Salt will not authenticate to an HTTP (non-HTTPS) remote.
758# This parameter enables authentication over HTTP.
759#git_pillar_insecure_auth: False
760
761# Along with git_pillar_privkey (and optionally git_pillar_passphrase),
762# is used to authenticate to SSH remotes.
763#git_pillar_pubkey: ''
764
765# Along with git_pillar_pubkey (and optionally git_pillar_passphrase),
766# is used to authenticate to SSH remotes.
767#git_pillar_privkey: ''
768
769# This parameter is optional, required only when the SSH key being used
770# to authenticate is protected by a passphrase.
771#git_pillar_passphrase: ''
772
773# A master can cache pillars locally to bypass the expense of having to render them
774# for each minion on every request. This feature should only be enabled in cases
775# where pillar rendering time is known to be unsatisfactory and any attendant security
776# concerns about storing pillars in a master cache have been addressed.
777#
778# When enabling this feature, be certain to read through the additional ``pillar_cache_*``
779# configuration options to fully understand the tunable parameters and their implications.
780#
781# Note: setting ``pillar_cache: True`` has no effect on targeting Minions with Pillars.
782# See https://docs.saltstack.com/en/latest/topics/targeting/pillar.html
783#pillar_cache: False
784
785# If and only if a master has set ``pillar_cache: True``, the cache TTL controls the amount
786# of time, in seconds, before the cache is considered invalid by a master and a fresh
787# pillar is recompiled and stored.
788#pillar_cache_ttl: 3600
789
790# If and only if a master has set `pillar_cache: True`, one of several storage providers
791# can be utililzed.
792#
793# `disk`: The default storage backend. This caches rendered pillars to the master cache.
794# Rendered pillars are serialized and deserialized as msgpack structures for speed.
795# Note that pillars are stored UNENCRYPTED. Ensure that the master cache
796# has permissions set appropriately. (Same defaults are provided.)
797#
798# memory: [EXPERIMENTAL] An optional backend for pillar caches which uses a pure-Python
799# in-memory data structure for maximal performance. There are several caveats,
800# however. First, because each master worker contains its own in-memory cache,
801# there is no guarantee of cache consistency between minion requests. This
802# works best in situations where the pillar rarely if ever changes. Secondly,
803# and perhaps more importantly, this means that unencrypted pillars will
804# be accessible to any process which can examine the memory of the ``salt-master``!
805# This may represent a substantial security risk.
806#
807#pillar_cache_backend: disk
808
809
810##### Syndic settings #####
811##########################################
812# The Salt syndic is used to pass commands through a master from a higher
813# master. Using the syndic is simple. If this is a master that will have
814# syndic servers(s) below it, then set the "order_masters" setting to True.
815#
816# If this is a master that will be running a syndic daemon for passthrough, then
817# the "syndic_master" setting needs to be set to the location of the master server
818# to receive commands from.
819
820# Set the order_masters setting to True if this master will command lower
821# masters' syndic interfaces.
822#order_masters: False
823
824# If this master will be running a salt syndic daemon, syndic_master tells
825# this master where to receive commands from.
826#syndic_master: masterofmaster
827
828# This is the 'ret_port' of the MasterOfMaster:
829#syndic_master_port: 4506
830
831# PID file of the syndic daemon:
832#syndic_pidfile: /var/run/salt-syndic.pid
833
834# LOG file of the syndic daemon:
835#syndic_log_file: syndic.log
836
837# The behaviour of the multi-syndic when connection to a master of masters failed.
838# Can specify ``random`` (default) or ``ordered``. If set to ``random``, masters
839# will be iterated in random order. If ``ordered`` is specified, the configured
840# order will be used.
841#syndic_failover: random
842
843
844##### Peer Publish settings #####
845##########################################
846# Salt minions can send commands to other minions, but only if the minion is
847# allowed to. By default "Peer Publication" is disabled, and when enabled it
848# is enabled for specific minions and specific commands. This allows secure
849# compartmentalization of commands based on individual minions.
850
851# The configuration uses regular expressions to match minions and then a list
852# of regular expressions to match functions. The following will allow the
853# minion authenticated as foo.example.com to execute functions from the test
854# and pkg modules.
855#peer:
856# foo.example.com:
857# - test.*
858# - pkg.*
859#
860# This will allow all minions to execute all commands:
861#peer:
862# .*:
863# - .*
864#
865# This is not recommended, since it would allow anyone who gets root on any
866# single minion to instantly have root on all of the minions!
867
868# Minions can also be allowed to execute runners from the salt master.
869# Since executing a runner from the minion could be considered a security risk,
870# it needs to be enabled. This setting functions just like the peer setting
871# except that it opens up runners instead of module functions.
872#
873# All peer runner support is turned off by default and must be enabled before
874# using. This will enable all peer runners for all minions:
875#peer_run:
876# .*:
877# - .*
878#
879# To enable just the manage.up runner for the minion foo.example.com:
880#peer_run:
881# foo.example.com:
882# - manage.up
883#
884#
885##### Mine settings #####
886#####################################
887# Restrict mine.get access from minions. By default any minion has a full access
888# to get all mine data from master cache. In acl definion below, only pcre matches
889# are allowed.
890# mine_get:
891# .*:
892# - .*
893#
894# The example below enables minion foo.example.com to get 'network.interfaces' mine
895# data only, minions web* to get all network.* and disk.* mine data and all other
896# minions won't get any mine data.
897# mine_get:
898# foo.example.com:
899# - network.interfaces
900# web.*:
901# - network.*
902# - disk.*
903
904
905##### Logging settings #####
906##########################################
907# The location of the master log file
908# The master log can be sent to a regular file, local path name, or network
909# location. Remote logging works best when configured to use rsyslogd(8) (e.g.:
910# ``file:///dev/log``), with rsyslogd(8) configured for network logging. The URI
911# format is: <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>
912#log_file: /var/log/salt/master
913#log_file: file:///dev/log
914#log_file: udp://loghost:10514
915
916#log_file: /var/log/salt/master
917#key_logfile: /var/log/salt/key
918
919# The level of messages to send to the console.
920# One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
921#
922# The following log levels are considered INSECURE and may log sensitive data:
923# ['garbage', 'trace', 'debug']
924#
925#log_level: warning
926
927# The level of messages to send to the log file.
928# One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
929# If using 'log_granular_levels' this must be set to the highest desired level.
930#log_level_logfile: warning
931
932# The date and time format used in log messages. Allowed date/time formatting
933# can be seen here: http://docs.python.org/library/time.html#time.strftime
934#log_datefmt: '%H:%M:%S'
935#log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'
936
937# The format of the console logging messages. Allowed formatting options can
938# be seen here: http://docs.python.org/library/logging.html#logrecord-attributes
939#
940# Console log colors are specified by these additional formatters:
941#
942# %(colorlevel)s
943# %(colorname)s
944# %(colorprocess)s
945# %(colormsg)s
946#
947# Since it is desirable to include the surrounding brackets, '[' and ']', in
948# the coloring of the messages, these color formatters also include padding as
949# well. Color LogRecord attributes are only available for console logging.
950#
951#log_fmt_console: '%(colorlevel)s %(colormsg)s'
952#log_fmt_console: '[%(levelname)-8s] %(message)s'
953#
954#log_fmt_logfile: '%(asctime)s,%(msecs)03d [%(name)-17s][%(levelname)-8s] %(message)s'
955
956# This can be used to control logging levels more specificically. This
957# example sets the main salt library at the 'warning' level, but sets
958# 'salt.modules' to log at the 'debug' level:
959# log_granular_levels:
960# 'salt': 'warning'
961# 'salt.modules': 'debug'
962#
963#log_granular_levels: {}
964
965
966##### Node Groups ######
967##########################################
968# Node groups allow for logical groupings of minion nodes. A group consists of
969# a group name and a compound target. Nodgroups can reference other nodegroups
970# with 'N@' classifier. Ensure that you do not have circular references.
971#
972#nodegroups:
973# group1: 'L@foo.domain.com,bar.domain.com,baz.domain.com or bl*.domain.com'
974# group2: 'G@os:Debian and foo.domain.com'
975# group3: 'G@os:Debian and N@group1'
976# group4:
977# - 'G@foo:bar'
978# - 'or'
979# - 'G@foo:baz'
980
981
982##### Range Cluster settings #####
983##########################################
984# The range server (and optional port) that serves your cluster information
985# https://github.com/ytoolshed/range/wiki/%22yamlfile%22-module-file-spec
986#
987#range_server: range:80
988
989
990##### Windows Software Repo settings #####
991###########################################
992# Location of the repo on the master:
993#winrepo_dir_ng: '/srv/salt/win/repo-ng'
994#
995# List of git repositories to include with the local repo:
996#winrepo_remotes_ng:
997# - 'https://github.com/saltstack/salt-winrepo-ng.git'
998
999
1000##### Windows Software Repo settings - Pre 2015.8 #####
1001########################################################
1002# Legacy repo settings for pre-2015.8 Windows minions.
1003#
1004# Location of the repo on the master:
1005#winrepo_dir: '/srv/salt/win/repo'
1006#
1007# Location of the master's repo cache file:
1008#winrepo_mastercachefile: '/srv/salt/win/repo/winrepo.p'
1009#
1010# List of git repositories to include with the local repo:
1011#winrepo_remotes:
1012# - 'https://github.com/saltstack/salt-winrepo.git'
1013
1014
1015##### Returner settings ######
1016############################################
1017# Which returner(s) will be used for minion's result:
1018#return: mysql
1019
1020
1021###### Miscellaneous settings ######
1022############################################
1023# Default match type for filtering events tags: startswith, endswith, find, regex, fnmatch
1024#event_match_type: startswith
1025
1026# Save runner returns to the job cache
1027#runner_returns: True
1028
1029# Permanently include any available Python 3rd party modules into Salt Thin
1030# when they are generated for Salt-SSH or other purposes.
1031# The modules should be named by the names they are actually imported inside the Python.
1032# The value of the parameters can be either one module or a comma separated list of them.
1033#thin_extra_mods: foo,bar
1034