saltstack/salt
1
0
Fork 0
mirror of https://github.com/saltstack/salt.git synced 2025-04-17 10:10:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Merge branch 'develop' of https://github.com/makearl/salt into issue-28796-beacon-config-as-list

Browse source 
# Conflicts:
#	salt/beacons/__init__.py
This commit is contained in:
makearl 2015-11-18 14:27:39 -06:00
commit fe53009d18
865 changed files with 59605 additions and 38998 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
.editorconfig Normal file
View file

@ -0,0 +1,7 @@
# For more info on EditorConfig, see: http://EditorConfig.org
root = true
[*.py]
indent_style = space
indent_size = 4

21
.gitignore vendored
View file

@ -17,15 +17,18 @@ MANIFEST
# top of salt such as
# - /some/path$ git clone https://github.com/thatch45/salt.git
# - /some/path$ virtualenv --python=/usr/bin/python2.6 salt
bin/
include/
lib/
lib64
pip/
share/
tests/integration/tmp/
tests/cachedir/
tests/unit/templates/roots/
/bin/
/etc/
/include/
/lib/
/lib64/
/local/
/pip/
/share/
/tests/integration/tmp/
/tests/cachedir/
/tests/unit/templates/roots/
/var/
# setuptools stuff
*.egg-info

4
.pylintrc
View file

@ -162,7 +162,9 @@ additional-builtins=__opts__,
__master_opts__,
__jid_event__,
__instance_id__,
__salt_system_encoding__
__salt_system_encoding__,
__proxy__,
__serializers__
# List of strings which can identify a callback function by name. A callback
# name must start or end with one of those strings.

4
.testing.pylintrc
View file

@ -225,7 +225,9 @@ additional-builtins=__opts__,
__master_opts__,
__jid_event__,
__instance_id__,
__salt_system_encoding__
__salt_system_encoding__,
__proxy__,
__serializers__
# List of strings which can identify a callback function by name. A callback

3
conf/cloud
View file

@ -28,6 +28,9 @@
# 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: 'info'
#
#log_level: info

140
conf/master
View file

@ -27,31 +27,6 @@
# modified files cause conflicts, set verify_env to False.
#user: root
# Max open files
#
# Each minion connecting to the master uses AT LEAST one file descriptor, the
# master subscription connection. If enough minions connect you might start
# seeing on the console (and then salt-master crashes):
# Too many open files (tcp_listener.cpp:335)
# Aborted (core dumped)
#
# By default this value will be the one of `ulimit -Hn`, ie, the hard limit for
# max open files.
#
# If you wish to set a different value than the default one, uncomment and
# configure this setting. Remember that this value CANNOT be higher than the
# hard limit. Raising the hard limit depends on your OS and/or distribution,
# a good way to find the limit is to search the internet. For example:
# raise max open files hard limit debian
#
#max_open_files: 100000
# The number of worker threads to start. These threads are used to manage
# return calls made from minions to the master. If the master seems to be
# running slowly, increase the number of threads. This setting can not be
# set lower than 3.
#worker_threads: 5
# The port used by the communication interface. The ret (return) port is the
# interface used for the file server, authentication, job returns, etc.
#ret_port: 4506
@ -204,6 +179,59 @@
# - /etc/salt/extra_config
##### Large-scale tuning settings #####
##########################################
# Max open files
#
# Each minion connecting to the master uses AT LEAST one file descriptor, the
# master subscription connection. If enough minions connect you might start
# seeing on the console (and then salt-master crashes):
# Too many open files (tcp_listener.cpp:335)
# Aborted (core dumped)
#
# By default this value will be the one of `ulimit -Hn`, ie, the hard limit for
# max open files.
#
# If you wish to set a different value than the default one, uncomment and
# configure this setting. Remember that this value CANNOT be higher than the
# hard limit. Raising the hard limit depends on your OS and/or distribution,
# a good way to find the limit is to search the internet. For example:
# raise max open files hard limit debian
#
#max_open_files: 100000
# The number of worker threads to start. These threads are used to manage
# return calls made from minions to the master. If the master seems to be
# running slowly, increase the number of threads. This setting can not be
# set lower than 3.
#worker_threads: 5
# Set the ZeroMQ high water marks
# http://api.zeromq.org/3-2:zmq-setsockopt
# The publisher interface ZeroMQPubServerChannel
#pub_hwm: 1000
# These two ZMQ HWM settings, salt_event_pub_hwm and event_publisher_pub_hwm
# are significant for masters with thousands of minions. When these are
# insufficiently high it will manifest in random responses missing in the CLI
# and even missing from the job cache. Masters that have fast CPUs and many
# cores with appropriate worker_threads will not need these set as high.
# On deployment with 8,000 minions, 2.4GHz CPUs, 24 cores, 32GiB memory has
# these settings:
#
# salt_event_pub_hwm: 128000
# event_publisher_pub_hwm: 64000
# ZMQ high-water-mark for SaltEvent pub socket
#salt_event_pub_hwm: 20000
# ZMQ high-water-mark for EventPublisher pub socket
#event_publisher_pub_hwm: 10000
##### Security settings #####
##########################################
# Enable "open mode", this mode still maintains encryption, but turns off
@ -244,7 +272,7 @@
# This setting should be treated with care since it opens up execution
# capabilities to non root users. By default this capability is completely
# disabled.
#client_acl:
#pulisher_acl:
# larry:
# - test.ping
# - network.*
@ -255,14 +283,18 @@
# running any commands. It would also blacklist any use of the "cmd"
# module. This is completely disabled by default.
#
#client_acl_blacklist:
#publisher_acl_blacklist:
# users:
# - root
# - '^(?!sudo_).*$' # all non sudo users
# modules:
# - cmd
#
# WARNING: client_acl and client_acl_blacklist options are deprecated and will
# be removed in the future releases. Use publisher_acl and
# publisher_acl_blacklist instead.
# Enforce client_acl & client_acl_blacklist when users have sudo
# Enforce publisher_acl & publisher_acl_blacklist when users have sudo
# access to the salt command.
#
#sudo_acl: False
@ -424,12 +456,17 @@
# default behaviour is an unordered merge. To prevent top files from
# being merged together and instead to only use the top file from the
# requested environment, set this value to 'same'.
# top_file_merging_strategy: merge
#top_file_merging_strategy: merge
# To specify the order in which environments are merged, set the ordering
# in the env_order option. Given a conflict, the last matching value will
# win.
# env_order: ['base', 'dev', 'prod']
#env_order: ['base', 'dev', 'prod']
# If top_file_merging_strategy is set to 'same' and an environment does not
# contain a top file, the top file in the environment specified by default_top
# will be used instead.
#default_top: base
# The hash_type is the hash to use when discovering the hash of a file on
# the master server. The default is md5, but sha1, sha224, sha256, sha384
@ -565,7 +602,7 @@
# master config file that can then be used on minions.
#pillar_opts: False
# The pillar_safe_render_error option prevents the master from passing piller
# The pillar_safe_render_error option prevents the master from passing pillar
# render errors to the minion. This is set on by default because the error could
# contain templating data which would give that minion information it shouldn't
# have, like a password! When set true the error message will only show:
@ -652,7 +689,7 @@
#
#
##### Mine settings #####
##########################################
#####################################
# Restrict mine.get access from minions. By default any minion has a full access
# to get all mine data from master cache. In acl definion below, only pcre matches
# are allowed.
@ -687,6 +724,10 @@
# 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']
#
#log_level: warning
# The level of messages to send to the log file.
@ -728,7 +769,7 @@
#log_granular_levels: {}
##### Node Groups #####
##### Node Groups ######
##########################################
# Node groups allow for logical groupings of minion nodes. A group consists of a group
# name and a compound target.
@ -745,19 +786,38 @@
#range_server: range:80
##### Windows Software Repo settings #####
##############################################
##### Windows Software Repo settings #####
###########################################
# Location of the repo on the master:
#win_repo: '/srv/salt/win/repo'
#
# Location of the master's repo cache file:
#win_repo_mastercachefile: '/srv/salt/win/repo/winrepo.p'
#winrepo_dir_ng: '/srv/salt/win/repo-ng'
#
# List of git repositories to include with the local repo:
#win_gitrepos:
#winrepo_remotes_ng:
# - 'https://github.com/saltstack/salt-winrepo-ng.git'
##### Windows Software Repo settings - Pre 2015.8 #####
########################################################
# Legacy repo settings for pre-2015.8 Windows minions.
#
# Location of the repo on the master:
#winrepo_dir: '/srv/salt/win/repo'
#
# Location of the master's repo cache file:
#winrepo_mastercachefile: '/srv/salt/win/repo/winrepo.p'
#
# List of git repositories to include with the local repo:
#winrepo_remotes:
# - 'https://github.com/saltstack/salt-winrepo.git'
##### Returner settings ######
############################################
# Which returner(s) will be used for minion's result:
#return: mysql
###### Miscellaneous settings ######
############################################
# Default match type for filtering events tags: startswith, endswith, find, regex, fnmatch
#event_match_type: startswith

17
conf/minion
View file

@ -31,7 +31,9 @@
# master_type: str
# Poll interval in seconds for checking if the master is still there. Only
# respected if master_type above is "failover".
# 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
# Set whether the minion should connect to the master via IPv6:
@ -402,7 +404,8 @@
# 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.
# 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
@ -511,6 +514,10 @@
# 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
@ -644,3 +651,9 @@
############################################
# Which returner(s) will be used for minion's result:
#return: mysql
###### Miscellaneous settings ######
############################################
# Default match type for filtering events tags: startswith, endswith, find, regex, fnmatch
#event_match_type: startswith

636
conf/proxy Normal file
View file

@ -0,0 +1,636 @@
##### 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 minion will automatically include all config files
# from minion.d/*.conf (minion.d is a directory in the same directory
# as the main minion config file).
#default_include: minion.d/*.conf
# Backwards compatibility option for proxymodules created before 2015.8.2
# This setting will default to 'False' in the Boron 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
# Set the location of the salt master server. If the master server cannot be
# resolved, then the minion will fail to start.
#master: salt
# 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
# 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 port used by the master reply and authentication server.
#master_port: 4506
# The user to run salt.
#user: root
# 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
# 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 directory to store the pki information in
#pki_dir: /etc/salt/pki/minion
# Where cache data goes.
# This data may contain sensitive data and should be protected accordingly.
#cachedir: /var/cache/salt/minion
# 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
# 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
# Do not strip off the colored output from nested results and state outputs
# (true by default).
# strip_colors: False
# Backup files that are replaced by file.managed and file.recurse under
# 'cachedir'/file_backups 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
# 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
# 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: 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.
# If you don't have any problems with syn-floods, don't bother with the
# three recon_* settings described below, just leave the defaults!
#
# The ZeroMQ pull-socket that binds to the masters publishing interface tries
# to reconnect immediately, if the socket is disconnected (for example if
# the master processes are restarted). In large setups this will have all
# minions reconnect immediately which might flood the master (the ZeroMQ-default
# is usually a 100ms delay). To prevent this, these three recon_* settings
# can be used.
# recon_default: the interval in milliseconds that the socket should wait before
# trying to reconnect to the master (1000ms = 1 second)
#
# recon_max: the maximum time a socket should wait. each interval the time to wait
# is calculated by doubling the previous time. if recon_max is reached,
# it starts again at recon_default. Short example:
#
# reconnect 1: the socket will wait 'recon_default' milliseconds
# reconnect 2: 'recon_default' * 2
# reconnect 3: ('recon_default' * 2) * 2
# reconnect 4: value from previous interval * 2
# reconnect 5: value from previous interval * 2
# reconnect x: if value >= recon_max, it starts again with recon_default
#
# recon_randomize: generate a random wait time on minion start. The wait time will
# be a random value between recon_default and recon_default +
# recon_max. Having all minions reconnect with the same recon_default
# and recon_max value kind of defeats the purpose of being able to
# change these settings. If all minions have the same values and your
# setup is quite large (several thousand minions), they will still
# flood the master. The desired behavior is to have timeframe within
# all minions try to reconnect.
#
# Example on how to use these settings. The goal: have all minions reconnect within a
# 60 second timeframe on a disconnect.
# recon_default: 1000
# recon_max: 59000
# recon_randomize: True
#
# Each minion will have a randomized reconnect value between 'recon_default'
# and 'recon_default + recon_max', which in this example means between 1000ms
# 60000ms (or between 1 and 60 seconds). The generated random-value will be
# doubled after each attempt to reconnect. Lets say the generated random
# value is 11 seconds (or 11000ms).
# reconnect 1: wait 11 seconds
# reconnect 2: wait 22 seconds
# reconnect 3: wait 33 seconds
# reconnect 4: wait 44 seconds
# reconnect 5: wait 55 seconds
# reconnect 6: wait time is bigger than 60 seconds (recon_default + recon_max)
# reconnect 7: wait 11 seconds
# reconnect 8: wait 22 seconds
# reconnect 9: wait 33 seconds
# reconnect x: etc.
#
# In a setup with ~6000 thousand hosts these settings would average the reconnects
# to about 100 per second and all hosts would be reconnected within 60 seconds.
# recon_default: 100
# recon_max: 5000
# recon_randomize: False
#
#
# The loop_interval sets how long in seconds the minion will wait between
# evaluating the scheduler and running cleanup tasks. This defaults to a
# sane 60 seconds, but if the minion scheduler needs to be evaluated more
# often lower this value
#loop_interval: 60
# 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
# 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
# Windows platforms lack posix IPC and must rely on slower TCP based inter-
# process communications. Set ipc_mode to 'tcp' on such systems
#ipc_mode: ipc
# Overwrite the default tcp ports used by the minion when in tcp mode
#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
# 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
#
#
#
##### 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 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
# yaml_wempy
# json_jinja
# json_mako
# json_wempy
#
#renderer: yaml_jinja
#
# 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: ''
# 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
##### 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
# 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 md5, but sha1, sha224, sha256, sha384
# and sha512 are also supported.
#
# Warning: Prior to changing this value, the minion should be stopped and all
# Salt caches should be cleared.
#hash_type: md5
# 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
# 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
# The state_verbose and state_output settings can be used to change the way
# state system data is printed to the display. By default all data is printed.
# The state_verbose setting can be set to True or False, when set to False
# all data that has a result of True and no changes will be suppressed.
#state_verbose: True
# The state_output setting changes if the output is the full multi line
# output for each changed state if set to 'full', but if set to 'terse'
# the output will be shortened to a single line.
#state_output: full
# The state_output_diff setting changes whether or not the output from
# successful states is returned. Useful when even the terse output of these
# states is cluttering the logs. Set it to True to ignore them.
#state_output_diff: False
# The state_output_profile setting changes whether profile information
# will be shown for each state run.
#state_output_profile: True
# 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
##### 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:
# The date and time format used in log messages. Allowed date/time formating
# can be seen here: http://docs.python.org/library/time.html#time.strftime
#log_datefmt: '%H:%M:%S'
#log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'
# The format of the console logging messages. Allowed formatting options can
# be seen here: http://docs.python.org/library/logging.html#logrecord-attributes
#
# Console log colors are specified by these additional formatters:
#
# %(colorlevel)s
# %(colorname)s
# %(colorprocess)s
# %(colormsg)s
#
# Since it is desirable to include the surrounding brackets, '[' and ']', in
# the coloring of the messages, these color formatters also include padding as
# well. Color LogRecord attributes are only available for console logging.
#
#log_fmt_console: '%(colorlevel)s %(colormsg)s'
#log_fmt_console: '[%(levelname)-8s] %(message)s'
#
#log_fmt_logfile: '%(asctime)s,%(msecs)03.0f [%(name)-17s][%(levelname)-8s] %(message)s'
# This can be used to control logging levels more specificically. This
# example sets the main salt library at the 'warning' level, but sets
# 'salt.modules' to log at the 'debug' level:
# log_granular_levels:
# 'salt': 'warning'
# 'salt.modules': 'debug'
#
#log_granular_levels: {}
# 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
###### 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.
# Overall state of TCP Keepalives, enable (1 or True), disable (0 or False)
# or leave to the OS defaults (-1), on Linux, typically disabled. Default True, enabled.
#tcp_keepalive: True
# How long before the first keepalive should be sent in seconds. Default 300
# to send the first keepalive after 5 minutes, OS default (-1) is typically 7200 seconds
# on Linux see /proc/sys/net/ipv4/tcp_keepalive_time.
#tcp_keepalive_idle: 300
# How many lost probes are needed to consider the connection lost. Default -1
# to use OS defaults, typically 9 on Linux, see /proc/sys/net/ipv4/tcp_keepalive_probes.
#tcp_keepalive_cnt: -1
# How often, in seconds, to send keepalives after the first one. Default -1 to
# use OS defaults, typically 75 seconds on Linux, see
# /proc/sys/net/ipv4/tcp_keepalive_intvl.
#tcp_keepalive_intvl: -1
###### Windows Software settings ######
############################################
# Location of the repository cache file on the master:
#win_repo_cachefile: 'salt://win/repo/winrepo.p'
###### Returner settings ######
############################################
# Which returner(s) will be used for minion's result:
#return: mysql

3
doc/_static/proxy_minions.drawio.xml vendored
View file

File diff suppressed because one or more lines are too long

BIN
doc/_static/proxy_minions.png vendored
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 118 KiB

After

Width:  |  Height:  |  Size: 113 KiB

2
doc/_static/proxy_minions.svg vendored
View file

File diff suppressed because one or more lines are too long
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 109 KiB

After

Width:  |  Height:  |  Size: 109 KiB

30
doc/_themes/saltstack2/layout.html vendored
View file

@ -21,12 +21,12 @@
{% set script_files = [
'_static/js/core.min.js',
'_static/js/webhelp.min_v1.4.1.js',
'_static/js/webhelp.min_v1.4.3.js',
] %}
{% set css_files = [
'_static/css/core.min.css',
'_static/css/webhelp.min_v1.4.2.css',
'_static/css/webhelp.min_v1.4.4.css',
] %}
{%- macro relbar() %}
@ -160,6 +160,12 @@
</div>
{% endif %}
{% if build_type == "inactive" and on_saltstack %}
<div id="dev-notification">
<div class="alert alert-warning dev-notification-text releaselinks" role="alert"><i class="glyphicon glyphicon-cog"></i> You are viewing docs from a branch that is no longer active. You might want to view docs for the <a data-container="body" data-toggle="tooltip" data-placement="bottom" title="Docs for the latest stable release" href="/en/latest/">{{ latest_release }}</a> release instead.</div>
</div>
{% endif %}
{%- block document %}
<div class="body-content">
{% block body %} {% endblock %}
@ -192,8 +198,11 @@
{% elif build_type == "previous" %}
<p>You are viewing docs for the previous stable release, {{ previous_release }}. Switch to docs for the latest stable release, <a data-container="body" data-toggle="tooltip" data-placement="bottom" title="Docs for the latest stable release" href="/en/latest/">{{ latest_release }}</a>, or to a recent doc build from the <a data-container="body" data-toggle="tooltip" data-placement="bottom" title="Latest docs from the develop branch" href="/en/develop/">develop</a> branch.</p>
{% elif build_type == "inactive" %}
<p>You are viewing docs for an inactive release, {{ previous_release }}. Switch to docs for the latest stable release, <a data-container="body" data-toggle="tooltip" data-placement="bottom" title="Docs for the latest stable release" href="/en/latest/">{{ latest_release }}</a>, or to a recent doc build from the <a data-container="body" data-toggle="tooltip" data-placement="bottom" title="Latest docs from the develop branch" href="/en/develop/">develop</a> branch.</p>
{% elif build_type == "develop" %}
<p>You are viewing docs built from a recent snapshot of the develop branch. Switch to docs for the latest stable release, <a data-container="body" data-toggle="tooltip" data-placement="bottom" title="Docs for the latest stable release" href="/en/latest/">{{ latest_release }}</a>, or to docs for the previous stable release, <a data-container="body" data-toggle="tooltip" data-placement="bottom" title="Docs for the previous stable release" href="/en/{{ previous_release_dir }}/">{{ previous_release }}</a>.</p>
<p>You are viewing docs built from a recent snapshot of the develop branch. Switch to docs for the latest stable release, <a data-container="body" data-toggle="tooltip" data-placement="bottom" title="Docs for the latest stable release" href="/en/latest/">{{ latest_release }}</a>.</p>
{% endif %}
<br>
@ -203,12 +212,9 @@
<div class="col-sm-6">
<a href="http://saltstack.com/saltstack-enterprise-4-0-now-with-gui/" target="_blank"><img class="nolightbox nav-banner" src="{{ pathto('_static/images/saltStack_enterprise_350x125.jpg', 1) }}"/></a>
<a href="http://saltstack.com/events/" target="_blank"><img class="nolightbox footer-banner center" src="{{ pathto('_static/images/webinars-banner.png', 1) }}"/></a>
<br/><br/>
<p><b>SaltStack Training</b></p>
<p><a href="http://www.saltstack.com/training/">Now offering remote attendee training!</a></p>
</div>
</div>
{% endif %}
@ -221,18 +227,20 @@
<div id="sidebar-wrapper">
<div id="sidebar-static">
<a class="ss-logo" href="http://saltstack.com"><img width="250" height="63" class="nolightbox center" src="{{ pathto('_static/images/saltstack_logo.svg', 1) }}"></a>
<a class="ss-logo" href="http://saltstack.com"><img width="250" height="63" class="nolightbox sidebar-logo" src="{{ pathto('_static/images/saltstack_logo.svg', 1) }}"></a>
{% if on_saltstack %}
<div class="versions {{ build_type }}">
<a class="btn btn-secondary{% if build_type == "previous" %} active{% endif %}" id="previous"{% if build_type == "previous" %} title="View release notes"{% else %} title="Switch to docs for the previous stable release"{% endif %} data-container="body" data-toggle="tooltip" data-placement="bottom" href="/en/{{ previous_release_dir }}/">{{ previous_release }}{% if build_type == "previous" %} <i class="glyphicon glyphicon-ok"></i>{%- endif %}</a>
<a href="http://saltconf.com" target="_blank"><img class="nolightbox sidebar-banner center" src="{{ pathto('_static/images/sc16-banner.png', 1) }}"/></a>
<div class="releaselinks versions {{ build_type }}">
<a class="btn btn-secondary{% if build_type == "previous" or build_type == "inactive" %} active{% endif %}" id="previous"{% if build_type == "previous" or build_type == "inactive" %} title="View release notes"{% else %} title="Switch to docs for the previous stable release"{% endif %} data-container="body" data-toggle="tooltip" data-placement="bottom" href="/en/{{ previous_release_dir }}/">{{ previous_release }}{% if build_type == "previous" or build_type == "inactive" %} <i class="glyphicon glyphicon-ok"></i>{%- endif %}</a>
<a class="btn btn-secondary{% if build_type == "latest" %} active{% endif %}" id="latest"{% if build_type == "latest" %} title="View release notes"{% else %} title="Switch to docs for the latest stable release"{% endif %} data-container="body" data-toggle="tooltip" data-placement="bottom" href="/en/latest/">{{ latest_release }}{% if build_type == "latest" %} <i class="glyphicon glyphicon-ok"></i>{% endif %}</a>
<a class="btn btn-secondary{% if build_type == "develop" %} active{% endif %}" id="develop"{% if build_type == "develop" %} title="View all release notes"{% endif %} title="Switch to docs built recently from the develop branch" data-container="body" data-toggle="tooltip" data-placement="bottom" href="/en/develop/">Develop{% if build_type == "develop" %} <i class="glyphicon glyphicon-ok"></i>{% endif %}</a>
<p><a id="notifications" title="View the latest announcements from SaltStack" data-container="body" data-toggle="tooltip" data-placement="bottom" href="#">Announcements</a></p>
</div>
{% else %}

11
doc/_themes/saltstack2/static/css/webhelp.min_v1.4.2.css → doc/_themes/saltstack2/static/css/webhelp.min_v1.4.4.css vendored
View file

@ -72,6 +72,7 @@ button#prev-button{float:left;margin:15px 0 0}
#page-content-wrapper{padding:20px 0 0}
#wrapper.toggled #page-content-wrapper{position:relative;margin-right:0}
#menu-toggle{display:none!important}
.footer-banner{width:90%}
}
@media(min-width:1200px) {
#wrapper{padding-right:350px}
@ -84,6 +85,7 @@ button#prev-button{float:left;margin:15px 0 0}
#wrapper.toggled #page-content-wrapper{position:relative;margin-right:0}
#menu-toggle{display:none!important}
.alert.alert-warning.dev-notification-text{width:68%}
.footer-banner{width:75%}
}
@media(min-width:1400px) {
#sidebar-wrapper{margin-right:-175px}
@ -93,6 +95,9 @@ button#prev-button{float:left;margin:15px 0 0}
@media(max-width:768px) {
#sidebar-wrapper{border:1px solid #424242}
}
@media(max-height:750px) {
.sidebar-banner{display: none !important}
}
#header-nav{float:right;text-align:right}
#header-nav li{padding:0 0 15px 15px;font-weight:300}
#sidebar-wrapper{visibility:hidden}
@ -138,7 +143,7 @@ ul.nav.collapsed{margin-left:80px;font-size:14pt}
#expanded-nav{font-size:12pt;font-weight:300}
#expanded-nav li{padding:0 15px 0 0}
ul.nav.collapsed li{padding:0 0 15px 10px;margin:0}
#social-links{text-align:center;padding:10px 0}
#social-links{text-align:center;padding:15px 0}
.navbar-default{background-color:#fff;border-color:#fff}
.navbar-header{width:100%}
.open>.dropdown-menu{width:100%}
@ -167,6 +172,8 @@ div.logo{background-color:#000}
div.versions .btn{padding: 3px 6px}
div.versions p{margin: 3px 0 0}
div.versions a,div.versions a:hover,div.versions a:active{color: #428bca}
.sidebar-banner{padding: 0 0 10px 0}
.sidebar-logo{display:block;margin: 10px auto 10px auto}
/*pygments*/
@ -311,6 +318,8 @@ dl{margin-bottom:15px}
dd p{margin-top:0}
dd ul,dd table{margin-bottom:10px}
dd{margin-top:3px;margin-bottom:10px;margin-left:30px}
dd table{table-layout:fixed;width:100%}
dd table th.field-name{width:20%}
dl.glossary dt{font-weight:700;font-size:1.1em}
.field-list ul{margin:0;padding-left:1em}
.field-list p{margin:0}

BIN
doc/_themes/saltstack2/static/images/saltStack_enterprise_350x125.jpg vendored
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 22 KiB

65
doc/_themes/saltstack2/static/images/saltstack_logo.svg vendored
View file

@ -1,27 +1,44 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 18.1.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
viewBox="0 0 257.5 65" enable-background="new 0 0 257.5 65" xml:space="preserve">
<g>
<path d="M162.6,29.3c-4.2-1-4.7-1.7-4.7-2.9c0-1.2,1.2-2,3-2c1.8,0,3.6,0.7,5.5,2.1l0.4,0.3l2.6-3.6l-0.4-0.3c-2.3-1.9-5-2.8-8-2.8
c-4.6,0-7.8,2.8-7.8,6.8c0,4.2,2.7,5.7,7.5,6.9c4.1,1,4.4,1.7,4.4,2.8c0,1.3-1.3,2.2-3.3,2.2c-2.3,0-4.3-0.8-6.4-2.6l-0.4-0.3
l-2.9,3.4l0.4,0.3c2.6,2.3,5.8,3.5,9.2,3.5c4.9,0,8.1-2.7,8.1-6.9C169.8,31.7,166.4,30.2,162.6,29.3z"/>
<polygon points="189.6,20.3 171.3,20.3 171.3,24.8 178.1,24.8 178.1,42.7 182.8,42.7 182.8,24.8 189.6,24.8 "/>
<path d="M197.6,20.2l-9.8,22.5h4.9l2.2-5.1h6l1.6-4.2l4,9.4h5.1l-9.8-22.5H197.6z M196.7,33.2l2.9-6.8l2.9,6.8H196.7z"/>
<path d="M228.9,36c-1.7,1.6-3.3,2.6-5.8,2.6c-3.7,0-6.5-3-6.5-7.1c0-4,2.8-7,6.5-7c2,0,3.8,0.8,5.6,2.5l0.4,0.4l3.1-3.5l-0.3-0.3
c-1.8-1.7-4.2-3.5-8.7-3.5c-6.6,0-11.5,5-11.5,11.6c0,6.4,5,11.5,11.4,11.5c3.7,0,6.4-1.2,9-3.9l0.3-0.4l-3.1-3.1L228.9,36z"/>
<polygon points="245.9,30.1 255.3,20.3 249.3,20.3 239.8,30.3 239.8,20.3 235.1,20.3 235.1,42.7 239.8,42.7 239.8,36.2 242.6,33.3
249.7,42.7 255.5,42.7 "/>
<path d="M83.7,29.9c-5-1.1-5.4-2.2-5.4-3.7c0-1.7,1.7-2.9,4-2.9c2.1,0,4,0.7,5.8,2.2l0.4,0.3l2-2.7l-0.4-0.3
c-2.4-1.9-4.7-2.7-7.8-2.7c-4.3,0-7.5,2.7-7.5,6.4c0,4.2,3,5.7,7.6,6.6c4.8,1,5.1,2.2,5.1,3.6c0,1.9-1.7,3.1-4.3,3.1
c-2.7,0-4.7-0.8-7-2.9L76,36.6l-2.1,2.5l0.4,0.3c2.7,2.4,5.6,3.5,9.1,3.5c4.6,0,7.8-2.7,7.8-6.6C91,32.9,88.8,31,83.7,29.9z"/>
<path d="M102.6,20.2L92.4,42.7H96l2.5-5.6h8.6l1.1-2.9l3.8,8.5h3.7l-10.2-22.5H102.6z M99.9,33.9l4.1-9.2l4.1,9.2H99.9z"/>
<polygon points="122,20.3 118.6,20.3 118.6,42.7 134,42.7 134,39.4 122,39.4 "/>
<polygon points="132.9,23.6 140,23.6 140,42.7 143.5,42.7 143.5,23.6 150.6,23.6 150.6,20.3 132.9,20.3 "/>
<!-- Generator: Adobe Illustrator 19.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<svg version="1.1" id="horizontal" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
viewBox="0 0 500 120" style="enable-background:new 0 0 500 120;" xml:space="preserve">
<g id="saltStack_x5F_icon_x5F_thicker_2_">
<g>
<path d="M49.4,1.7c1.7-1.2,3.2-1,5,0c5,3,10,5.9,15.1,8.7c0.5,0.3,1.4,0.1,1.9-0.1c5-2.8,9.9-5.6,14.8-8.6c1.7-1,3.1-1.2,4.8-0.1
c7.5,4.4,15.1,8.8,22.7,13.1c1.6,0.9,2.3,2.1,2.3,3.9c-0.1,8.8-0.1,17.6,0,26.4c0,1.7-0.6,2.8-2.1,3.7c-4.5,2.5-8.9,5.1-13.4,7.7
c3.2,2.6,3.2,2.6,3.2,6.7c0,8.2,0,16.4,0,24.7c0,1.6-0.6,2.5-2,3.3c-15.6,9-31.2,17.9-46.7,27c-2.2,1.3-3.8,1.3-6,0
c-15.5-9.1-31.1-18.1-46.7-27c-1.5-0.8-2.1-2-2.1-3.6c0-18.3,0-36.7,0-55c0-1.6,0.6-2.7,2-3.5L49.4,1.7z M49.3,63.1
c0-1.1-0.3-1.7-1.2-2.2L5.4,36.4l0,48.9c0,1.2,0.4,1.8,1.4,2.4l42.3,24.4L49.3,63.1z M96.9,87.6c1-0.6,1.4-1.1,1.4-2.3l-0.1-20.5
L78.4,76.1c-2.8,1.6-4.7,0.5-4.7-2.7c0-7,0-14,0-21c0-0.5,0-1.1-0.1-1.8L55.6,61c-0.9,0.5-1.1,1.2-1.1,2.1l0,49L96.9,87.6z
M50.7,56.4c0.8,0.5,1.4,0.5,2.2,0c3.4-2.1,6.9-4,10.4-6c2.5-1.4,4.9-2.9,7.6-4.5c-1-0.6-1.8-1.1-2.6-1.5
c-5.9-3.4-11.7-6.8-17.6-10.2c-2.2-1.3-2.2-3.7,0-5c3.1-1.8,6.1-3.6,9.2-5.3c1-0.5,1.5-1.2,1.3-2.3c-0.1-0.5,0-0.9,0-1.4
c-0.3-2.6,0.1-4.8,2.9-5.9c0.1,0,0.2-0.2,0.3-0.4c-3.9-2.2-7.8-4.4-11.6-6.7c-1-0.6-1.6-0.5-2.5,0L8.2,31.7L50.7,56.4z
M107.8,17.6c-0.4-0.3-0.5-0.4-0.6-0.4c-5.9-3.4-11.8-6.8-17.7-10.2c-0.4-0.2-1.3-0.2-1.8,0.1c-5.3,3-10.5,6-15.7,9
c-0.7,0.4-1.4,0.9-2.4,1.4c0.4,0.2,0.5,0.3,0.6,0.4c5.9,3.4,11.8,6.8,17.7,10.2c0.4,0.2,1.3,0.1,1.8-0.1c2.6-1.4,5.1-2.9,7.6-4.3
C100.7,21.7,104.1,19.7,107.8,17.6z M109.7,44.8c0.5-0.3,0.8-1.1,0.8-1.7c0.1-6.4,0-12.8,0-19.3c0-0.4-0.1-0.8-0.1-1.2
c-0.3,0-0.4,0-0.5,0c-5.9,3.4-11.8,6.8-17.7,10.3c-0.5,0.3-0.8,1.1-0.8,1.7l0,20.7L109.7,44.8z M66.8,22.3c0,4.8,0,9.2,0,13.7
c0,1,0.4,1.6,1.2,2c3.1,1.8,6.2,3.6,9.4,5.4c1.3,0.7,1.8,1.7,1.8,3.1c0,1.3,0,2.7,0,4c0,0.4,0.1,1,0.4,1.2c2,1.3,4.1,2.4,6.3,3.7
c0.1-0.5,0.2-0.7,0.2-0.9c0-6.7,0-13.5,0-20.2c0-0.5-0.5-1.2-1-1.5L66.8,22.3z M79.3,57.8c0,4,0,7.7,0,11.7
c5.5-3.2,10.8-6.2,16-9.3c-0.1-0.2-0.2-0.4-0.3-0.5c-0.4,0.1-0.8,0.3-1.1,0.4c-1.1,0.6-2.2,1.2-3.2,1.9c-1.3,0.9-2.6,0.9-4,0.1
C84.3,60.6,81.8,59.3,79.3,57.8z M57.2,31.7c1.5,0.9,2.7,1.6,4,2.3c0-1.7,0-3.1,0-4.7C59.9,30.2,58.7,30.9,57.2,31.7z"/>
</g>
</g>
<path fill="#010101" d="M63.9,12.2L48.6,3.3L37.7,9.6l-8.9-5L3.9,19v28.9l25,14.4l25-14.4V35.7l10-5.8V12.2z M59.6,13l-11,6.4
l-11-6.4l11-6.4L59.6,13z M31.5,19.8l1.8-1l0,2l-0.7-0.4l0,0L31.5,19.8z M36.1,15.5l11,6.4v12.7L42,31.5v-5.7l-5.9-3.4L36.1,15.5z
M42,34.8l4,2.4l-4,2.3V34.8z M28.9,7.5l6.3,3.5l-1.9,1.1l0,3.6l-6.9,3.9l3.4,2l8.4,4.9L28.9,32L7.7,19.8L28.9,7.5z M6.5,22
l21.2,12.2v24.4L6.5,46.4V22z M51.3,46.4L30.2,58.6V34.2l9.3-5.4V44l9.1-5.2l0,0l2.8-1.6V46.4z M50,34.6V21.9l11-6.4v12.8L50,34.6z"
/>
<polygon points="480.7,57.1 499.5,37.6 487.5,37.6 468.6,57.6 468.6,37.6 459.1,37.6 459.1,82.4 468.6,82.4 468.6,69.4 474.2,63.7
488.4,82.4 500,82.4 "/>
<path d="M446.7,68.9c-3.5,3.3-6.7,5.3-11.6,5.3c-7.5,0-13.1-6.1-13.1-14.3c0-8,5.6-14.1,13.1-14.1c4.1,0,7.5,1.6,11.3,5l0.8,0.7
l6.2-7.1l-0.7-0.7c-3.6-3.4-8.5-6.9-17.4-6.9c-13.2,0-23.1,9.9-23.1,23.2c0,12.9,10,23,22.8,23c7.4,0,12.8-2.4,18.1-7.9l0.7-0.7
l-6.2-6.3L446.7,68.9z"/>
<path d="M383.8,37.3l-19.7,45.1h9.9l4.4-10.3h12.1l3.2-8.5l8,18.8h10.1l-19.7-45.1H383.8z M382,63.4l5.8-13.5l5.8,13.5H382z"/>
<polygon points="367.9,37.6 331.2,37.6 331.2,46.6 344.7,46.6 344.7,82.4 354.3,82.4 354.3,46.6 367.9,46.6 "/>
<path d="M313.8,55.6c-8.4-2-9.4-3.4-9.4-5.9c0-2.4,2.4-4.1,6-4.1c3.6,0,7.2,1.4,11,4.2l0.8,0.6l5.2-7.3l-0.7-0.6
c-4.7-3.8-10-5.6-16.1-5.6c-9.2,0-15.6,5.5-15.6,13.5c0,8.5,5.5,11.4,15,13.7c8.3,1.9,8.9,3.5,8.9,5.7c0,2.7-2.6,4.4-6.6,4.4
c-4.7,0-8.6-1.6-12.9-5.3l-0.8-0.7l-5.8,6.9l0.7,0.6c5.2,4.7,11.6,7.1,18.5,7.1c9.9,0,16.3-5.4,16.3-13.9
C328.3,60.3,321.3,57.4,313.8,55.6z"/>
<polygon points="254.1,44.1 268.5,44.1 268.5,82.4 275.4,82.4 275.4,44.1 289.7,44.1 289.7,37.6 254.1,37.6 "/>
<polygon points="232.3,37.6 225.5,37.6 225.5,82.4 256.4,82.4 256.4,75.9 232.3,75.9 "/>
<path d="M193.4,37.3L173,82.4h7.2l5.1-11.3h17.3l2.1-5.8l7.6,17.1h7.4l-20.4-45.1H193.4z M188,64.7l8.2-18.4l8.1,18.4H188z"/>
<path d="M155.5,56.7c-10-2.2-10.8-4.5-10.8-7.5c0-3.5,3.3-5.9,8.1-5.9c4.3,0,8,1.4,11.7,4.4l0.8,0.7l4-5.3l-0.8-0.6
c-4.8-3.8-9.5-5.5-15.7-5.5c-8.7,0-15,5.3-15,12.8c0,8.3,6.1,11.4,15.1,13.3c9.6,2,10.3,4.3,10.3,7.3c0,3.8-3.4,6.3-8.5,6.3
c-5.4,0-9.4-1.7-14-5.8l-0.8-0.7l-4.3,5.1l0.7,0.7c5.4,4.8,11.2,7.1,18.2,7.1c9.2,0,15.6-5.4,15.6-13.2
C170.3,62.9,165.9,58.9,155.5,56.7z"/>
</svg>

Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 2.5 KiB

After

Width:  |  Height:  |  Size: 4.1 KiB

BIN
doc/_themes/saltstack2/static/images/sc16-banner.png vendored Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 39 KiB

BIN
doc/_themes/saltstack2/static/images/webinars-banner.png vendored Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 94 KiB

10
doc/_themes/saltstack2/static/js/webhelp.min_v1.4.1.js → doc/_themes/saltstack2/static/js/webhelp.min_v1.4.3.js vendored
View file

@ -38,16 +38,16 @@ $( document ).ready(function() {
var hash = window.location.hash.substring(1);
var $link = $( '#sidebar-nav').find('a[href$="#' + hash + '"]').addClass("selected");
if ($link.length) {
var scrollTo_val = $link.offset().top - 300 + 'px';
var scrollTo_val = $link.offset().top - ($( '#sidebar-static' ).height() + 40) + 'px';
$( '#sidebar-nav' ).slimScroll({ scrollTo : scrollTo_val });
}
else if ($( 'a.current' ).length) {
var scrollTo_val = $( 'a.current' ).offset().top - 300 + 'px';
var scrollTo_val = $( 'a.current' ).offset().top - ($( '#sidebar-static' ).height() + 40) + 'px';
$( '#sidebar-nav' ).slimScroll({ scrollTo : scrollTo_val });
}
}
else if ($( 'a.current' ).length) {
var scrollTo_val = $( 'a.current' ).offset().top - 300 + 'px';
var scrollTo_val = $( 'a.current' ).offset().top - ($( '#sidebar-static' ).height() + 40) + 'px';
$( '#sidebar-nav' ).slimScroll({ scrollTo : scrollTo_val });
}
/*hidden by css - make visible after slimScroll plug-in loads*/
@ -115,7 +115,7 @@ $( document ).ready(function() {
});
/*version page selector*/
$( 'div.versions' ).on('click', 'a', function (e) {
$( 'div.releaselinks' ).on('click', 'a', function (e) {
e.preventDefault();
var clickedVer = $(this).attr("href");
var $currentVer = $( 'div.versions' ).find( 'a.active' ).first();
@ -188,4 +188,4 @@ function resizeend() {
function last(list) {
return list[list.length - 1];
}
}

80
doc/apidoc-saltmods.sh Executable file
View file

@ -0,0 +1,80 @@
#!/bin/sh
MOD_DIRS='
auth
beacons
cloud
engines
executors
fileserver
modules
netapi
output
pillar
proxy
queues
renderers
returners
roster
runners
sdb
serializers
states
tops
wheel'
build_stubs() {
[ $# -eq 0 ] && { printf 'Module names are required.' 1>&2; return 1; }
local outdir
while [[ -n $1 ]]; do
outdir="ref/${1}/all"
mkdir -p "$outdir"
sphinx-apidoc --separate -o "${outdir}" $(get_excludes "$1")
find "$outdir" '(' \
-path 'ref/*/all/salt.*.*.rst' \
-o -name 'index.rst' \
')' -prune \
-o -type f -print0 \
| xargs -0 rm
find "$outdir" -type f -print0 \
| xargs -0 -r -I@ -n1 sh -c \
'sed -e "/:show-inheritance:/d" @ > "@.new" && mv -- "@.new" "@"'
shift
done
}
get_excludes() {
# This is a tad convoluted. We need to list all top-level files and
# directories in the main Salt dir _except_ for the main __init__.py file
# and the the module directory for the module we're building for.
# ...that way sphinx-apidoc will exclude them from the build. (o_O)
exclude="${1:?Dirname to exclude is required.}"
find ../ \
'(' \
-path '*/.git' \
-o -path '../[!s]*/*' \
-o -path '../salt/__init__.py' \
-o -path '../*/*/*' \
')' -prune \
-o '(' \
-type d \
-o -path '../*.py' \
-o -path '../salt/*.py' \
')' -print \
| sed -e '/^\.\.\/salt$/d' \
| sed -e '/^\.\.\/salt\/'"$exclude"'$/d'
}
main() {
build_stubs $(printf '%s\n' "$MOD_DIRS")
}
main "$@"

28
doc/conf.py
View file

@ -50,6 +50,7 @@ MOCK_MODULES = [
'Crypto.PublicKey',
'Crypto.Random',
'Crypto.Signature',
'Crypto.Signature.PKCS1_v1_5',
'M2Crypto',
'msgpack',
'yaml',
@ -87,6 +88,7 @@ MOCK_MODULES = [
'tornado.httpserver',
'tornado.httputil',
'tornado.ioloop',
'tornado.simple_httpclient',
'tornado.web',
'tornado.websocket',
@ -104,7 +106,6 @@ MOCK_MODULES = [
'MySQLdb.cursors',
'nagios_json',
'psutil',
'psutil.version_info',
'pycassa',
'pymongo',
'rabbitmq_server',
@ -122,8 +123,9 @@ MOCK_MODULES = [
for mod_name in MOCK_MODULES:
sys.modules[mod_name] = Mock()
# Define a fake version attribute for libcloud so docs build as supposed
# Define a fake version attribute for the following libs.
sys.modules['libcloud'].__version__ = '0.0.0'
sys.modules['pymongo'].version = '0.0.0'
# -- Add paths to PYTHONPATH ---------------------------------------------------
@ -162,23 +164,25 @@ project = 'Salt'
copyright = '2015 SaltStack, Inc.'
version = salt.version.__version__
latest_release = '2015.5.5' # latest release
previous_release = '2014.7.6' # latest release from previous branch
previous_release_dir = '2014.7' # path on web server for previous branch
latest_release = '2015.8.1' # latest release
previous_release = '2015.5.6' # latest release from previous branch
previous_release_dir = '2015.5' # path on web server for previous branch
build_type = 'develop' # latest, previous, develop
# set release to 'version' for develop so sha is used
# - otherwise -
# set release to 'latest_release' or 'previous_release'
release = version # version, latest_release, previous_release
release = latest_release # version, latest_release, previous_release
# Set google custom search engine
if release == latest_release:
search_cx = '004624818632696854117:yfmprrbw3pk'
search_cx = '004624818632696854117:yfmprrbw3pk' # latest
elif release.startswith('2014.7'):
search_cx = '004624818632696854117:thhslradbru'
search_cx = '004624818632696854117:thhslradbru' # 2014.7
elif release.startswith('2015.5'):
search_cx = '004624818632696854117:ovogwef29do' # 2015.5
else:
search_cx = '004624818632696854117:haj7bjntf4s' # develop
@ -226,8 +230,11 @@ rst_prolog = """\
.. _`salt-packagers`: https://groups.google.com/forum/#!forum/salt-packagers
.. |windownload| raw:: html
<a href="https://repo.saltstack.com/windows/Salt-Minion-{release}-2-x86-Setup.exe"><strong>Salt-Minion-{release}-2-x86-Setup.exe</strong></a>
| <a href="https://repo.saltstack.com/windows/Salt-Minion-{release}-2-x86-Setup.exe.md5"><strong>md5</strong></a>
<p>x86: <a href="https://repo.saltstack.com/windows/Salt-Minion-{release}-x86-Setup.exe"><strong>Salt-Minion-{release}-x86-Setup.exe</strong></a>
| <a href="https://repo.saltstack.com/windows/Salt-Minion-{release}-x86-Setup.exe.md5"><strong>md5</strong></a></p>
<p>AMD64: <a href="https://repo.saltstack.com/windows/Salt-Minion-{release}-AMD64-Setup.exe"><strong>Salt-Minion-{release}-AMD64-Setup.exe</strong></a>
| <a href="https://repo.saltstack.com/windows/Salt-Minion-{release}-AMD64-Setup.exe.md5"><strong>md5</strong></a></p>
""".format(release=release)
@ -381,6 +388,7 @@ man_pages = [
('ref/cli/salt-key', 'salt-key', 'salt-key Documentation', authors, 1),
('ref/cli/salt-cp', 'salt-cp', 'salt-cp Documentation', authors, 1),
('ref/cli/salt-call', 'salt-call', 'salt-call Documentation', authors, 1),
('ref/cli/salt-proxy', 'salt-proxy', 'salt-proxy Documentation', authors, 1),
('ref/cli/salt-syndic', 'salt-syndic', 'salt-syndic Documentation', authors, 1),
('ref/cli/salt-run', 'salt-run', 'salt-run Documentation', authors, 1),
('ref/cli/salt-ssh', 'salt-ssh', 'salt-ssh Documentation', authors, 1),

5
doc/contents.rst
View file

@ -21,11 +21,13 @@ Salt Table of Contents
topics/sdb/index
topics/event/index
topics/beacons/index
topics/engines/index
topics/ext_processes/index
topics/highavailability/index
topics/topology/index
topics/proxyminion/index
topics/transports/raet/index
topics/spm/index
topics/transports/index
topics/windows/index
topics/cloud/index
topics/netapi/index
@ -35,6 +37,7 @@ Salt Table of Contents
topics/ssh/*
ref/index
topics/best_practices
topics/hardening
topics/troubleshooting/index
topics/development/index
topics/releases/index

17
doc/faq.rst
View file

@ -1,3 +1,5 @@
.. _faq:
Frequently Asked Questions
==========================
@ -301,3 +303,18 @@ More information about salting the Salt master can be found in the salt-formula
for salt itself:
https://github.com/saltstack-formulas/salt-formula
.. _faq-grain-security:
Is Targeting using Grain Data Secure?
-------------------------------------
Because grains can be set by users that have access to the minion configuration
files on the local system, grains are considered less secure than other
identifiers in Salt. Use caution when targeting sensitive operations or setting
pillar values based on grain data.
When possible, you should target sensitive operations and data using the Minion
ID. If the Minion ID of a system changes, the Salt Minion's public key must be
re-accepted by an administrator on the Salt Master, making it less vulnerable
to impersonation attacks.

1
doc/glossary.rst
View file

@ -247,6 +247,7 @@ Glossary
whether or not the module should be available to a minion. This
function commonly contains logic to determine if all requirements
for a module are available, such as external libraries.
Worker
A master process which can send notices and receive replies from
minions. *See also*:

9
doc/index.rst
View file

@ -65,6 +65,15 @@ Running Salt without root access in userland:
A list of all tutorials can be found here:
:doc:`All Salt tutorials <topics/tutorials/index>`
Demo Environments
=================
You can download one of the following `Vagrant <http://vagrantup.com>`_
projects to quickly set up a Salt demo environment:
- https://github.com/UtahDave/salt-vagrant-demo
- https://github.com/UtahDave/salt-vagrant-lxc
Salt in depth
=============

2
doc/man/salt-api.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-API" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-API" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-api \- salt-api Command
.

2
doc/man/salt-call.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-CALL" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-CALL" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-call \- salt-call Documentation
.

2
doc/man/salt-cloud.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-CLOUD" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-CLOUD" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-cloud \- Salt Cloud Command
.

2
doc/man/salt-cp.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-CP" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-CP" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-cp \- salt-cp Documentation
.

2
doc/man/salt-key.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-KEY" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-KEY" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-key \- salt-key Documentation
.

2
doc/man/salt-master.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-MASTER" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-MASTER" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-master \- salt-master Documentation
.

2
doc/man/salt-minion.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-MINION" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-MINION" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-minion \- salt-minion Documentation
.

19
doc/man/salt-proxy.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-PROXY" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-PROXY" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-proxy \- salt-proxy Documentation
.
@ -31,8 +31,8 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
..
.sp
The Salt Proxy minion daemon, receives commands from a remote Salt master
and communicates with devices unable to run a full minion.
Receives commands from a Salt master and proxies these commands to
devices that are unable to run a full minion.
.SH SYNOPSIS
.INDENT 0.0
.INDENT 3.5
@ -46,8 +46,9 @@ salt\-proxy [ options ]
.UNINDENT
.SH DESCRIPTION
.sp
The Salt proxy minion receives commands from the central Salt master, transmits apppropriate commands
to devices unable to run a minion, and replies with the results of said commands.
The Salt proxy minion receives commands from a Salt master, transmits
appropriate commands to devices that are unable to run a minion, and replies
with the results of said commands.
.SH OPTIONS
.INDENT 0.0
.TP
@ -72,9 +73,9 @@ Show the help message and exit
.INDENT 0.0
.TP
.B \-c CONFIG_DIR, \-\-config\-dir=CONFIG_dir
The location of the Salt configuration directory. This directory contains
the configuration files for Salt master and minions. The default location
on most systems is \fB/etc/salt\fP\&.
The location of the Salt configuration directory. This directory
contains the configuration files for Salt master and minions.
The default location on most systems is \fB/etc/salt\fP\&.
.UNINDENT
.INDENT 0.0
.TP
@ -89,7 +90,7 @@ Run salt\-proxy as a daemon
.INDENT 0.0
.TP
.B \-\-pid\-file PIDFILE
Specify the location of the pidfile. Default: /var/run/salt\-proxy-<id>\&.pid
Specify the location of the pidfile. Default: \fB/var/run/salt\-proxy\-<id>.pid\fP
.UNINDENT
.SS Logging Options
.sp

2
doc/man/salt-run.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-RUN" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-RUN" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-run \- salt-run Documentation
.

2
doc/man/salt-ssh.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-SSH" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-SSH" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-ssh \- salt-ssh Documentation
.

2
doc/man/salt-syndic.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-SYNDIC" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-SYNDIC" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-syndic \- salt-syndic Documentation
.

2
doc/man/salt-unity.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT-UNITY" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT-UNITY" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt-unity \- salt-unity Command
.

2
doc/man/salt.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SALT" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SALT" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
salt \- salt
.

107
doc/man/salt.7
View file

@ -7515,7 +7515,7 @@ These access control options include but are not limited to:
.IP \(bu 2
external_auth
.IP \(bu 2
client_acl
publisher_acl
.IP \(bu 2
peer
.IP \(bu 2
@ -16084,14 +16084,14 @@ 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 \fBpeer\fP system, the
\fBexternal auth\fP system and the \fBclient acl\fP system.
\fBexternal auth\fP system and the \fBpublisher acl\fP system.
.sp
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.
.sp
Now specific functions can be opened up to specific minions from specific users
in the case of external auth and client ACLs, and for specific minions in the
in the case of external auth and publisher ACLs, and for specific minions in the
case of the peer system.
.sp
The access controls are manifested using matchers in these configurations:
@ -16100,7 +16100,7 @@ The access controls are manifested using matchers in these configurations:
.sp
.nf
.ft C
client_acl:
publisher_acl:
fred:
\- web\e*:
\- pkg.list_pkgs
@ -17262,7 +17262,7 @@ called.
this job.
.IP \(bu 2
\fBuser\fP \-\- The name of the user that ran the command as defined in Salt\(aqs
Client ACL or external auth.
Publisher ACL or external auth.
.UNINDENT
.UNINDENT
.UNINDENT
@ -35632,22 +35632,23 @@ in that directory which describes them.
\fIsalt(1)\fP
\fIsalt\-master(1)\fP
\fIsalt\-minion(1)\fP
.SS Client ACL system
.SS Publisher ACL system
.sp
The salt client 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.
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.
.sp
The client ACL system is configured in the master configuration file via the
\fBclient_acl\fP configuration option. Under the \fBclient_acl\fP configuration
option the users open to send commands are specified and then a list of regular
expressions which specify the minion functions which will be made available to
specified user. This configuration is much like the \fBpeer\fP configuration:
The publisher ACL system is configured in the master configuration file via the
\fBpublisher_acl\fP configuration option. Under the \fBpublisher_acl\fP
configuration option the users open to send commands are specified and then a
list of regular expressions which specify the minion functions which will be
made available to specified user. This configuration is much like the \fBpeer\fP
configuration:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
client_acl:
publisher_acl:
# Allow thatch to execute anything.
thatch:
\- .*
@ -35662,8 +35663,8 @@ client_acl:
.UNINDENT
.SS Permission Issues
.sp
Directories required for \fBclient_acl\fP must be modified to be readable by the
users specified:
Directories required for \fBpublisher_acl\fP must be modified to be readable by
the users specified:
.INDENT 0.0
.INDENT 3.5
.sp
@ -45836,7 +45837,7 @@ salt\-cloud \-a suspend vmname
# This setting should be treated with care since it opens up execution
# capabilities to non root users. By default this capability is completely
# disabled.
#client_acl:
#publisher_acl:
# larry:
# \- test.ping
# \- network.*
@ -45847,14 +45848,18 @@ salt\-cloud \-a suspend vmname
# running any commands. It would also blacklist any use of the "cmd"
# module. This is completely disabled by default.
#
#client_acl_blacklist:
#publisher_acl_blacklist:
# users:
# \- root
# \- \(aq^(?!sudo_).*$\(aq # all non sudo users
# modules:
# \- cmd
#
# WARNING: client_acl and client_acl_blacklist options are deprecated and will
# be removed in the future releases. Use publisher_acl and
# publisher_acl_blacklist instead.
# Enforce client_acl & client_acl_blacklist when users have sudo
# Enforce publisher_acl & publisher_acl_blacklist when users have sudo
# access to the salt command.
#
#sudo_acl: False
@ -47886,7 +47891,7 @@ Works like \fI\%autosign_file\fP, but instead allows you to specify
minion IDs for which keys will automatically be rejected. Will override both
membership in the \fI\%autosign_file\fP and the
\fI\%auto_accept\fP setting.
.SS \fBclient_acl\fP
.SS \fBpublisher_acl\fP
.sp
Default: \fB{}\fP
.sp
@ -47897,7 +47902,7 @@ can be expressed as regular expressions.
.sp
.nf
.ft C
client_acl:
publisher_acl:
fred:
\- test.ping
\- pkg.*
@ -47905,7 +47910,7 @@ client_acl:
.fi
.UNINDENT
.UNINDENT
.SS \fBclient_acl_blacklist\fP
.SS \fBpublisher_acl_blacklist\fP
.sp
Default: \fB{}\fP
.sp
@ -47921,7 +47926,7 @@ This is completely disabled by default.
.sp
.nf
.ft C
client_acl_blacklist:
publisher_acl_blacklist:
users:
\- root
\- \(aq^(?!sudo_).*$\(aq # all non sudo users
@ -163290,7 +163295,7 @@ The state altering system is used to make sure that states are evaluated exactly
as the user expects. It can be used to double check that a state preformed
exactly how it was expected to, or to make 100% sure that a state only runs
under certain conditions. The use of unless or onlyif options help make states
even more stateful. The check_cmds option helps ensure that the result of a
even more stateful. The \fBcheck_cmd\fP option helps ensure that the result of a
state is evaluated correctly.
.SS Unless
.sp
@ -163468,19 +163473,27 @@ comment\-repo:
\- pattern: ^enabled=0
\- repl: enabled=1
\- check_cmd:
\- grep \(aqenabled=0\(aq /etc/yum.repos.d/fedora.repo && exit 1 || exit 0
\- ! grep \(aqenabled=0\(aq /etc/yum.repos.d/fedora.repo
.ft P
.fi
.UNINDENT
.UNINDENT
.sp
This will attempt to do a replace on all enabled=0 in the .repo file, and
replace them with enabled=1. The check_cmd is just a bash command. It will do
a grep for enabled=0 in the file, and if it finds any, it will return a 0, which
will prompt the && portion of the command to return a 1, causing check_cmd to
set the state as failed. If it returns a 1, meaning it didn\(aqt find any
\(aqenabled=0\(aq it will hit the || portion of the command, returning a 0, and
declaring the function succeeded.
replace them with enabled=1. The \fBcheck_cmd\fP is just a bash command. It
will do a grep for enabled=0 in the file, and if it finds any, it will return
a 0, which will be inverted by the leading \(aq!\(aq, causing \fBcheck_cmd\fP
to set the state as failed. If it returns a 1, meaning it didn\(aqt find any
\(aqenabled=0\(aq, it will be inverted by the leading \(aq!\(aq, returning a
0, and declaring the function succeeded.
.sp
\fBNOTE:\fP
.INDENT 0.0
.INDENT 3.5
This requisite \fBcheck_cmd\fP functions differently than the \fBcheck_cmd\fP
of the \fBfile.managed\fP state.
.UNINDENT
.UNINDENT
.SS Overriding Checks
.sp
There are two commands used for the above checks.
@ -163489,7 +163502,7 @@ There are two commands used for the above checks.
override the global check for these to variables, include a \fBmod_run_check\fP in the
salt/states/ file.
.sp
\fBmod_run_check_cmd\fP is used to check for the check_cmd options. To override
\fBmod_run_check_cmd\fP is used to check for the \fBcheck_cmd\fP options. To override
this one, include a \fBmod_run_check_cmd\fP in the states file for the state.
.SS Startup States
.sp
@ -175808,7 +175821,7 @@ New in version 2015.5.0.
.sp
Set \fBpreserve: True\fP to preserve user/group ownership and mode
after copying. Default is \fBFalse\fP\&. If \fBpreseve\fP is set to \fBTrue\fP,
after copying. Default is \fBFalse\fP\&. If \fBpreserve\fP is set to \fBTrue\fP,
then user/group/mode attributes will be ignored.
.TP
.B user
@ -176312,9 +176325,19 @@ file to which the symlink points.
New in version 2014.7.0.
.sp
The specified command will be run with the managed file as an argument.
If the command exits with a nonzero exit code, the command will not be
run.
The specified command will be run with an appended argument of a
.I temporary
file containing the new managed contents. If the command exits with a zero
status the new managed contents will be written to the managed destination.
If the command exits with a nonzero exit code, the new managed contents will
be discarded.
.sp
\fBNOTE:\fP
.INDENT 7.0
.INDENT 3.5
This \fBcheck_cmd\fP functions differently than the requisite \fBcheck_cmd\fP.
.UNINDENT
.UNINDENT
.UNINDENT
.UNINDENT
.INDENT 0.0
@ -212172,14 +212195,14 @@ other than root to execute salt commands. Users can be allowed to execute
specific commands in the same way that minions are opened up to the peer
system.
.sp
The configuration value to open up the ACL system is called \fBclient_acl\fP
The configuration value to open up the ACL system is called \fBpublisher_acl\fP
and is configured like so:
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
client_acl:
publisher_acl:
fred:
\- test..*
\- pkg.list_pkgs
@ -212403,7 +212426,7 @@ test and network modules on minions that match the web* target.
All Salt systems can now be configured to grant access to non\-administrative
users in a granular way. The old configuration continues to work. Specific
functions can be opened up to specific minions from specific users in the case
of external auth and client ACLs, and for specific minions in the case of the
of external auth and publisher ACLs, and for specific minions in the case of the
peer system.
.sp
Access controls are configured like this:
@ -212412,7 +212435,7 @@ Access controls are configured like this:
.sp
.nf
.ft C
client_acl:
publisher_acl:
fred:
\- web\e*:
\- pkg.list_pkgs
@ -212938,7 +212961,7 @@ salt\-call publish.publish group1 test.ping expr_form=nodegroup
.SS Blacklist Additions
.sp
Additions allowing more granular blacklisting are available in 0.13.0. The
ability to blacklist users and functions in client_acl have been added, as
ability to blacklist users and functions in publisher_acl have been added, as
well as the ability to exclude state formulas from the command line.
.SS Command Line Pillar Embedding
.sp
@ -213965,7 +213988,7 @@ users and mostly apply to Salt SSH.
.sp
This issue allowed for a user with limited privileges to embed executions
inside of routines to execute routines that should be restricted. This applies
to users using external auth or client ACL and opening up specific routines.
to users using external auth or publisher ACL and opening up specific routines.
.sp
Be advised that these patches address the direct issue. Additional commits have
been applied to help mitigate this issue from resurfacing.

2
doc/man/spm.1
View file

@ -1,6 +1,6 @@
.\" Man page generated from reStructuredText.
.
.TH "SPM" "1" "July 29, 2015" "2015.8.0rc2-13-g733b842" "Salt"
.TH "SPM" "1" "September 01, 2015" "2015.8.0" "Salt"
.SH NAME
spm \- Salt Package Manager Command
.

8
doc/ref/auth/all/salt.auth.rest.rst
View file

@ -1,6 +1,6 @@
==============
salt.auth.rest
==============
salt.auth.rest module
=====================
.. automodule:: salt.auth.rest
:members:
:members:
:undoc-members:

8
doc/ref/beacons/all/salt.beacons.ps.rst
View file

@ -1,6 +1,6 @@
===============
salt.beacons.ps
===============
salt.beacons.ps module
======================
.. automodule:: salt.beacons.ps
:members:
:members:
:undoc-members:

14
doc/ref/cli/index.rst
View file

@ -231,6 +231,14 @@ You may change the arguments separator using the ``--args-separator`` option:
salt --args-separator=:: '*' some.fun,test.echo params with , comma :: foo
CLI Completion
==============
Shell completion scripts for the Salt CLI are available in the ``pkg`` Salt
`source directory`_.
.. _source directory: https://github.com/saltstack/salt/tree/develop/pkg
salt-call
=========
.. toctree::
@ -273,6 +281,12 @@ salt-minion
salt-minion
salt-proxy
==========
.. toctree::
salt-proxy
salt-run
========
.. toctree::

2
doc/ref/cli/salt-cp.rst
View file

@ -22,7 +22,7 @@ Salt copy copies a local file out to all of the Salt minions matched by the
given target.
Note: salt-cp uses salt's publishing mechanism. This means the privacy of the
contents of the file on the wire are completely dependant upon the transport
contents of the file on the wire is completely dependent upon the transport
in use. In addition, if the salt-master is running with debug logging it is
possible that the contents of the file will be logged to disk.

23
doc/ref/cli/salt-key.rst
View file

@ -15,6 +15,27 @@ Description
Salt-key executes simple management of Salt server public keys used for
authentication.
On initial connection, a Salt minion sends its public key to the Salt
master. This key must be accepted using the ``salt-key`` command on the
Salt master.
Salt minion keys can be in one of the following states:
- **unaccepted**: key is waiting to be accepted.
- **accepted**: key was accepted and the minion can communicate with the Salt
master.
- **rejected**: key was rejected using the ``salt-key`` command. In
this state the minion does not receive any communication from the Salt
master.
- **denied**: key was rejected automatically by the Salt master.
This occurs when a minion has a duplicate ID, or when a minion was rebuilt or
had new keys generated and the previous key was not deleted from the Salt
master. In this state the minion does not receive any communication from the
Salt master.
To change the state of a minion key, use ``-d`` to delete the key and then
accept or reject the key.
Options
=======
@ -163,4 +184,4 @@ See also
:manpage:`salt(7)`
:manpage:`salt-master(1)`
:manpage:`salt-minion(1)`
:manpage:`salt-minion(1)`

73
doc/ref/cli/salt-proxy.rst Normal file
View file

@ -0,0 +1,73 @@
.. _salt-proxy-cli:
==============
``salt-proxy``
==============
Receives commands from a Salt master and proxies these commands to
devices that are unable to run a full minion.
Synopsis
========
.. code-block:: bash
salt-proxy [ options ]
Description
===========
The Salt proxy minion receives commands from a Salt master, transmits
appropriate commands to devices that are unable to run a minion, and replies
with the results of said commands.
Options
=======
.. program:: salt-proxy
.. option:: --proxyid
The minion id that this proxy will assume. This is required.
.. option:: --version
Print the version of Salt that is running.
.. option:: --versions-report
Show program's dependencies and version number, and then exit
.. option:: -h, --help
Show the help message and exit
.. option:: -c CONFIG_DIR, --config-dir=CONFIG_dir
The location of the Salt configuration directory. This directory
contains the configuration files for Salt master and minions.
The default location on most systems is ``/etc/salt``.
.. option:: -u USER, --user=USER
Specify user to run salt-proxy
.. option:: -d, --daemon
Run salt-proxy as a daemon
.. option:: --pid-file PIDFILE
Specify the location of the pidfile. Default: ``/var/run/salt-proxy-<id>.pid``
.. include:: _includes/logging-options.rst
.. |logfile| replace:: /var/log/salt/minion
.. |loglevel| replace:: ``warning``
See also
========
:manpage:`salt(1)`
:manpage:`salt(7)`
:manpage:`salt-master(1)`
:manpage:`salt-minion(1)`

4
doc/ref/cli/spm.rst
View file

@ -1,8 +1,10 @@
.. _spm-cli:
=======
``spm``
=======
Salt Package Manager
:ref:`Salt Package Manager <spm>`
Synopsis
========

2
doc/ref/clients/index.rst
View file

@ -46,7 +46,7 @@ Salt's Loader Interface
Modules in the Salt ecosystem are loaded into memory using a custom loader
system. This allows modules to have conditional requirements (OS, OS version,
installed libraries, etc) and allows Salt to inject special variables
(``__salt__``, ``__opts``, etc).
(``__salt__``, ``__opts__``, etc).
Most modules can be manually loaded. This is often useful in third-party Python
apps or when writing tests. However some modules require and expect a full,

6
doc/ref/clouds/all/salt.cloud.clouds.digital_ocean_v2.rst
View file

@ -1,6 +0,0 @@
==================================
salt.cloud.clouds.digital_ocean_v2
==================================
.. automodule:: salt.cloud.clouds.digital_ocean_v2
:members:

4
doc/ref/configuration/logging/index.rst
View file

@ -56,7 +56,7 @@ Examples:
``log_level``
-------------
Default: ``warning``
Default: ``info``
The level of log record messages to send to the console.
One of ``all``, ``garbage``, ``trace``, ``debug``, ``info``, ``warning``,
@ -73,7 +73,7 @@ One of ``all``, ``garbage``, ``trace``, ``debug``, ``info``, ``warning``,
``log_level_logfile``
---------------------
Default: ``warning``
Default: ``info``
The level of messages to send to the log file.
One of ``all``, ``garbage``, ``trace``, ``debug``, ``info``, ``warning``,

127
doc/ref/configuration/master.rst
View file

@ -417,7 +417,7 @@ configuration requirements. Read the returner's documentation.
``master_job_cache``
--------------------
.. versionadded:: 2014.7
.. versionadded:: 2014.7.0
Default: 'local_cache'
@ -451,10 +451,11 @@ only the cache for the mine system.
Default: 0
The number of minions the master should allow to connect. Use this to accommodate
the number of minions per master if you have different types of hardware serving
your minions. The default of ``0`` means unlimited connections. Please note, that
this can slow down the authentication process a bit in large setups.
The maximum number of minion connections allowed by the master. Use this to
accommodate the number of minions per master if you have different types of
hardware serving your minions. The default of ``0`` means unlimited connections.
Please note, that this can slow down the authentication process a bit in large
setups.
.. code-block:: yaml
@ -607,27 +608,28 @@ minion IDs for which keys will automatically be rejected. Will override both
membership in the :conf_master:`autosign_file` and the
:conf_master:`auto_accept` setting.
.. conf_master:: client_acl
.. conf_master:: publisher_acl
``client_acl``
--------------
``publisher_acl``
-----------------
Default: ``{}``
Enable user accounts on the master to execute specific modules. These modules
can be expressed as regular expressions.
can be expressed as regular expressions. Note that client_acl option is
deprecated by publisher_acl option and will be removed in future releases.
.. code-block:: yaml
client_acl:
publisher_acl:
fred:
- test.ping
- pkg.*
.. conf_master:: client_acl_blacklist
.. conf_master:: publisher_acl_blacklist
``client_acl_blacklist``
------------------------
``publisher_acl_blacklist``
---------------------------
Default: ``{}``
@ -635,13 +637,14 @@ Blacklist users or modules
This example would blacklist all non sudo users, including root from
running any commands. It would also blacklist any use of the "cmd"
module.
module. Note that client_acl_blacklist option is deprecated by
publisher_acl_blacklist option and will be removed in future releases.
This is completely disabled by default.
.. code-block:: yaml
client_acl_blacklist:
publisher_acl_blacklist:
users:
- root
- '^(?!sudo_).*$' # all non sudo users
@ -2252,6 +2255,34 @@ strategy between different sources. It accepts 4 values:
element2: True
baz: quux
* recurse_list:
it will merge recursively mapping of data similar to ``recurse`` but merge
lists by aggregating them instead of replacing them.
.. code-block:: yaml
foo: 43
bar:
- 1
- 2
.. code-block:: yaml
bar:
- 3
baz: quux
will be merged as:
.. code-block:: yaml
foo: 42
bar:
- 1
- 2
- 3
baz: quux
* aggregate:
@ -2750,17 +2781,35 @@ used.
---------------
.. versionchanged:: 2015.8.0
Renamed from ``win_repo`` to ``winrepo_dir``
Renamed from ``win_repo`` to ``winrepo_dir``.
Default: ``/srv/salt/win/repo``
Location on the master where the :conf_master:`winrepo_remotes` are checked
out.
Location on the master where the :conf_master:`winrepo_remotes` are checked out
for pre-2015.8.0 minions. 2015.8.0 and later minions use
:conf_master:`winrepo_remotes_ng <winrepo_remotes_ng>` instead.
.. code-block:: yaml
winrepo_dir: /srv/salt/win/repo
.. conf_master:: winrepo_dir_ng
``winrepo_dir_ng``
---------------
.. versionadded:: 2015.8.0
A new :ref:`ng <windows-package-manager>` repo was added.
Default: ``/srv/salt/win/repo-ng``
Location on the master where the :conf_master:`winrepo_remotes_ng` are checked
out for 2015.8.0 and later minions.
.. code-block:: yaml
winrepo_dir: /srv/salt/win/repo-ng
.. conf_master:: winrepo_cachefile
.. conf_master:: win_repo_mastercachefile
@ -2770,6 +2819,10 @@ out.
.. versionchanged:: 2015.8.0
Renamed from ``win_repo_mastercachefile`` to ``winrepo_cachefile``
.. note::
2015.8.0 and later minions do not use this setting since the cachefile
is now located on the minion.
Default: ``winrepo.p``
Path relative to :conf_master:`winrepo_dir` where the winrepo cache should be
@ -2786,11 +2839,13 @@ created.
-------------------
.. versionchanged:: 2015.8.0
Renamed from ``win_gitrepos`` to ``winrepo_remotes``
Renamed from ``win_gitrepos`` to ``winrepo_remotes``.
Default: ``['https://github.com/saltstack/salt-winrepo.git']``
List of git repositories to checkout and include in the winrepo
List of git repositories to checkout and include in the winrepo for
pre-2015.8.0 minions. 2015.8.0 and later minions use
:conf_master:`winrepo_remotes_ng <winrepo_remotes_ng>` instead.
.. code-block:: yaml
@ -2798,7 +2853,7 @@ List of git repositories to checkout and include in the winrepo
- https://github.com/saltstack/salt-winrepo.git
To specify a specific revision of the repository, prepend a commit ID to the
URL of the the repository:
URL of the repository:
.. code-block:: yaml
@ -2809,6 +2864,36 @@ Replace ``<commit_id>`` with the SHA1 hash of a commit ID. Specifying a commit
ID is useful in that it allows one to revert back to a previous version in the
event that an error is introduced in the latest revision of the repo.
.. conf_master:: winrepo_remotes_ng
``winrepo_remotes_ng``
-------------------
.. versionadded:: 2015.8.0
A new :ref:`ng <windows-package-manager>` repo was added.
Default: ``['https://github.com/saltstack/salt-winrepo-ng.git']``
List of git repositories to checkout and include in the winrepo for
2015.8.0 and later minions.
.. code-block:: yaml
winrepo_remotes_ng:
- https://github.com/saltstack/salt-winrepo-ng.git
To specify a specific revision of the repository, prepend a commit ID to the
URL of the repository:
.. code-block:: yaml
winrepo_remotes:
- '<commit_id> https://github.com/saltstack/salt-winrepo-ng.git'
Replace ``<commit_id>`` with the SHA1 hash of a commit ID. Specifying a commit
ID is useful in that it allows one to revert back to a previous version in the
event that an error is introduced in the latest revision of the repo.
.. conf_master:: winrepo_branch
``winrepo_branch``

40
doc/ref/configuration/minion.rst
View file

@ -198,7 +198,7 @@ need to be changed to the ownership of the new user.
.. conf_minion:: sudo_user
``sudo_user``
--------
-------------
Default: ``''``
@ -481,6 +481,35 @@ behavior is to have time-frame within all minions try to reconnect.
recon_randomize: True
.. conf_minion:: return_retry_timer
``return_retry_timer``
-------------------
Default: ``5``
The default timeout for a minion return attempt.
.. code-block:: yaml
return_retry_timer: 5
.. conf_minion:: return_retry_timer_max
``return_retry_timer_max``
-------------------
Default: ``10``
The maximum timeout for a minion return attempt. If non-zero the minion return
retry timeout will be a random int beween ``return_retry_timer`` and
``return_retry_timer_max``
.. code-block:: yaml
return_retry_timer_max: 10
.. conf_minion:: cache_sreqs
``cache_sreqs``
@ -986,8 +1015,11 @@ Thread Settings
Default: ``True``
Disable multiprocessing support by default when a minion receives a
If `multiprocessing` is enabled when a minion receives a
publication a new process is spawned and the command is executed therein.
Conversely, if `multiprocessing` is disabled the new publication will be run
executed in a thread.
.. code-block:: yaml
@ -1031,7 +1063,7 @@ Examples:
``log_level``
-------------
Default: ``warning``
Default: ``info``
The level of messages to send to the console. See also :conf_log:`log_level`.
@ -1045,7 +1077,7 @@ The level of messages to send to the console. See also :conf_log:`log_level`.
``log_level_logfile``
---------------------
Default: ``warning``
Default: ``info``
The level of messages to send to the log file. See also
:conf_log:`log_level_logfile`. When it is not set explicitly

23
doc/ref/file_server/dynamic-modules.rst
View file

@ -1,23 +1,30 @@
.. _module-sync:
===========================
.. _dynamic-module-distribution:
Dynamic Module Distribution
===========================
.. versionadded:: 0.9.5
Salt Python modules can be distributed automatically via the Salt file server.
Custom Salt execution, state, and other modules can be distributed to Salt
minions using the Salt file server.
Under the root of any environment defined via the :conf_master:`file_roots`
option on the master server directories corresponding to the type of module can
be used.
The directories are prepended with an underscore:
1. :file:`_modules`
2. :file:`_grains`
3. :file:`_renderers`
4. :file:`_returners`
5. :file:`_states`
- :file:`_beacons`
- :file:`_modules`
- :file:`_grains`
- :file:`_renderers`
- :file:`_returners`
- :file:`_states`
- :file:`_output`
- :file:`_utils`
The contents of these directories need to be synced over to the minions after
Python modules have been created in them. There are a number of ways to sync
@ -27,9 +34,9 @@ Sync Via States
===============
The minion configuration contains an option ``autoload_dynamic_modules``
which defaults to True. This option makes the state system refresh all
which defaults to ``True``. This option makes the state system refresh all
dynamic modules when states are run. To disable this behavior set
``autoload_dynamic_modules`` to False in the minion config.
:conf_minion:`autoload_dynamic_modules` to ``False`` in the minion config.
When dynamic modules are autoloaded via states, modules only pertinent to
the environments matched in the master's top file are downloaded.

4
doc/ref/index.rst
View file

@ -5,7 +5,7 @@ Reference
auth/all/index
cli/index
clientacl
publisheracl
clients/index
clouds/all/index
configuration/*
@ -20,6 +20,7 @@ Reference
peer
pillar/index
pillar/all/index
proxy/all/index
renderers/index
returners/index
roster/all/index
@ -33,3 +34,4 @@ Reference
beacons/all/index
engines/all/index
sdb/all/index
serializers/all/index

8
doc/ref/modules/all/index.rst
View file

@ -53,6 +53,7 @@ Full list of builtin execution modules
cabal
cassandra
cassandra_cql
chassis
chef
chocolatey
cloud
@ -72,6 +73,7 @@ Full list of builtin execution modules
ddns
deb_apache
deb_postgres
debbuild
debconfmod
debian_ip
debian_service
@ -86,6 +88,7 @@ Full list of builtin execution modules
dockerng
dpkg
drac
dracr
drbd
ebuild
eix
@ -103,6 +106,7 @@ Full list of builtin execution modules
freebsdpkg
freebsdports
freebsdservice
fsutils
gem
genesis
gentoo_service
@ -130,6 +134,7 @@ Full list of builtin execution modules
incron
influx
ini_manage
inspectlib
introspect
ipmi
ipset
@ -144,6 +149,7 @@ Full list of builtin execution modules
kmod
launchctl
layman
ldap3
ldapmod
linux_acl
linux_lvm
@ -257,6 +263,7 @@ Full list of builtin execution modules
shadow
slack_notify
smartos_imgadm
smartos_virt
smartos_vmadm
smbios
smf
@ -286,6 +293,7 @@ Full list of builtin execution modules
sysrc
system
system_profiler
system_rest_sample
systemd
telemetry
temp

6
doc/ref/modules/all/salt.modules.chassis.rst Normal file
View file

@ -0,0 +1,6 @@
====================
salt.modules.chassis
====================
.. automodule:: salt.modules.chassis
:members:

6
doc/ref/modules/all/salt.modules.cytest.rst
View file

@ -1,6 +0,0 @@
===================
salt.modules.cytest
===================
.. automodule:: salt.modules.cytest
:members:

6
doc/ref/modules/all/salt.modules.debbuild.rst Normal file
View file

@ -0,0 +1,6 @@
=====================
salt.modules.debbuild
=====================
.. automodule:: salt.modules.debbuild
:members:

6
doc/ref/modules/all/salt.modules.dracr.rst Normal file
View file

@ -0,0 +1,6 @@
==================
salt.modules.dracr
==================
.. automodule:: salt.modules.dracr
:members:

6
doc/ref/modules/all/salt.modules.fsutils.rst Normal file
View file

@ -0,0 +1,6 @@
====================
salt.modules.fsutils
====================
.. automodule:: salt.modules.fsutils
:members:

6
doc/ref/modules/all/salt.modules.inspectlib.collector.rst Normal file
View file

@ -0,0 +1,6 @@
salt.modules.inspectlib.collector module
========================================
.. automodule:: salt.modules.inspectlib.collector
:members:
:undoc-members:

6
doc/ref/modules/all/salt.modules.inspectlib.dbhandle.rst Normal file
View file

@ -0,0 +1,6 @@
salt.modules.inspectlib.dbhandle module
=======================================
.. automodule:: salt.modules.inspectlib.dbhandle
:members:
:undoc-members:

6
doc/ref/modules/all/salt.modules.inspectlib.exceptions.rst Normal file
View file

@ -0,0 +1,6 @@
salt.modules.inspectlib.exceptions module
=========================================
.. automodule:: salt.modules.inspectlib.exceptions
:members:
:undoc-members:

6
doc/ref/modules/all/salt.modules.inspectlib.query.rst Normal file
View file

@ -0,0 +1,6 @@
salt.modules.inspectlib.query module
====================================
.. automodule:: salt.modules.inspectlib.query
:members:
:undoc-members:

19
doc/ref/modules/all/salt.modules.inspectlib.rst Normal file
View file

@ -0,0 +1,19 @@
salt.modules.inspectlib package
===============================
Submodules
----------
.. toctree::
salt.modules.inspectlib.collector
salt.modules.inspectlib.dbhandle
salt.modules.inspectlib.exceptions
salt.modules.inspectlib.query
Module contents
---------------
.. automodule:: salt.modules.inspectlib
:members:
:undoc-members:

6
doc/ref/modules/all/salt.modules.ldap3.rst Normal file
View file

@ -0,0 +1,6 @@
==================
salt.modules.ldap3
==================
.. automodule:: salt.modules.ldap3
:members:

6
doc/ref/modules/all/salt.modules.smartos_virt.rst Normal file
View file

@ -0,0 +1,6 @@
=========================
salt.modules.smartos_virt
=========================
.. automodule:: salt.modules.smartos_virt
:members:

6
doc/ref/modules/all/salt.modules.system_rest_sample.rst Normal file
View file

@ -0,0 +1,6 @@
===============================
salt.modules.system_rest_sample
===============================
.. automodule:: salt.modules.system_rest_sample
:members:

159
doc/ref/modules/index.rst
View file

@ -1,3 +1,5 @@
.. _execution-modules:
=================
Execution Modules
=================
@ -128,8 +130,10 @@ Once placed in :conf_master:`file_roots`, Salt users can distribute and use ``lu
.. _`Python package`: https://docs.python.org/2/tutorial/modules.html#packages
Cross-Calling Modules
=====================
.. _cross-calling-execution-modules:
Cross Calling Execution Modules
===============================
All of the Salt execution modules are available to each other and modules can call
functions available in other execution modules.
@ -148,8 +152,8 @@ Salt modules can be cross-called by accessing the value in the ``__salt__`` dict
def foo(bar):
return __salt__['cmd.run'](bar)
This code will call the `run` function in the :mod:`cmd <salt.modules.cmdmod>` and pass the argument
``bar`` to it.
This code will call the `run` function in the :mod:`cmd <salt.modules.cmdmod>`
module and pass the argument ``bar`` to it.
Preloaded Execution Module Data
@ -221,35 +225,91 @@ This will ensure that the text outputter is used.
Virtual Modules
===============
Sometimes an execution module should be presented in a generic way. A good example of this
can be found in the package manager modules. The package manager changes from
one operating system to another, but the Salt execution module that interfaces with the
package manager can be presented in a generic way.
Virtual modules let you override the name of a module in order to use the same
name to refer to one of several similar modules. The specific module that is
loaded for a virtual name is selected based on the current platform or
environment.
The Salt modules for package managers all contain a ``__virtual__`` function
which is called to define what systems the module should be loaded on.
For example, packages are managed across platforms using the ``pkg`` module.
``pkg`` is a virtual module name that is
an alias for the specific package manager module that is loaded on a specific
system (for example, :mod:`yumpkg <salt.modules.yumpkg>` on RHEL/CentOS systems
, and :mod:`aptpkg <salt.modules.aptpkg>` on Ubuntu).
The ``__virtual__`` function is used to return either a
:ref:`string <python2:typesseq>` or :py:data:`False`. If
False is returned then the module is not loaded, if a string is returned then
the module is loaded with the name of the string.
Virtual module names are set using the ``__virtual__`` function and the
:ref:`virtual name <modules-virtual-name>`.
.. note::
``__virtual__`` Function
========================
Optionally, modules may additionally return a list of reasons that a module could
not be loaded. For example, if a dependency for 'my_mod' was not met, a
__virtual__ function could do as follows:
return False, ['My Module must be installed before this module can be
used.']
This means that the package manager modules can be presented as the ``pkg`` module
regardless of what the actual module is named.
The ``__virtual__`` function returns either a :ref:`string <python2:typesseq>`,
:py:data:`True`, :py:data:`False`, or :py:data:`False` with an :ref:`error
string <modules-error-info>`. If a string is returned then the module is loaded
using the name of the string as the virtual name. If ``True`` is returned the
module is loaded using the current module name. If ``False`` is returned the
module is not loaded. ``False`` lets the module perform system checks and
prevent loading if dependencies are not met.
Since ``__virtual__`` is called before the module is loaded, ``__salt__`` will be
unavailable as it will not have been packed into the module at this point in time.
The package manager modules are among the best example of using the ``__virtual__``
.. note::
Modules which return a string from ``__virtual__`` that is already used by a module that
ships with Salt will _override_ the stock module.
.. _modules-error-info:
Returning Error Information from ``__virtual__``
------------------------------------------------
Optionally, Salt plugin modules, such as execution, state, returner, beacon,
etc. modules may additionally return a string containing the reason that a
module could not be loaded. For example, an execution module called ``cheese``
and a corresponding state module also called ``cheese``, both depending on a
utility called ``enzymes`` should have ``__virtual__`` functions that handle
the case when the dependency is unavailable.
.. code-block:: python
'''
Cheese execution (or returner/beacon/etc.) module
'''
try:
import enzymes
HAS_ENZYMES = True
except ImportError:
HAS_ENZYMES = False
def __virtual__():
'''
only load cheese if enzymes are available
'''
if HAS_ENZYMES:
return 'cheese'
else:
return (False, 'The cheese execution module cannot be loaded: enzymes unavailable.')
.. code-block:: python
'''
Cheese state module
'''
def __virtual__():
'''
only load cheese if enzymes are available
'''
# predicate loading of the cheese state on the corresponding execution module
if 'cheese.slice' in __salt__:
return 'cheese'
else:
return (False, 'The cheese state module cannot be loaded: enzymes unavailable.')
Examples
--------
The package manager modules are among the best examples of using the ``__virtual__``
function. Some examples:
- :blob:`pacman.py <salt/modules/pacman.py>`
@ -257,9 +317,34 @@ function. Some examples:
- :blob:`aptpkg.py <salt/modules/aptpkg.py>`
- :blob:`at.py <salt/modules/at.py>`
.. note::
Modules which return a string from ``__virtual__`` that is already used by a module that
ships with Salt will _override_ the stock module.
.. _modules-virtual-name:
``__virtualname__``
===================
``__virtualname__`` is a variable that is used by the documentation build
system to know the virtual name of a module without calling the ``__virtual__``
function. Modules that return a string from the ``__virtual__`` function
must also set the ``__virtualname__`` variable.
To avoid setting the virtual name string twice, you can implement
``__virtual__`` to return the value set for ``__virtualname__`` using a pattern
similar to the following:
.. code-block:: python
# Define the module's virtual name
__virtualname__ = 'pkg'
def __virtual__():
'''
Confine this module to Mac OS with Homebrew.
'''
if salt.utils.which('brew') and __grains__['os'] == 'MacOS':
return __virtualname__
return False
Documentation
@ -329,6 +414,22 @@ on.
The platform field is a comma-delimited list of platforms that this module is
known to run on.
Log Output
==========
You can call the logger from custom modules to write messages to the minion
logs. The following code snippet demonstrates writing log messages:
.. code-block:: python
import logging
log = logging.getLogger(__name__)
log.info('Here is Some Information')
log.warning('You Should Not Do That')
log.error('It Is Busted')
Private Functions
=================
@ -417,7 +518,7 @@ If a "fallback_function" is defined, it will replace the function instead of rem
'''
return True
In addition to global dependancies the depends decorator also supports raw booleans.
In addition to global dependencies the depends decorator also supports raw booleans.
.. code-block:: python

6
doc/ref/netapi/all/salt.netapi.rest_cherrypy.app.rst Normal file
View file

@ -0,0 +1,6 @@
salt.netapi.rest_cherrypy.app module
====================================
.. automodule:: salt.netapi.rest_cherrypy.app
:members:
:undoc-members:

6
doc/ref/netapi/all/salt.netapi.rest_cherrypy.wsgi.rst Normal file
View file

@ -0,0 +1,6 @@
salt.netapi.rest_cherrypy.wsgi module
=====================================
.. automodule:: salt.netapi.rest_cherrypy.wsgi
:members:
:undoc-members:

6
doc/ref/netapi/all/salt.netapi.rest_tornado.saltnado.rst Normal file
View file

@ -0,0 +1,6 @@
salt.netapi.rest_tornado.saltnado module
========================================
.. automodule:: salt.netapi.rest_tornado.saltnado
:members:
:undoc-members:

6
doc/ref/netapi/all/salt.netapi.rest_tornado.saltnado_websockets.rst Normal file
View file

@ -0,0 +1,6 @@
salt.netapi.rest_tornado.saltnado_websockets module
===================================================
.. automodule:: salt.netapi.rest_tornado.saltnado_websockets
:members:
:undoc-members:

8
doc/ref/pillar/all/salt.pillar.consul_pillar.rst
View file

@ -1,6 +1,6 @@
=========================
salt.pillar.consul_pillar
=========================
salt.pillar.consul_pillar module
================================
.. automodule:: salt.pillar.consul_pillar
:members:
:members:
:undoc-members:

8
doc/ref/pillar/all/salt.pillar.neutron.rst
View file

@ -1,6 +1,6 @@
===================
salt.pillar.neutron
===================
salt.pillar.neutron module
==========================
.. automodule:: salt.pillar.neutron
:members:
:members:
:undoc-members:

8
doc/ref/pillar/all/salt.pillar.sql_base.rst
View file

@ -1,6 +1,6 @@
====================
salt.pillar.sql_base
====================
salt.pillar.sql_base module
===========================
.. automodule:: salt.pillar.sql_base
:members:
:members:
:undoc-members:

8
doc/ref/pillar/all/salt.pillar.sqlite3.rst
View file

@ -1,6 +1,6 @@
===================
salt.pillar.sqlite3
===================
salt.pillar.sqlite3 module
==========================
.. automodule:: salt.pillar.sqlite3
:members:
:members:
:undoc-members:

15
doc/ref/proxy/all/index.rst Normal file
View file

@ -0,0 +1,15 @@
.. _all-salt.proxy:
==================================
Full list of builtin proxy modules
==================================
.. currentmodule:: salt.proxy
.. autosummary::
:toctree:
:template: autosummary.rst.tmpl
fx2
junos
rest_sample

6
doc/ref/proxy/all/salt.proxy.fx2.rst Normal file
View file

@ -0,0 +1,6 @@
==============
salt.proxy.fx2
==============
.. automodule:: salt.proxy.fx2
:members:

6
doc/ref/proxy/all/salt.proxy.junos.rst Normal file
View file

@ -0,0 +1,6 @@
salt.proxy.junos module
=======================
.. automodule:: salt.proxy.junos
:members:
:undoc-members:

6
doc/ref/proxy/all/salt.proxy.rest_sample.rst Normal file
View file

@ -0,0 +1,6 @@
salt.proxy.rest_sample module
=============================
.. automodule:: salt.proxy.rest_sample
:members:
:undoc-members:

31
doc/ref/clientacl.rst → doc/ref/publisheracl.rst
View file

@ -1,19 +1,20 @@
=================
Client ACL system
=================
====================
Publisher ACL system
====================
The salt client 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.
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.
The client ACL system is configured in the master configuration file via the
``client_acl`` configuration option. Under the ``client_acl`` configuration
option the users open to send commands are specified and then a list of regular
expressions which specify the minion functions which will be made available to
specified user. This configuration is much like the ``peer`` configuration:
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 regular expressions which specify the minion functions which will be
made available to specified user. This configuration is much like the ``peer``
configuration:
.. code-block:: yaml
client_acl:
publisher_acl:
# Allow thatch to execute anything.
thatch:
- .*
@ -23,11 +24,15 @@ specified user. This configuration is much like the ``peer`` configuration:
- test.*
- pkg.*
WARNING: client_acl and client_acl_blacklist options are deprecated and will be
removed in the future releases. Use publisher_acl and publisher_acl_blacklist
instead.
Permission Issues
=================
Directories required for ``client_acl`` must be modified to be readable by the
users specified:
Directories required for ``publisher_acl`` must be modified to be readable by
the users specified:
.. code-block:: bash

6
doc/ref/queues/all/salt.queues.sqlite_queue.rst Normal file
View file

@ -0,0 +1,6 @@
salt.queues.sqlite_queue module
===============================
.. automodule:: salt.queues.sqlite_queue
:members:
:undoc-members:

1
doc/ref/runners/all/index.rst
View file

@ -34,6 +34,7 @@ Full list of runner modules
queue
reactor
sdb
ssh
search
spacewalk
ssh

8
doc/ref/sdb/all/salt.sdb.rest.rst
View file

@ -1,6 +1,6 @@
=============
salt.sdb.rest
=============
salt.sdb.rest module
====================
.. automodule:: salt.sdb.rest
:members:
:members:
:undoc-members:

2
doc/ref/states/all/index.rst
View file

@ -50,6 +50,7 @@ Full list of builtin state modules
cyg
ddns
debconfmod
dellchassis
disk
dockerio
dockerng
@ -87,6 +88,7 @@ Full list of builtin state modules
keystone
kmod
layman
ldap
libvirt
linux_acl
locale

6
doc/ref/states/all/salt.states.apt.rst
View file

@ -1,6 +0,0 @@
===============
salt.states.apt
===============
.. automodule:: salt.states.apt
:members:

6
doc/ref/states/all/salt.states.dellchassis.rst Normal file
View file

@ -0,0 +1,6 @@
=======================
salt.states.dellchassis
=======================
.. automodule:: salt.states.dellchassis
:members:

6
doc/ref/states/all/salt.states.glance.rst Normal file
View file

@ -0,0 +1,6 @@
==================
salt.states.glance
==================
.. automodule:: salt.states.glance
:members:

6
doc/ref/states/all/salt.states.ldap.rst Normal file
View file

@ -0,0 +1,6 @@
================
salt.states.ldap
================
.. automodule:: salt.states.ldap
:members:

4
doc/ref/states/ordering.rst
View file

@ -38,7 +38,9 @@ override the ordering defined in the files, and the ``order`` option described
below will also override the order in which states are defined in sls files.
If the classic ordering is preferred (lexicographic), then set
``state_auto_order`` to ``False`` in the master configuration file.
``state_auto_order`` to ``False`` in the master configuration file. Otherwise,
``state_auto_order`` defaults to ``True``.
.. _ordering_requisites:

21
doc/ref/states/requisites.rst
View file

@ -4,6 +4,8 @@
Requisites and Other Global State Arguments
===========================================
.. _requisites-fire-event:
Fire Event Notifications
========================
@ -450,7 +452,7 @@ The state altering system is used to make sure that states are evaluated exactly
as the user expects. It can be used to double check that a state preformed
exactly how it was expected to, or to make 100% sure that a state only runs
under certain conditions. The use of unless or onlyif options help make states
even more stateful. The check_cmds option helps ensure that the result of a
even more stateful. The ``check_cmd`` option helps ensure that the result of a
state is evaluated correctly.
Unless
@ -600,16 +602,19 @@ same privileges as the salt-minion.
- pattern: ^enabled=0
- repl: enabled=1
- check_cmd:
- grep 'enabled=0' /etc/yum.repos.d/fedora.repo && exit 1 || exit 0
- ! grep 'enabled=0' /etc/yum.repos.d/fedora.repo
This will attempt to do a replace on all enabled=0 in the .repo file, and
replace them with enabled=1. The check_cmd is just a bash command. It will do
a grep for enabled=0 in the file, and if it finds any, it will return a 0, which
will prompt the && portion of the command to return a 1, causing check_cmd to
set the state as failed. If it returns a 1, meaning it didn't find any
'enabled=0' it will hit the || portion of the command, returning a 0, and
This will attempt to do a replace on all ``enabled=0`` in the .repo file, and
replace them with ``enabled=1``. The ``check_cmd`` is just a bash command. It
will do a grep for ``enabled=0`` in the file, and if it finds any, it will
return a 0, which will be inverted by the leading ``!``, causing ``check_cmd``
to set the state as failed. If it returns a 1, meaning it didn't find any
``enabled=0``, it will be inverted by the leading ``!``, returning a 0, and
declaring the function succeeded.
**NOTE**: This requisite ``check_cmd`` functions differently than the ``check_cmd``
of the ``file.managed`` state.
Overriding Checks
-----------------

90
doc/ref/states/top.rst
View file

@ -19,11 +19,11 @@ that the Apache service should always be running.
In Salt, the file which contains a mapping between groups of machines on a
network and the configuration roles that should be applied to them is
called a `top file`.
called a ``top file``.
Top files are named `top.sls` by default and they are so-named because they
Top files are named ``top.sls`` by default and they are so-named because they
always exist in the "top" of a directory hierarchy that contains state files.
That directory hierarchy is called a `state tree`.
That directory hierarchy is called a ``state tree``.
A Basic Example
===============
@ -38,7 +38,7 @@ Top files have three components:
- State files: A list of state files to apply to a target. Each state
file describes one or more states to be configured and enforced
on the targeted machines.
on the targeted machines.
The relationship between these three components is nested as follows:
@ -49,7 +49,7 @@ The relationship between these three components is nested as follows:
Putting these concepts together, we can describe a scenario in which all
minions with an ID that begins with `web` have an `apache` state applied
minions with an ID that begins with ``web`` have an ``apache`` state applied
to them:
.. code-block:: yaml
@ -69,7 +69,7 @@ of state files.
Environments can be used in many ways, however there is no requirement that
they be used at all. In fact, the most common way to deploy Salt is with
a single environment, called `base`. It is recommended that users only
a single environment, called ``base``. It is recommended that users only
create multiple environments if they have a use case which specifically
calls for multiple versions of state trees.
@ -77,7 +77,7 @@ calls for multiple versions of state trees.
Getting Started with Top Files
==============================
Each environment is defined inside a salt master configuration variable
Each environment is defined inside a salt master configuration variable
called, :conf_master:`file_roots` .
@ -96,9 +96,9 @@ In the above example, the top file will only have a single environment to pull
from.
Next is a simple single-environment top file placed in `/srv/salt/top.sls`,
illustrating that for the environment called `base`, all minions will have the
state files named `core.sls` and `edit.sls` applied to them.
Next is a simple single-environment top file placed in ``/srv/salt/top.sls``,
illustrating that for the environment called ``base``, all minions will have the
state files named ``core.sls`` and ``edit.sls`` applied to them.
.. code-block:: yaml
@ -107,8 +107,8 @@ state files named `core.sls` and `edit.sls` applied to them.
- core
- edit
Assuming the `file_roots` configuration from above, Salt will look in the
`/srv/salt` directory for `core.sls` and `edit.sls`.
Assuming the ``file_roots`` configuration from above, Salt will look in the
``/srv/salt`` directory for ``core.sls`` and ``edit.sls``.
Multiple Environments
@ -134,7 +134,7 @@ expanded:
prod:
- /srv/salt/prod
In the above, we declare three environments: `dev`, `qa` and `prod`.
In the above, we declare three environments: ``dev``, ``qa`` and ``prod``.
Each environment has a single directory assigned to it.
Our top file references the environments:
@ -159,12 +159,12 @@ Our top file references the environments:
As seen above, the top file now declares the three environments and for each,
targets are defined to map globs of minion IDs to state files. For example,
all minions which have an ID beginning with the string `webserver` will have the
all minions which have an ID beginning with the string ``webserver`` will have the
webserver state from the requested environment assigned to it.
In this manner, a proposed change to a state could first be made in a state
file in `/srv/salt/dev` and the applied to development webservers before moving
the state into QA by copying the state file into `/srv/salt/qa`.
file in ``/srv/salt/dev`` and then be applied to development webservers before
moving the state into QA by copying the state file into ``/srv/salt/qa``.
Choosing an Environment to Target
@ -177,19 +177,19 @@ applied to that minion. The states that will be applied to a minion in a given
environment can be viewed using the :py:func:`state.show_top
<salt.modules.state.show_top>` execution function.
Minions may be pinned to a particular environment by setting the `environment`
Minions may be pinned to a particular environment by setting the ``environment``
value in the minion configuration file. In doing so, a minion will only
request files from the environment to which it is assigned.
The environment to use may also be dynamically selected at the time that
a `salt`, `salt-call` or `salt-ssh` by passing passing a flag to the
a ``salt``, ``salt-call`` or ``salt-ssh`` by passing passing a flag to the
execution module being called. This is most commonly done with
functions in the `state` module by using the `saltenv=` argument. For
example, to run a `highstate` on all minions, using the state files in
the `prod` state tree, run: `salt '*' state.highstate saltenv=prod`.
functions in the ``state`` module by using the ``saltenv=`` argument. For
example, to run a ``highstate`` on all minions, using the state files in
the ``prod`` state tree, run: ``salt '*' state.highstate saltenv=prod``.
.. note::
Not all functions accept `saltenv` as an argument See individual
Not all functions accept ``saltenv`` as an argument See individual
function documentation to verify.
@ -227,7 +227,7 @@ of matches you can perform:
.. code-block:: yaml
# All files will be taken from the file path specified in the base
# environment in the `file_roots` configuration value.
# environment in the ``file_roots`` configuration value.
base:
# All minions get the following three state files applied
@ -237,11 +237,11 @@ of matches you can perform:
- networking
- salt.minion
# All minions which have an ID that begins with the phrase
# All minions which have an ID that begins with the phrase
# 'salt-master' will have an SLS file applied that is named
# 'master.sls' and is in the 'salt' directory, underneath
# the root specified in the `base` environment in the
# configuration value for `file_roots`.
# the root specified in the ``base`` environment in the
# configuration value for ``file_roots``.
'salt-master*':
- salt.master
@ -251,8 +251,8 @@ of matches you can perform:
# nagios/mon directory applied. Additionally, minions matching
# the regular expression will also have the 'server.sls' file
# in the apache/ directory applied.
# NOTE!
# NOTE!
#
# Take note of the 'match' directive here, which tells Salt
# to treat the target string as a regex to be matched!
@ -310,16 +310,17 @@ each environment. The most common approach, and the easiest to maintain, is
to use a single top file placed in only one environment.
However, some workflows do call for multiple top files. In this case, top
files may be merged together to create `high data` for the state compiler
files may be merged together to create ``high data`` for the state compiler
to use as a source to compile states on a minion.
For the following discussion of top file compilation, assume the following
configuration:
``/etc/salt/master``
``/etc/salt/master``:
.. code-block:: yaml
<snip>
file_roots:
first_env:
@ -328,7 +329,8 @@ configuration:
- /srv/salt/second
``/srv/salt/first/top.sls:``
``/srv/salt/first/top.sls``:
.. code-block:: yaml
first_env:
@ -342,23 +344,27 @@ The astute reader will ask how the state compiler resolves which should be
an obvious conflict if a minion is not pinned to a particular environment
and if no environment argument is passed into a state function.
Given the above, it is initially unclear whether `first.sls` will be applied
or whether `second.sls` will be applied in a `salt '*' state.highstate` command.
Given the above, it is initially unclear whether ``first.sls`` will be applied
or whether ``second.sls`` will be applied in a ``salt '*' state.highstate`` command.
When conflicting keys arise, there are several configuration options which
control the behaviour of salt:
- `env_order`
Setting `env_order` will set the order in which environments are processed
- ``env_order``
Setting ``env_order`` will set the order in which environments are processed
by the state compiler.
- `top_file_merging_strategy`
Can be set to `same`, which will process only the top file from the environment
that the minion belongs to via the `environment` configuration setting or
the environment that is requested via the `saltenv` argument supported
by some functions in the `state` module.
- ``top_file_merging_strategy``
Can be set to ``same``, which will process only the top file from the environment
that the minion belongs to via the ``environment`` configuration setting or
the environment that is requested via the ``saltenv`` argument supported
by some functions in the ``state`` module.
Can also be set to `merge`. This is the default. When set to `merge`,
Can also be set to ``merge``. This is the default. When set to ``merge``,
top files will be merged together. The order in which top files are
merged together can be controlled with `env_order`.
merged together can be controlled with ``env_order``.
- ``default_top``
If ``top_file_merging_strategy`` is set to ``same`` and an environment does
not contain a top file, the top file in the environment specified by
``default_top`` will be used instead.

54
doc/ref/states/writing.rst
View file

@ -1,3 +1,5 @@
.. _state-modules:
=============
State Modules
=============
@ -5,6 +7,8 @@ State Modules
State Modules are the components that map to actual enforcement and management
of Salt states.
.. _writing-state-modules:
States are Easy to Write!
=========================
@ -63,12 +67,12 @@ state with the same name. Note that a state's default name is its filename
(i.e. ``foo.py`` becomes state ``foo``), but that its name can be overridden
by using a :ref:`__virtual__ function <virtual-modules>`.
Cross Calling Modules
=====================
Cross Calling Execution Modules from States
===========================================
As with Execution Modules, State Modules can also make use of the ``__salt__``
and ``__grains__`` data.
and ``__grains__`` data. See :ref:`cross calling execution modules
<cross-calling-execution-modules>`.
It is important to note that the real work of state management should not be
done in the state module unless it is needed. A good example is the pkg state
@ -82,6 +86,31 @@ state module, a good example of this is the file module. But in the vast
majority of cases this is not the best approach, and writing specific
execution modules to do the backend work will be the optimal solution.
.. _cross-calling-state-modules:
Cross Calling State Modules
===========================
All of the Salt state modules are available to each other and state modules can call
functions available in other state modules.
The variable ``__states__`` is packed into the modules after they are loaded into
the Salt minion.
The ``__states__`` variable is a :ref:`Python dictionary <python2:typesmapping>`
containing all of the state modules. Dictionary keys are strings representing the
names of the modules and the values are the functions themselves.
Salt state modules can be cross-called by accessing the value in the ``__states__`` dict:
.. code-block:: python
ret = __states__['file.managed'](name='/tmp/myfile', source='salt://myfile')
This code will call the `managed` function in the :mod:`file
<salt.states.file>` state module and pass the arguments ``name`` and ``source``
to it.
Return Data
===========
@ -203,6 +232,23 @@ prepared to refresh, then return True and the mod_init will not be called
the next time a pkg state is evaluated, otherwise return False and the mod_init
will be called next time a pkg state is evaluated.
Log Output
==========
You can call the logger from custom modules to write messages to the minion
logs. The following code snippet demonstrates writing log messages:
.. code-block:: python
import logging
log = logging.getLogger(__name__)
log.info('Here is Some Information')
log.warning('You Should Not Do That')
log.error('It Is Busted')
Full State Module Example
=========================

188
doc/topics/beacons/index.rst
View file

@ -4,20 +4,35 @@
Beacons
=======
The beacon system allows the minion to hook into system processes and
continually translate external events into the salt event bus. The
primary example of this is the :py:mod:`~salt.beacons.inotify` beacon. This
beacon uses inotify to watch configured files or directories on the minion for
changes, creation, deletion etc.
The beacon system allows the minion to hook into a variety of system processes
and continually monitor these processes. When monitored activity occurs in
a system process, an event is sent on the Salt event bus that can
be used to trigger a :ref:`reactor <reactor>`.
This allows for the changes to be sent up to the master where the
reactor can respond to changes.
Salt beacons can currently monitor and send Salt events for many system
activities, including:
Configuring The Beacons
=======================
- file system changes
- system load
- service status
- shell activity, such as user login
- network and disk usage
The beacon system, like many others in Salt, can be configured via the
minion pillar, grains, or local config file:
See :ref:`beacon modules <all-salt.beacons>` for a current list.
.. note::
Salt beacons are an event generation mechanism. Beacons leverage the Salt
:ref:`reactor <reactor>` system to make changes when beacon events occur.
Configuring Beacons
===================
Salt beacons do not require any changes to the system process that
is being monitored, everything is configured using Salt.
Beacons are typically enabled by placing a ``beacons:`` top level block in the
minion configuration file:
.. code-block:: yaml
@ -26,11 +41,15 @@ minion pillar, grains, or local config file:
/etc/httpd/conf.d: {}
/opt: {}
Optionally, a beacon can be run on an interval other than the default
``loop_interval``, which is typically set to 1 second.
The beacon system, like many others in Salt, can also be configured via the
minion pillar, grains, or local config file.
To run a beacon every 5 seconds, for example, provide an ``interval`` argument
to a beacon.
Beacon Monitoring Interval
--------------------------
Beacons monitor on a 1-second interval by default. To set a different interval,
provide an ``interval`` argument to a beacon. The following beacons run on
5- and 10-second intervals:
.. code-block:: yaml
@ -51,6 +70,145 @@ to a beacon.
- 1.0
- interval: 10
Avoiding Event Loops
--------------------
It is important to carefully consider the possibility of creating a loop
between a reactor and a beacon. For example, one might set up a beacon
which monitors whether a file is read which in turn fires a reactor to
run a state which in turn reads the file and re-fires the beacon.
To avoid these types of scenarios, the ``disable_during_state_run``
argument may be set. If a state run is in progress, the beacon will
not be run on its regular interval until the minion detects that the
state run has completed, at which point the normal beacon interval
will resume.
.. code-block:: yaml
beacons:
inotify:
/etc/passwd: {}
disable_during_state_run: True
Beacon Example
==============
This example demonstrates configuring the :py:mod:`~salt.beacons.inotify`
beacon to monitor a file for changes, and then create a backup each time
a change is detected.
.. note::
The inotify beacon requires Pyinotify on the minion, install it using
``salt myminion pkg.install python-inotify``.
First, on the Salt minion, add the following beacon configuration to
``/ect/salt/minion``:
.. code-block:: yaml
beacons:
inotify:
home/user/importantfile:
mask:
- modify
Replace ``user`` in the previous example with the name of your user account,
and then save the configuration file and restart the minion service.
Next, create a file in your home directory named ``importantfile`` and add some
simple content. The beacon is now set up to monitor this file for
modifications.
View Events on the Master
-------------------------
On your Salt master, start the event runner using the following command:
.. code-block:: bash
salt-run state.event pretty=true
This runner displays events as they are received on the Salt event bus. To test
the beacon you set up in the previous section, make and save
a modification to the ``importantfile`` you created. You'll see an event
similar to the following on the event bus:
.. code-block:: json
salt/beacon/minion1/inotify/home/user/importantfile {
"_stamp": "2015-09-09T15:59:37.972753",
"data": {
"change": "IN_IGNORED",
"id": "minion1",
"path": "/home/user/importantfile"
},
"tag": "salt/beacon/minion1/inotify/home/user/importantfile"
}
This indicates that the event is being captured and sent correctly. Now you can
create a reactor to take action when this event occurs.
Create a Reactor
----------------
On your Salt master, create a file named ``srv/reactor/backup.sls``. If the
``reactor`` directory doesn't exist, create it. Add the following to ``backup.sls``:
.. code-block:: yaml
backup file:
cmd.file.copy:
- tgt: {{ data['data']['id'] }}
- arg:
- {{ data['data']['path'] }}
- {{ data['data']['path'] }}.bak
Next, add the code to trigger the reactor to ``ect/salt/master``:
.. code-block:: yaml
reactor:
- salt/beacon/*/inotify/*/importantfile:
- /srv/reactor/backup.sls
This reactor creates a backup each time a file named ``importantfile`` is
modified on a minion that has the :py:mod:`~salt.beacons.inotify` beacon
configured as previously shown.
.. note::
You can have only one top level ``reactor`` section, so if one already
exists, add this code to the existing section. See :ref:`Understanding
the Structure of Reactor Formulas <reactor-structure>` to learn more about
reactor SLS syntax.
Start the Salt Master in Debug Mode
-----------------------------------
To help with troubleshooting, start the Salt master in debug mode:
.. code-block:: yaml
service salt-master stop
salt-master -l debug
When debug logging is enabled, event and reactor data are displayed so you can
discover syntax and other issues.
Trigger the Reactor
-------------------
On your minion, make and save another change to ``importantfile``. On the Salt
master, you'll see debug messages that indicate the event was received and the
``file.copy`` job was sent. When you list the directory on the minion, you'll now
see ``importantfile.bak``.
All beacons are configured using a similar process of enabling the beacon,
writing a reactor SLS, and mapping a beacon event to the reactor SLS.
Writing Beacon Plugins
======================

2
doc/topics/best_practices.rst
View file

@ -154,7 +154,7 @@ creates a consistent understanding throughout our Salt environment. Users can
expect that pillar variables found in an Apache state will live inside of an
Apache pillar:
``/srv/salt/pillar/apache.sls``:
``/srv/pillar/apache.sls``:
.. code-block:: yaml

22
doc/topics/cloud/aws.rst
View file

@ -118,7 +118,7 @@ parameters are discussed in more detail below.
keyname: my_test_key
# This one should NOT be specified if VPC was not configured in AWS to be
# the default. It might cause an error message which sais that network
# the default. It might cause an error message which says that network
# interfaces and an instance-level security groups may not be specified
# on the same request.
#
@ -554,17 +554,6 @@ function exists which renames both the instance, and the salt keys.
salt-cloud -a rename mymachine newname=yourmachine
EC2 Termination Protection
==========================
EC2 allows the user to enable and disable termination protection on a specific
instance. An instance with this protection enabled cannot be destroyed.
.. code-block:: bash
salt-cloud -a enable_term_protect mymachine
salt-cloud -a disable_term_protect mymachine
Rename on Destroy
=================
When instances on EC2 are destroyed, there will be a lag between the time that
@ -901,6 +890,13 @@ point, and should be stored immediately.
salt-cloud -f create_keypair ec2 keyname=mykeypair
Importing a Key Pair
-------------------
.. code-block:: bash
salt-cloud -f import_keypair ec2 keyname=mykeypair file=/path/to/id_rsa.pub
Show a Key Pair
---------------
@ -973,7 +969,7 @@ the network interfaces of your virtual machines, for example:-
# Uncomment this to associate an existing Elastic IP Address with
# this network interface:
#
# associate_eip: eni-XXXXXXXX
# associate_eip: eipalloc-XXXXXXXX
# You can allocate more than one IP address to an interface. Use the
# 'ip addr list' command to see them.

16
doc/topics/cloud/azure.rst
View file

@ -14,13 +14,25 @@ More information about Azure is located at `http://www.windowsazure.com/
Dependencies
============
* The `Azure <https://pypi.python.org/pypi/azure>`_ Python SDK >= 0.11.1.
* The `Azure <https://pypi.python.org/pypi/azure>`_ Python SDK >= 0.10.2 and < 1.0.0
* The python-requests library, for Python < 2.7.9.
* A Microsoft Azure account
* OpenSSL (to generate the certificates)
* `Salt <https://github.com/saltstack/salt>`_
.. note::
The Azure driver is currently being updated to work with the new version of
the Python Azure SDK, 1.0.0. However until that process is complete, this
driver will not work with Azure 1.0.0. Please be sure you're running on a
minimum version of 0.10.2 and less than version 1.0.0.
See `Issue #27980`_ for more information.
.. _Issue #27980: https://github.com/saltstack/salt/issues/27980
Configuration
=============
@ -1442,7 +1454,7 @@ Required if the blob has an active lease.
progress_callback
`````````````````
callback for progress with signature function(current, total) where
current is the number of bytes transfered so far, and total is the
current is the number of bytes transferred so far, and total is the
size of the blob.
max_connections

36
doc/topics/cloud/config.rst
View file

@ -229,7 +229,7 @@ Amazon AWS
----------
A number of configuration options are required for Amazon AWS including ``id``,
``key``, ``keyname``, ``sercuritygroup``, and ``private_key``:
``key``, ``keyname``, ``securitygroup``, and ``private_key``:
.. code-block:: yaml
@ -500,35 +500,11 @@ And in the map file:
Saltify
-------
The Saltify driver is a new, experimental driver for installing Salt on
existing machines (virtual or bare metal). Because it does not use an actual
cloud provider, it needs no configuration in the main cloud config file.
However, it does still require a profile to be set up, and is most useful when
used inside a map file. The key parameters to be set are ``ssh_host``,
``ssh_username`` and either ``ssh_keyfile`` or ``ssh_password``. These may all
be set in either the profile or the map. An example configuration might use the
following in cloud.profiles:
.. code-block:: yaml
make_salty:
driver: saltify
And in the map file:
.. code-block:: yaml
make_salty:
- myinstance:
ssh_host: 54.262.11.38
ssh_username: ubuntu
ssh_keyfile: '/etc/salt/mysshkey.pem'
sudo: True
.. note::
In the cloud profile that uses this provider configuration, the syntax for the
``provider`` required field would be ``provider: make_salty``.
The Saltify driver is a new, experimental driver designed to install Salt on a remote
machine, virtual or bare metal, using SSH. This driver is useful for provisioning
machines which are already installed, but not Salted. For more information about using
this driver and for configuration examples, please see the
:ref:`Gettting Started with Saltify <getting-started-with-saltify>` documentation.
Extending Profiles and Cloud Providers Configuration

64
doc/topics/cloud/digitalocean.rst
View file

@ -45,13 +45,14 @@ Set up an initial profile at ``/etc/salt/cloud.profiles`` or in the
.. code-block:: yaml
digitalocean-ubuntu:
provider: my-digitalocean-config
image: Ubuntu 14.04 x32
size: 512MB
location: New York 1
private_networking: True
backups_enabled: True
ipv6: True
provider: my-digitalocean-config
image: 14.04 x64
size: 512MB
location: New York 1
private_networking: True
backups_enabled: True
ipv6: True
create_dns_record: True
Locations can be obtained using the ``--list-locations`` option for the ``salt-cloud``
command:
@ -117,20 +118,44 @@ command:
----------
digital_ocean:
----------
Arch Linux 2013.05 x64:
10.1:
----------
created_at:
2015-01-20T20:04:34Z
distribution:
Arch Linux
FreeBSD
id:
350424
10144573
min_disk_size:
20
name:
Arch Linux 2013.05 x64
10.1
public:
True
slug:
None
...SNIP...
Profile Specifics:
------------------
ssh_username
------------
If using a FreeBSD image from Digital Ocean, you'll need to set the ``ssh_username``
setting to ``freebsd`` in your profile configuration.
.. code-block:: yaml
digitalocean-freebsd:
provider: my-digitalocean-config
image: 10.2
size: 512MB
ssh_username: freebsd
Miscellaneous Information
=========================
.. note::
DigitalOcean's concept of ``Applications`` is nothing more than a
@ -142,10 +167,15 @@ command:
.. note::
If your domain's DNS is managed with DigitalOcean, you can automatically
create A-records for newly created droplets. Use ``create_dns_record: True``
in your config to enable this. Add ``delete_dns_record: True`` to also
delete records when a droplet is destroyed.
If your domain's DNS is managed with DigitalOcean, and your minion name
matches your DigitalOcean managed DNS domain, you can automatically create
A and AAA records for newly created droplets. Use ``create_dns_record: True``
in your config to enable this. Adding ``delete_dns_record: True`` to also
delete records when a droplet is destroyed is optional. Due to limitations
in salt-cloud design, the destroy code does not have access to the VM config
data. WHETHER YOU ADD ``create_dns_record: True`` OR NOT, salt-cloud WILL
attempt to delete your DNS records if the minion name matches. This will
prevent advertising any recycled IP addresses for destroyed minions.
.. note::

2
doc/topics/cloud/function.rst
View file

@ -27,4 +27,4 @@ gathering information about instances on a provider basis:
$ salt-cloud -f list_nodes_select linode
Another useful reference for viewing salt-cloud functions is the
:ref:Salt Cloud Feature Matrix <salt-cloud-feature-matrix>
:ref:`Salt Cloud Feature Matrix <salt-cloud-feature-matrix>`.

Some files were not shown because too many files have changed in this diff Show more