valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-08 01:18:58 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'develop' of github.com:plassa-b/salt into develop

Browse Source
This commit is contained in:
Cléry Plassat 2017-06-09 19:09:50 +02:00
commit 2b5c7fb2e1
1935 changed files with 141331 additions and 65118 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
.github/CONTRIBUTING.rst → .github/CONTRIBUTING.md vendored
View File

@ -7,7 +7,7 @@ License. We cannot accept contributions that already hold a License other
than Apache 2.0 without explicit exception.
Reporting issues
Reporting Issues
================
The Salt issue tracker is used for feature requests and bug reports.
@ -17,15 +17,16 @@ Bugs
A bug is a *demonstrable problem* that is caused by the code in the repository.
Please read the following guidelines before you `report an issue`_
Please read the following guidelines before you
[report an issue](https://github.com/saltstack/salt/issues).
1. **Use the GitHub issue search** -- check if the issue has
already been reported. If it has been, please comment on the existing issue.
2. **Check if the issue has been fixed** — Various point-release branches, such
as ``2015.5``, ``2015.8``, ``2016.3``, or even ``develop``, may already contain
a fix. Please try to reproduce the bug against the latest git HEAD or the latest
release.
as ``2016.3``, ``2016.11``, or even ``develop``, may already contain
a fix. Please try to reproduce the bug against the latest git ``HEAD`` or
the latest release.
3. **Isolate the demonstrable problem** -- make sure that the
code in the project's repository is *definitely* responsible for the issue.
@ -41,7 +42,7 @@ assess and fix any potential bugs.
**Including the output of** ``salt --versions-report`` **will always help.**
Valid bugs will be categorized for the next release and worked on as quickly
as resources can be reasonably allocated
as resources can be reasonably allocated.
Features
--------
@ -65,25 +66,23 @@ reason to ask first.
Fixing issues
=============
If you wish to help us fix the issue you're reporting, `Salt's documentation`_
If you wish to help us fix the issue you're reporting,
[Salt's documentation](http://docs.saltstack.com/en/latest/index.html)
already includes information to help you setup a development environment,
under `Developing Salt`_.
under [Developing Salt](http://docs.saltstack.com/en/latest/topics/development/hacking.html).
`SaltStack's Contributing documentation`_ is also helpful, as it explains
sending in pull requests, keeping your salt branches in sync, and knowing
`which branch`_ new features or bug fixes should be submitted against.
[SaltStack's Contributing documentation](https://docs.saltstack.com/en/latest/topics/development/contributing.html)
is also helpful, as it explains sending in pull requests, keeping your
salt branches in sync, and knowing
[which branch](https://docs.saltstack.com/en/latest/topics/development/contributing.html#which-salt-branch)
new features or bug fixes should be submitted against.
Fix the issue you have in hands, if possible also add a test case to Salt's
testing suite, create a `pull request`_, and **that's it**!
Fix the issue you have in hand and, if possible, also add a test case to Salt's
testing suite. Then, create a
[pull request](http://docs.saltstack.com/en/latest/topics/development/contributing.html#sending-a-github-pull-request),
and **that's it**!
Salt's development team will review your fix and if everything is OK, your fix
will be merged into Salt's code.
.. _`report an issue`: https://github.com/saltstack/salt/issues
.. _`Salt's documentation`: http://docs.saltstack.com/en/latest/index.html
.. _`Developing Salt`: http://docs.saltstack.com/en/latest/topics/development/hacking.html
.. _`pull request`: http://docs.saltstack.com/en/latest/topics/development/contributing.html#sending-a-github-pull-request
.. _`SaltStack's Contributing documentation`: https://docs.saltstack.com/en/latest/topics/development/contributing.html
.. _`which branch`: https://docs.saltstack.com/en/latest/topics/development/contributing.html#which-salt-branch
.. vim: set fenc=utf-8 spell spl=en:

33
.github/stale.yml vendored Normal file
View File

@ -0,0 +1,33 @@
# Probot Stale configuration file
# Number of days of inactivity before an issue becomes stale
# 1250 is approximately 3 years and 5 months
daysUntilStale: 1250
# Number of days of inactivity before a stale issue is closed
daysUntilClose: 7
# Issues with these labels will never be considered stale
#exemptLabels:
# - pinned
# - security
# Label to use when marking an issue as stale
staleLabel: stale
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment: |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.
# Comment to post when removing the stale label. Set to `false` to disable
unmarkComment: |
Thank you for updating this issue. It is no longer marked as stale.
# Comment to post when closing a stale issue. Set to `false` to disable
closeComment: false
# Limit to only `issues` or `pulls`
only: issues

5
.mention-bot Normal file
View File

@ -0,0 +1,5 @@
{
"skipTitle": "Merge forward",
"userBlacklist": ["cvrebert", "markusgattol", "olliewalsh"]
}

36
.pylintrc
View File

@ -4,15 +4,7 @@
# Python code to execute, usually for sys.path manipulation such as
# pygtk.require().
init-hook="
exec 'aW1wb3J0IG9zLCBzeXMKCmlmICdWSVJUVUFMX0VOVicgaW4gb3MuZW52aXJvbjoKCiAgICB2ZV9k \
aXIgPSBvcy5lbnZpcm9uWydWSVJUVUFMX0VOViddCiAgICB2ZV9kaXIgaW4gc3lzLnBhdGggb3Ig \
c3lzLnBhdGguaW5zZXJ0KDAsIHZlX2RpcikKICAgIGFjdGl2YXRlX3RoaXMgPSBvcy5wYXRoLmpv \
aW4ob3MucGF0aC5qb2luKHZlX2RpciwgJ2JpbicpLCAnYWN0aXZhdGVfdGhpcy5weScpCgogICAg \
IyBGaXggZm9yIHdpbmRvd3MKICAgIGlmIG5vdCBvcy5wYXRoLmV4aXN0cyhhY3RpdmF0ZV90aGlz \
KToKICAgICAgICBhY3RpdmF0ZV90aGlzID0gb3MucGF0aC5qb2luKG9zLnBhdGguam9pbih2ZV9k \
aXIsICdTY3JpcHRzJyksICdhY3RpdmF0ZV90aGlzLnB5JykKCiAgICBleGVjZmlsZShhY3RpdmF0 \
ZV90aGlzLCBkaWN0KF9fZmlsZV9fPWFjdGl2YXRlX3RoaXMpKQo='.decode('base64')"
#init-hook=
# Profiled execution.
profile=no
@ -32,7 +24,9 @@ load-plugins=saltpylint.pep8,
saltpylint.fileperms,
saltpylint.py3modernize,
saltpylint.smartup,
saltpylint.minpyver
saltpylint.minpyver,
saltpylint.blacklist,
saltpylint.thirdparty
# Use multiple processes to speed up Pylint.
# Don't bump this values on PyLint 1.4.0 - Know bug that ignores the passed --rcfile
@ -49,13 +43,22 @@ extension-pkg-whitelist=
# Fileperms Lint Plugin Settings
fileperms-default=0644
fileperms-ignore-paths=tests/runtests.py,tests/jenkins*.py,tests/saltsh.py,tests/buildpackage.py
# Py3 Modernize PyLint Plugin Settings
modernize-nofix = libmodernize.fixes.fix_dict_six
fileperms-ignore-paths=setup.py,tests/runtests.py,tests/jenkins*.py,tests/saltsh.py,tests/buildpackage.py
# Minimum Python Version To Enforce
minimum-python-version = 2.6
minimum-python-version = 2.7
# Allowed 3rd-party package imports
allowed-3rd-party-modules = msgpack,
tornado,
yaml,
jinja2,
Crypto,
requests,
libcloud,
zmq,
pytest,
pytestsalt
[MESSAGES CONTROL]
# Only show warnings with the listed confidence levels. Leave empty to show
@ -71,7 +74,7 @@ confidence=
# can either give multiple identifiers separated by comma (,) or put this
# option multiple times (only on the command line, not in the configuration
# file where it should appear only once).You can also use "--disable=all" to
# disable everything first and then reenable specific checks. For example, if
# disable everything first and then re-enable specific checks. For example, if
# you want to run only the similarities checker, you can use "--disable=all
# --enable=similarities". If you want to run only the classes checker, but have
# no Warning level messages displayed, use"--disable=all --enable=classes
@ -81,6 +84,7 @@ disable=W0142,
I0011,
I0012,
W1202,
E1320,
E8402,
E8731
# E8121,

40
.testing.pylintrc
View File

@ -4,15 +4,7 @@
# Python code to execute, usually for sys.path manipulation such as
# pygtk.require().
init-hook="
exec 'aW1wb3J0IG9zLCBzeXMKCmlmICdWSVJUVUFMX0VOVicgaW4gb3MuZW52aXJvbjoKCiAgICB2ZV9k \
aXIgPSBvcy5lbnZpcm9uWydWSVJUVUFMX0VOViddCiAgICB2ZV9kaXIgaW4gc3lzLnBhdGggb3Ig \
c3lzLnBhdGguaW5zZXJ0KDAsIHZlX2RpcikKICAgIGFjdGl2YXRlX3RoaXMgPSBvcy5wYXRoLmpv \
aW4ob3MucGF0aC5qb2luKHZlX2RpciwgJ2JpbicpLCAnYWN0aXZhdGVfdGhpcy5weScpCgogICAg \
IyBGaXggZm9yIHdpbmRvd3MKICAgIGlmIG5vdCBvcy5wYXRoLmV4aXN0cyhhY3RpdmF0ZV90aGlz \
KToKICAgICAgICBhY3RpdmF0ZV90aGlzID0gb3MucGF0aC5qb2luKG9zLnBhdGguam9pbih2ZV9k \
aXIsICdTY3JpcHRzJyksICdhY3RpdmF0ZV90aGlzLnB5JykKCiAgICBleGVjZmlsZShhY3RpdmF0 \
ZV90aGlzLCBkaWN0KF9fZmlsZV9fPWFjdGl2YXRlX3RoaXMpKQo='.decode('base64')"
#init-hook=
# Add files or directories to the blacklist. They should be base names, not
# paths.
@ -29,7 +21,9 @@ load-plugins=saltpylint.pep8,
saltpylint.fileperms,
saltpylint.py3modernize,
saltpylint.smartup,
saltpylint.minpyver
saltpylint.minpyver,
saltpylint.blacklist,
saltpylint.thirdparty
# Use multiple processes to speed up Pylint.
# Don't bump this values on PyLint 1.4.0 - Know bug that ignores the passed --rcfile
@ -46,13 +40,22 @@ extension-pkg-whitelist=
# Fileperms Lint Plugin Settings
fileperms-default=0644
fileperms-ignore-paths=tests/runtests.py,tests/jenkins*.py,tests/saltsh.py,tests/buildpackage.py
# Py3 Modernize PyLint Plugin Settings
modernize-nofix = libmodernize.fixes.fix_dict_six
fileperms-ignore-paths=setup.py,tests/runtests.py,tests/jenkins*.py,tests/saltsh.py,tests/buildpackage.py
# Minimum Python Version To Enforce
minimum-python-version = 2.6
minimum-python-version = 2.7
# Allowed 3rd-party package imports
allowed-3rd-party-modules = msgpack,
tornado,
yaml,
jinja2,
Crypto,
requests,
libcloud,
zmq,
pytest,
pytestsalt
[MESSAGES CONTROL]
# Only show warnings with the listed confidence levels. Leave empty to show
@ -68,7 +71,7 @@ confidence=
# can either give multiple identifiers separated by comma (,) or put this
# option multiple times (only on the command line, not in the configuration
# file where it should appear only once).You can also use "--disable=all" to
# disable everything first and then reenable specific checks. For example, if
# disable everything first and then re-enable specific checks. For example, if
# you want to run only the similarities checker, you can use "--disable=all
# --enable=similarities". If you want to run only the classes checker, but have
# no Warning level messages displayed, use"--disable=all --enable=classes
@ -82,6 +85,7 @@ disable=R,
E1101,
E1103,
E1136,
E1320,
E8114,
C0102,
C0103,
@ -130,7 +134,8 @@ disable=R,
E8265,
E8266,
E8402,
E8731
E8731,
3rd-party-local-module-not-gated
# Disabled:
# R* [refactoring suggestions & reports]
@ -142,6 +147,7 @@ disable=R,
# E1101 (no-member) [pylint isn't smart enough]
# E1103 (maybe-no-member)
# E1136 (unsubscriptable-object)
# E1320 (un-indexed-curly-braces-error)
# E8114 (indentation-is-not-a-multiple-of-four-comment)
# C0102 (blacklisted-name) [because it activates C0103 too]
# C0103 (invalid-name)

35
.travis.yml
View File

@ -1,35 +0,0 @@
language: python
python:
- '2.6'
- '2.7'
before_install:
- sudo apt-get update
- sudo apt-get install --fix-broken --ignore-missing -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" swig rabbitmq-server ruby python-apt mysql-server libmysqlclient-dev
- (git describe && git fetch --tags) || (git remote add upstream git://github.com/saltstack/salt.git && git fetch --tags upstream)
- pip install mock
- pip install --allow-external http://dl.dropbox.com/u/174789/m2crypto-0.20.1.tar.gz
- pip install --upgrade pep8 'pylint<=1.2.0'
- pip install --upgrade coveralls
- "if [[ $TRAVIS_PYTHON_VERSION == '2.6' ]]; then pip install unittest2 ordereddict; fi"
- pip install git+https://github.com/saltstack/salt-testing.git#egg=SaltTesting
install:
- pip install -r requirements/zeromq.txt -r requirements/cloud.txt
- pip install --allow-all-external -r requirements/opt.txt
before_script:
- "/home/travis/virtualenv/python${TRAVIS_PYTHON_VERSION}/bin/pylint --rcfile=.testing.pylintrc salt/ && echo 'Finished Pylint Check Cleanly' || echo 'Finished Pylint Check With Errors'"
- "/home/travis/virtualenv/python${TRAVIS_PYTHON_VERSION}/bin/pep8 --ignore=E501,E12 salt/ && echo 'Finished PEP-8 Check Cleanly' || echo 'Finished PEP-8 Check With Errors'"
script: "sudo -E /home/travis/virtualenv/python${TRAVIS_PYTHON_VERSION}/bin/python setup.py test --runtests-opts='--run-destructive --sysinfo -v --coverage'"
after_success:
- coveralls
notifications:
irc:
channels: "irc.freenode.org#salt-devel"
on_success: change
on_failure: change

2
AUTHORS
View File

@ -84,6 +84,7 @@ Maxim Burgerhout <maxim@wzzrd.com>
Mickey Malone <mickey.malone@gmail.com>
Michael Steed <msteed@saltstack.com>
Mike Place <mp@saltstack.com>
Mircea Ulinic <mircea@cloudflare.com>
Mitch Anderson <mitch@metauser.net>
Mostafa Hussein <mostafa.hussein91@gmail.com>
Nathaniel Whiteinge <seth@eseth.com>
@ -96,6 +97,7 @@ Pedro Algarvio <pedro@algarvio.me>
Peter Baumgartner
Pierre Carrier <pierre@spotify.com>
Rhys Elsmore <me@rhys.io>
Rafael Caricio <rafael@caricio.com>
Robert Fielding
Sean Channel <pentabular@gmail.com>
Seth House <seth@eseth.com>

92
conf/master
View File

@ -133,6 +133,14 @@
# Cache subsystem module to use for minion data cache.
#cache: localfs
# Enables a fast in-memory cache booster and sets the expiration time.
#memcache_expire_seconds: 0
# Set a memcache limit in items (bank + key) per cache storage (driver + driver_opts).
#memcache_max_items: 1024
# Each time a cache storage got full cleanup all the expired items not just the oldest one.
#memcache_full_cleanup: False
# Enable collecting the memcache stats and log it on `debug` log level.
#memcache_debug: False
# Store all returns in the given returner.
# Setting this option requires that any returner-specific configuration also
@ -186,6 +194,9 @@
# a previous deleted minion ID.
#preserve_minion_cache: False
# Allow or deny minions from requesting their own key revocation
#allow_minion_key_revoke: True
# If max_minions is used in large installations, the master might experience
# high-load situations because of having to check the number of connected
# minions for every authentication. This cache provides the minion-ids of
@ -271,6 +282,15 @@
# a value for you. Default is disabled.
# ipc_write_buffer: 'dynamic'
# These two batch settings, batch_safe_limit and batch_safe_size, are used to
# automatically switch to a batch mode execution. If a command would have been
# sent to more than <batch_safe_limit> minions, then run the command in
# batches of <batch_safe_size>. If no batch_safe_size is specified, a default
# of 8 will be used. If no batch_safe_limit is specified, then no automatic
# batching will occur.
#batch_safe_limit: 100
#batch_safe_size: 8
##### Security settings #####
##########################################
@ -362,6 +382,15 @@
#
#token_expire_user_override: False
# Set to True to enable keeping the calculated user's auth list in the token
# file. This is disabled by default and the auth list is calculated or requested
# from the eauth driver each time.
#keep_acl_in_token: False
# Auth subsystem module to use to get authorized access list for a user. By default it's
# the same module used for external authentication.
#eauth_acl_module: django
# Allow minions to push files to the master. This is disabled by default, for
# security purposes.
#file_recv: False
@ -400,7 +429,7 @@
# Pass in an alternative location for the salt-ssh roster file
#roster_file: /etc/salt/roster
# Define a location for roster files so they can be chosen when using Salt API.
# Define locations for roster files so they can be chosen when using Salt API.
# An administrator can place roster files into these locations. Then when
# calling Salt API, parameter 'roster_file' should contain a relative path to
# these locations. That is, "roster_file=/foo/roster" will be resolved as
@ -549,11 +578,11 @@
#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
# and sha512 are also supported.
# the master server. The default is sha256, but md5, sha1, sha224, sha384 and
# sha512 are also supported.
#
# WARNING: While md5 is also supported, do not use it due to the high chance
# of possible collisions and thus security breach.
# WARNING: While md5 and sha1 are also supported, do not use them due to the
# high chance of possible collisions and thus security breach.
#
# Prior to changing this value, the master should be stopped and all Salt
# caches should be cleared.
@ -623,10 +652,11 @@
# Git File Server Backend Configuration
#
# Optional parameter used to specify the provider to be used for gitfs. Must
# be one of the following: pygit2, gitpython, or dulwich. If unset, then each
# will be tried in that same order, and the first one with a compatible
# version installed will be the provider that is used.
# Optional parameter used to specify the provider to be used for gitfs. Must be
# either pygit2 or gitpython. If unset, then both will be tried (in that
# order), and the first one with a compatible version installed will be the
# provider that is used.
#
#gitfs_provider: pygit2
# Along with gitfs_password, is used to authenticate to HTTPS remotes.
@ -679,6 +709,11 @@
# repository and defaults to the repository root.
#gitfs_root: somefolder/otherfolder
#
# The refspecs fetched by gitfs remotes
#gitfs_refspecs:
# - '+refs/heads/*:refs/remotes/origin/*'
# - '+refs/tags/*:refs/tags/*'
#
#
##### Pillar settings #####
##########################################
@ -695,11 +730,38 @@
# - hiera: /etc/hiera.yaml
# - cmd_yaml: cat /etc/salt/yaml
# A list of paths to be recursively decrypted during pillar compilation.
# Entries in this list can be formatted either as a simple string, or as a
# key/value pair, with the key being the pillar location, and the value being
# the renderer to use for pillar decryption. If the former is used, the
# renderer specified by decrypt_pillar_default will be used.
#decrypt_pillar:
# - 'foo:bar': gpg
# - 'lorem:ipsum:dolor'
# The delimiter used to distinguish nested data structures in the
# decrypt_pillar option.
#decrypt_pillar_delimiter: ':'
# The default renderer used for decryption, if one is not specified for a given
# pillar key in decrypt_pillar.
#decrypt_pillar_default: gpg
# List of renderers which are permitted to be used for pillar decryption.
#decrypt_pillar_renderers:
# - gpg
# The ext_pillar_first option allows for external pillar sources to populate
# before file system pillar. This allows for targeting file system pillar from
# ext_pillar.
#ext_pillar_first: False
# The external pillars permitted to be used on-demand using pillar.ext
#on_demand_ext_pillar:
# - libvirt
# - virtkey
# The pillar_gitfs_ssl_verify option specifies whether to ignore ssl certificate
# errors when contacting the pillar gitfs backend. You might want to set this to
# false if you're using a git backend that uses a self-signed certificate but
@ -801,6 +863,11 @@
# to authenticate is protected by a passphrase.
#git_pillar_passphrase: ''
# The refspecs fetched by git_pillar remotes
#git_pillar_refspecs:
# - '+refs/heads/*:refs/remotes/origin/*'
# - '+refs/tags/*:refs/tags/*'
# A master can cache pillars locally to bypass the expense of having to render them
# for each minion on every request. This feature should only be enabled in cases
# where pillar rendering time is known to be unsatisfactory and any attendant security
@ -819,7 +886,7 @@
#pillar_cache_ttl: 3600
# If and only if a master has set `pillar_cache: True`, one of several storage providers
# can be utililzed.
# can be utilized.
#
# `disk`: The default storage backend. This caches rendered pillars to the master cache.
# Rendered pillars are serialized and deserialized as msgpack structures for speed.
@ -1046,6 +1113,11 @@
#winrepo_remotes:
# - 'https://github.com/saltstack/salt-winrepo.git'
# The refspecs fetched by winrepo remotes
#winrepo_refspecs:
# - '+refs/heads/*:refs/remotes/origin/*'
# - '+refs/tags/*:refs/tags/*'
#
##### Returner settings ######
############################################

28
conf/minion
View File

@ -161,7 +161,7 @@
# 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
# 'cachedir'/file_backup relative to their original location and appended
# with a timestamp. The only valid setting is "minion". Disabled by default.
#
# Alternatively this can be specified for each file in state files:
@ -193,6 +193,15 @@
# The wait-time will be a random number of seconds between 0 and the defined value.
#random_reauth_delay: 60
# To avoid overloading a master when many minions startup at once, a randomized
# delay may be set to tell the minions to wait before connecting to the master.
# This value is the number of seconds to choose from for a random number. For
# example, setting this value to 60 will choose a random number of seconds to delay
# on startup between zero seconds and sixty seconds. Setting to '0' will disable
# this feature.
#random_startup_delay: 0
# When waiting for a master to accept the minion's public key, salt will
# continuously attempt to reconnect until successful. This is the timeout value,
# in seconds, for each individual attempt. After this timeout expires, the minion
@ -574,14 +583,11 @@
#fileserver_limit_traversal: False
# The hash_type is the hash to use when discovering the hash of a file on
# the local fileserver. The default is md5, but sha1, sha224, sha256, sha384
# the local fileserver. The default is sha256, but md5, sha1, sha224, sha384
# and sha512 are also supported.
#
# WARNING: While md5 and sha1 are also supported, do not use it due to the high chance
# of possible collisions and thus security breach.
#
# WARNING: While md5 is also supported, do not use it due to the high chance
# of possible collisions and thus security breach.
# WARNING: While md5 and sha1 are also supported, do not use them due to the
# high chance of possible collisions and thus security breach.
#
# Warning: Prior to changing this value, the minion should be stopped and all
# Salt caches should be cleared.
@ -652,6 +658,10 @@
###########################################
# Disable multiprocessing support, by default when a minion receives a
# publication a new process is spawned and the command is executed therein.
#
# WARNING: Disabling multiprocessing may result in substantial slowdowns
# when processing large pillars. See https://github.com/saltstack/salt/issues/38758
# for a full explanation.
#multiprocessing: True
@ -736,6 +746,10 @@
#
#zmq_monitor: False
# Number of times to try to authenticate with the salt master when reconnecting
# to the master
#tcp_authentication_retries: 5
###### Module configuration #####
###########################################
# Salt allows for modules to be passed arbitrary configuration data, any data

22
conf/proxy
View File

@ -31,6 +31,26 @@
# Default to False for 2016.3 and 2016.11. Switch to True for Nitrogen.
# proxy_merge_grains_in_module: True
# If a proxymodule has a function called 'alive' returning a boolean
# flag reflecting the state of the connection with the remove device,
# when this option is set as True, a scheduled job on the proxy will
# try restarting the connection. The polling frequency depends on the
# next option, 'proxy_keep_alive_interval'. Added in Nitrogen.
# proxy_keep_alive: True
# The polling interval (in minutes) to check if the underlying connection
# with the remote device is still alive. This option requires
# 'proxy_keep_alive' to be configured as True and the proxymodule to
# implement the 'alive' function. Added in Nitrogen.
# proxy_keep_alive_interval: 1
# By default, any proxy opens the connection with the remote device when
# initialized. Some proxymodules allow through this option to open/close
# the session per command. This requires the proxymodule to have this
# capability. Please consult the documentation to see if the proxy type
# used can be that flexible. Added in Nitrogen.
# proxy_always_alive: True
# If multiple masters are specified in the 'master' setting, the default behavior
# is to always try to connect to them in the order they are listed. If random_master is
# set to True, the order will be randomized instead. This can be helpful in distributing
@ -119,7 +139,7 @@
# 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
# 'cachedir'/file_backup relative to their original location and appended
# with a timestamp. The only valid setting is "minion". Disabled by default.
#
# Alternatively this can be specified for each file in state files:

60
doc/Makefile
View File

@ -9,11 +9,6 @@ BUILDDIR = _build
SPHINXLANG =
XELATEX = xelatex
# User-friendly check for sphinx-build
ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
endif
# ----- Translations Support ------------------------------------------------>
# If language is set, also set translation options
ifeq ($(shell [ "x$(SPHINXLANG)" != "x" ] && echo 0 || echo 1), 0)
@ -36,7 +31,7 @@ ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(TRANSLATIONOPTS
# the i18n builder cannot share the environment and doctrees with the others
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext translations download-translations
.PHONY: help clean check_sphinx-build html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext translations download-translations
help:
@echo "Please use \`make <target>' where <target> is one of"
@ -69,38 +64,42 @@ clean:
rm -rf $(BUILDDIR)/*
test -d 'locale' && find locale/ -name *.mo -exec rm {} \; || true
html: translations
# User-friendly check for sphinx-build
check_sphinx-build:
@which $(SPHINXBUILD) >/dev/null 2>&1 || (echo "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)" >&2; false)
html: check_sphinx-build translations
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
dirhtml: translations
dirhtml: check_sphinx-build translations
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
singlehtml: translations
singlehtml: check_sphinx-build translations
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
@echo
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
pickle: translations
pickle: check_sphinx-build translations
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@echo
@echo "Build finished; now you can process the pickle files."
json: translations
json: check_sphinx-build translations
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
@echo
@echo "Build finished; now you can process the JSON files."
htmlhelp: translations
htmlhelp: check_sphinx-build translations
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
@echo
@echo "Build finished; now you can run HTML Help Workshop with the" \
".hhp project file in $(BUILDDIR)/htmlhelp."
qthelp: translations
qthelp: check_sphinx-build translations
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
@echo
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
@ -109,7 +108,7 @@ qthelp: translations
@echo "To view the help file:"
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Salt.qhc"
devhelp: translations
devhelp: check_sphinx-build translations
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
@echo
@echo "Build finished."
@ -118,31 +117,31 @@ devhelp: translations
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Salt"
@echo "# devhelp"
epub: translations
epub: check_sphinx-build translations
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
@echo
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
latex: translations
latex: check_sphinx-build translations
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
@echo "Run \`make' in that directory to run these through (pdf)latex" \
"(use \`make latexpdf' here to do that automatically)."
latexpdf: translations
latexpdf: check_sphinx-build translations
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through pdflatex..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
latexpdfja: translations
latexpdfja: check_sphinx-build translations
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through platex and dvipdfmx..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
pdf: translations
pdf: check_sphinx-build translations
@if [ "$(XELATEX)" = "xelatex" ] || [ "x$(XELATEX)" = "x" ]; then \
echo "The '$(XELATEX)' command was not found."; \
fi
@ -157,67 +156,66 @@ cheatsheet: translations
cd cheatsheet && xelatex salt.tex && cp salt.pdf ../salt-cheatsheet.pdf
@echo "./salt-cheatsheet.pdf created."
text: translations
text: check_sphinx-build translations
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
@echo
@echo "Build finished. The text files are in $(BUILDDIR)/text."
man: translations
man: check_sphinx-build translations
$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
@echo
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
texinfo: translations
texinfo: check_sphinx-build translations
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo
@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
@echo "Run \`make' in that directory to run these through makeinfo" \
"(use \`make info' here to do that automatically)."
info: translations
info: check_sphinx-build translations
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo "Running Texinfo files through makeinfo..."
make -C $(BUILDDIR)/texinfo info
@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
gettext:
gettext: check_sphinx-build
$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
@echo
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale"
changes: translations
changes: check_sphinx-build translations
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@echo
@echo "The overview file is in $(BUILDDIR)/changes."
spelling:
spelling: check_sphinx-build
$(SPHINXBUILD) -b spelling $(ALLSPHINXOPTS) $(BUILDDIR)/spelling
@echo
@echo "Spell check complete; look for any errors in the above output " \
"or in $(BUILDDIR)/spelling/output.txt."
linkcheck:
linkcheck: check_sphinx-build
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
@echo
@echo "Link check complete; look for any errors in the above output " \
"or in $(BUILDDIR)/linkcheck/output.txt."
doctest:
doctest: check_sphinx-build
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
@echo "Testing of doctests in the sources finished, look at the " \
"results in $(BUILDDIR)/doctest/output.txt."
xml: translations
xml: check_sphinx-build translations
$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
@echo
@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
pseudoxml: translations
pseudoxml: check_sphinx-build translations
$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
@echo
@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
translations:
@if [ "$(SPHINXLANG)" = "en" ] || [ "x$(SPHINXLANG)" = "x" ]; then \
echo "No need to update translations. Skipping..."; \

2
doc/_ext/saltdomain.py
View File

@ -305,5 +305,7 @@ def setup(app):
indextemplate="pair: %s; conf/master")
app.add_crossref_type(directivename="conf_minion", rolename="conf_minion",
indextemplate="pair: %s; conf/minion")
app.add_crossref_type(directivename="conf_proxy", rolename="conf_proxy",
indextemplate="pair: %s; conf/proxy")
app.add_crossref_type(directivename="conf_log", rolename="conf_log",
indextemplate="pair: %s; conf/logging")

BIN
doc/_static/napalm_logo.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

6
doc/_themes/saltstack2/layout.html vendored
View File

@ -164,6 +164,9 @@
<!--start navbar-->
<div class="row">
<div class="col-sm-12 col-md-11 col-md-offset-1 col-lg-10 col-lg-offset-1">
<nav class="pull-left text-muted">
<a href="https://github.com/saltstack/salt/edit/develop/doc/{{pagename}}.rst">Edit on GitHub</a>
</nav>
<nav id="localnav">
<ul class="nav navbar-nav">
{%- block relbar_small %}{{ relbar() }}{% endblock %}
@ -252,7 +255,8 @@
<div class="col-sm-6">
<a href="http://saltstack.com/support" target="_blank"><img class="nolightbox footer-banner center" src="{{ pathto('_static/images/footer-support.png', 1) }}"/></a>
<a href="https://saltstack.com/support" target="_blank"><img class="nolightbox footer-banner center" src="{{ pathto('_static/images/footer-support.png', 1) }}"/></a>
<a href="https://saltstack.com/saltstack-enterprise/" target="_blank"><img class="nolightbox footer-banner center" src="{{ pathto('_static/images/enterprise_ad.jpg', 1) }}"/></a>
</div>

BIN
doc/_themes/saltstack2/static/images/enterprise_ad.jpg vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 739 KiB

12
doc/conf.py
View File

@ -26,7 +26,7 @@ class Mock(object):
'''
def __init__(self, mapping=None, *args, **kwargs):
"""
Mapping allows to bypass the Mock object, but actually assign
Mapping allows autodoc to bypass the Mock object, but actually assign
a specific value, expected by a specific attribute returned.
"""
self.__mapping = mapping or {}
@ -165,6 +165,11 @@ MOCK_MODULES = [
'pyroute2.ipdb',
'avahi',
'dbus',
'twisted',
'twisted.internet',
'twisted.internet.protocol',
'twisted.internet.protocol.DatagramProtocol',
'msgpack',
]
for mod_name in MOCK_MODULES:
@ -239,8 +244,8 @@ on_saltstack = 'SALT_ON_SALTSTACK' in os.environ
project = 'Salt'
version = salt.version.__version__
latest_release = '2016.11.1' # latest release
previous_release = '2016.3.4' # latest release from previous branch
latest_release = '2016.11.5' # latest release
previous_release = '2016.3.6' # latest release from previous branch
previous_release_dir = '2016.3' # path on web server for previous branch
next_release = '' # next release
next_release_dir = '' # path on web server for next release branch
@ -499,6 +504,7 @@ epub_copyright = copyright
epub_scheme = 'URL'
epub_identifier = 'http://saltstack.com/'
epub_tocdup = False
#epub_tocdepth = 3

2
doc/contents.rst
View File

@ -18,6 +18,7 @@ Salt Table of Contents
topics/ssh/index
topics/cloud/index
topics/proxyminion/index
topics/network_automation/index
topics/virt/index
ref/cli/index
ref/index
@ -27,3 +28,4 @@ Salt Table of Contents
topics/windows/index
topics/development/index
topics/releases/index
topics/venafi/index

150
doc/faq.rst
View File

@ -147,7 +147,7 @@ should be opened on our tracker_, with the following information:
Why aren't my custom modules/states/etc. available on my Minions?
-----------------------------------------------------------------
Custom modules are synced to Minions when
Custom modules are synced to Minions when
:mod:`saltutil.sync_modules <salt.modules.saltutil.sync_modules>`,
or :mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.
Custom modules are also synced by :mod:`state.apply` when run without
@ -166,8 +166,14 @@ Other custom types (renderers, outputters, etc.) have similar behavior, see the
documentation for the :mod:`saltutil <salt.modules.saltutil>` module for more
information.
:ref:`This reactor example <minion-start-reactor>` can be used to automatically
sync custom types when the minion connects to the master, to help with this
chicken-and-egg issue.
Module ``X`` isn't available, even though the shell command it uses is installed. Why?
--------------------------------------------------------------------------------------
This is most likely a PATH issue. Did you custom-compile the software which the
module requires? RHEL/CentOS/etc. in particular override the root user's path
in ``/etc/init.d/functions``, setting it to ``/sbin:/usr/sbin:/bin:/usr/bin``,
@ -246,86 +252,116 @@ specifying the pillar variable is the same one used for :py:func:`pillar.get
<salt.states.file.managed>` state is only supported in Salt 2015.8.4 and
newer.
What is the best way to restart a Salt daemon using Salt?
---------------------------------------------------------
What is the best way to restart a Salt Minion daemon using Salt after upgrade?
------------------------------------------------------------------------------
Updating the salt-minion package requires a restart of the salt-minion service.
But restarting the service while in the middle of a state run interrupts the
process of the minion running states and sending results back to the master.
It's a tricky problem to solve, and we're working on it, but in the meantime
one way of handling this (on Linux and UNIX-based operating systems) is to use
**at** (a job scheduler which predates cron) to schedule a restart of the
service. **at** is not installed by default on most distros, and requires a
service to be running (usually called **atd**) in order to schedule jobs.
Here's an example of how to upgrade the salt-minion package at the end of a
Salt run, and schedule a service restart for one minute after the package
update completes.
Updating the ``salt-minion`` package requires a restart of the ``salt-minion``
service. But restarting the service while in the middle of a state run
interrupts the process of the Minion running states and sending results back to
the Master. A common way to workaround that is to schedule restarting of the
Minion service using :ref:`masterless mode <masterless-quickstart>` after all
other states have been applied. This allows the minion to keep Minion to Master
connection alive for the Minion to report the final results to the Master, while
the service is restarting in the background.
Linux/Unix
**********
Upgrade without automatic restart
*********************************
.. code-block:: yaml
Doing the Minion upgrade seems to be a simplest state in your SLS file at
first. But the operating systems such as Debian GNU/Linux, Ubuntu and their
derivatives start the service after the package installation by default.
To prevent this, we need to create policy layer which will prevent the Minion
service to restart right after the upgrade:
salt-minion:
.. code-block:: jinja
{%- if grains['os_family'] == 'Debian' %}
Disable starting services:
file.managed:
- name: /usr/sbin/policy-rc.d
- user: root
- group: root
- mode: 0755
- contents:
- '#!/bin/sh'
- exit 101
# do not touch if already exists
- replace: False
- prereq:
- pkg: Upgrade Salt Minion
{%- endif %}
Upgrade Salt Minion:
pkg.installed:
- name: salt-minion
- version: 2014.1.7-3.el6
- version: 2016.11.3{% if grains['os_family'] == 'Debian' %}+ds-1{% endif %}
- order: last
service.running:
Enable Salt Minion:
service.enabled:
- name: salt-minion
- require:
- pkg: salt-minion
cmd.run:
- name: echo service salt-minion restart | at now + 1 minute
- pkg: Upgrade Salt Minion
{%- if grains['os_family'] == 'Debian' %}
Enable starting services:
file.absent:
- name: /usr/sbin/policy-rc.d
- onchanges:
- pkg: salt-minion
- pkg: Upgrade Salt Minion
To ensure that **at** is installed and **atd** is running, the following states
can be used (be sure to double-check the package name and service name for the
distro the minion is running, in case they differ from the example below.
{%- endif %}
.. code-block:: yaml
Restart using states
********************
at:
pkg.installed:
- name: at
service.running:
- name: atd
- enable: True
Now we can apply the workaround to restart the Minion in reliable way.
The following example works on both UNIX-like and Windows operating systems:
An alternative to using the :program:`atd` daemon is to fork and disown the
process.
.. code-block:: jinja
.. code-block:: yaml
restart_minion:
Restart Salt Minion:
cmd.run:
- name: |
{%- if grains['kernel'] == 'Windows' %}
- name: 'C:\salt\salt-call.bat --local service.restart salt-minion'
{%- else %}
- name: 'salt-call --local service.restart salt-minion'
{%- endif %}
- bg: True
- onchanges:
- pkg: Upgrade Salt Minion
However, it requires more advanced tricks to upgrade from legacy version of
Salt (before ``2016.3.0``), where executing commands in the background is not
supported:
.. code-block:: jinja
Restart Salt Minion:
cmd.run:
{%- if grains['kernel'] == 'Windows' %}
- name: 'start powershell "Restart-Service -Name salt-minion"'
{%- else %}
# fork and disown the process
- name: |-
exec 0>&- # close stdin
exec 1>&- # close stdout
exec 2>&- # close stderr
nohup /bin/sh -c 'sleep 10 && salt-call --local service.restart salt-minion' &
- python_shell: True
- order: last
nohup salt-call --local service.restart salt-minion &
{%- endif %}
Windows
*******
Restart using remote executions
*******************************
For Windows machines, restarting the minion can be accomplished using the
following state:
.. code-block:: yaml
schedule-start:
cmd.run:
- name: 'start powershell "Restart-Service -Name salt-minion"'
- order: last
or running immediately from the command line:
Restart the Minion from the command line:
.. code-block:: bash
salt -G kernel:Windows cmd.run 'start powershell "Restart-Service -Name salt-minion"'
salt -G kernel:Windows cmd.run_bg 'C:\salt\salt-call.bat --local service.restart salt-minion'
salt -C 'not G@kernel:Windows' cmd.run_bg 'salt-call --local service.restart salt-minion'
Salting the Salt Master
-----------------------

3
doc/glossary.rst
View File

@ -1,3 +1,6 @@
.. _glossary:
========
Glossary
========

47
doc/man/salt.7
View File

@ -6093,17 +6093,17 @@ fileserver_list_cache_time: 5
.UNINDENT
.SS \fBhash_type\fP
.sp
Default: \fBmd5\fP
Default: \fBsha256\fP
.sp
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, and
the master server. The default is sha256, but md5, sha1, sha224, sha384, and
sha512 are also supported.
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
hash_type: md5
hash_type: sha256
.ft P
.fi
.UNINDENT
@ -10539,17 +10539,17 @@ fileserver_limit_traversal: False
.UNINDENT
.SS \fBhash_type\fP
.sp
Default: \fBmd5\fP
Default: \fBsha256\fP
.sp
The hash_type is the hash to use when discovering the hash of a file on the
local fileserver. The default is md5, but sha1, sha224, sha256, sha384, and
local fileserver. The default is sha256, but md5, sha1, sha224, sha384, and
sha512 are also supported.
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
hash_type: md5
hash_type: sha256
.ft P
.fi
.UNINDENT
@ -11776,11 +11776,11 @@ event that an error is introduced in the latest revision of the repo.
#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
# and sha512 are also supported.
# the master server. The default is sha256, but md5, sha1, sha224, sha384 and
# sha512 are also supported.
#
# WARNING: While md5 is also supported, do not use it due to the high chance
# of possible collisions and thus security breach.
# WARNING: While md5 and sha1 are also supported, do not use them due to the
# high chance of possible collisions and thus security breach.
#
# Prior to changing this value, the master should be stopped and all Salt
# caches should be cleared.
@ -12459,7 +12459,7 @@ event that an error is introduced in the latest revision of the repo.
# strip_colors: False
# Backup files that are replaced by file.managed and file.recurse under
# \(aqcachedir\(aq/file_backups relative to their original location and appended
# \(aqcachedir\(aq/file_backup relative to their original location and appended
# with a timestamp. The only valid setting is "minion". Disabled by default.
#
# Alternatively this can be specified for each file in state files:
@ -12867,14 +12867,11 @@ event that an error is introduced in the latest revision of the repo.
#fileserver_limit_traversal: False
# The hash_type is the hash to use when discovering the hash of a file on
# the local fileserver. The default is md5, but sha1, sha224, sha256, sha384
# the local fileserver. The default is sha256, but md5, sha1, sha224, sha384
# and sha512 are also supported.
#
# WARNING: While md5 and sha1 are also supported, do not use it due to the high chance
# of possible collisions and thus security breach.
#
# WARNING: While md5 is also supported, do not use it due to the high chance
# of possible collisions and thus security breach.
# WARNING: While md5 and sha1 are also supported, do not use them due to the
# high chance of possible collisions and thus security breach.
#
# Warning: Prior to changing this value, the minion should be stopped and all
# Salt caches should be cleared.
@ -41075,7 +41072,7 @@ The above command is equivalent to the following command at the CLI:
.sp
.nf
.ft C
salt \(aqhaproxy*\(aq state.apply haproxy.refresh_pool \(aqpillar={new_minion: minionid}\(aq
salt \(aqhaproxy*\(aq state.apply haproxy.refresh_pool pillar=\(aq{new_minion: minionid}\(aq
.ft P
.fi
.UNINDENT
@ -63393,6 +63390,7 @@ them onto a logstash endpoint.
logstash:
host: log.my_network.com
port: 5959
proto: tcp
.UNINDENT
.UNINDENT
.UNINDENT
@ -63402,7 +63400,7 @@ logstash
.UNINDENT
.INDENT 0.0
.TP
.B salt.engines.logstash.start(host, port=5959, tag=\(aqsalt/engine/logstash\(aq)
.B salt.engines.logstash.start(host, port=5959, proto=\(aqtcp\(aq, tag=\(aqsalt/engine/logstash\(aq)
Listen to salt events and forward them to logstash
.UNINDENT
.SS salt.engines.reactor module
@ -68500,6 +68498,9 @@ key id to load with the keyserver argument
.B key_url
URL to a GPG key to add to the APT GPG keyring
.TP
.B key_text
GPG key in string form to add to the APT GPG keyring
.TP
.B consolidate
if \fBTrue\fP, will attempt to de\-dup and consolidate sources
.TP
@ -98664,10 +98665,10 @@ Attach TTYs
Example: \fBtty=True\fP
.TP
.B detach
True
False
If \fBTrue\fP, run \fBcommand\fP in the background (daemon mode)
.sp
Example: \fBdetach=False\fP
Example: \fBdetach=True\fP
.TP
.B user
User under which to run docker
@ -292069,7 +292070,7 @@ the test method:
.nf
.ft C
import integration
from salttesting.helpers import destructiveTest
from tests.support.helpers import destructiveTest
class PkgTest(integration.ModuleCase):
@destructiveTest
@ -292165,7 +292166,7 @@ can be used
.nf
.ft C
# Import logging handler
from salttesting.helpers import TestsLoggingHandler
from tests.support.helpers import TestsLoggingHandler
# .. inside test
with TestsLoggingHandler() as handler:

6
doc/ref/auth/all/salt.auth.file.rst Normal file
View File

@ -0,0 +1,6 @@
==============
salt.auth.file
==============
.. automodule:: salt.auth.file
:members:

5
doc/ref/auth/all/salt.auth.rest.rst
View File

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

2
doc/ref/beacons/all/index.rst
View File

@ -20,6 +20,7 @@ beacon modules
inotify
journald
load
log
memusage
network_info
network_settings
@ -31,5 +32,6 @@ beacon modules
service
sh
status
telegram_bot_msg
twilio_txt_msg
wtmp

6
doc/ref/beacons/all/salt.beacons.log.rst Normal file
View File

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

6
doc/ref/beacons/all/salt.beacons.telegram_bot_msg.rst Normal file
View File

@ -0,0 +1,6 @@
=============================
salt.beacons.telegram_bot_msg
=============================
.. automodule:: salt.beacons.telegram_bot_msg
:members:

1
doc/ref/cache/all/index.rst vendored
View File

@ -12,3 +12,4 @@ cache modules
localfs
consul
redis_cache

5
doc/ref/cache/all/salt.cache.etcd_cache.rst vendored Normal file
View File

@ -0,0 +1,5 @@
salt.cache.etcd_cache module
=============================
.. automodule:: salt.cache.etcd_cache
:members:

5
doc/ref/cache/all/salt.cache.mysql_cache.rst vendored Normal file
View File

@ -0,0 +1,5 @@
salt.cache.mysql_cache module
=============================
.. automodule:: salt.cache.mysql_cache
:members:

5
doc/ref/cache/all/salt.cache.redis_cache.rst vendored Normal file
View File

@ -0,0 +1,5 @@
salt.cache.redis_cache module
=============================
.. automodule:: salt.cache.redis_cache
:members:

40
doc/ref/cli/salt-cp.rst
View File

@ -2,32 +2,42 @@
``salt-cp``
===========
Copy a file to a set of systems
Copy a file or files to one or more minions
Synopsis
========
.. code-block:: bash
salt-cp '*' [ options ] SOURCE DEST
salt-cp '*' [ options ] SOURCE [SOURCE2 SOURCE3 ...] DEST
salt-cp -E '.*' [ options ] SOURCE DEST
salt-cp -E '.*' [ options ] SOURCE [SOURCE2 SOURCE3 ...] DEST
salt-cp -G 'os:Arch.*' [ options ] SOURCE DEST
salt-cp -G 'os:Arch.*' [ options ] SOURCE [SOURCE2 SOURCE3 ...] DEST
Description
===========
Salt copy copies a local file out to all of the Salt minions matched by the
given target.
salt-cp copies files from the master to all of the Salt minions matched by the
specified target expression.
Salt copy is only intended for use with small files (< 100KB). If you need
to copy large files out to minions please use the cp.get_file function.
.. note::
salt-cp uses Salt's publishing mechanism. This means the privacy of the
contents of the file on the wire is completely dependent upon the transport
in use. In addition, if the master or minion is running with debug logging,
the contents of the file will be logged to disk.
Note: salt-cp uses salt's publishing mechanism. This means the privacy of the
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.
In addition, this tool is less efficient than the Salt fileserver when
copying larger files. It is recommended to instead use
:py:func:`cp.get_file <salt.modules.cp.get_file>` to copy larger files to
minions. However, this requires the file to be located within one of the
fileserver directories.
.. versionchanged:: 2016.3.7,2016.11.6,Nitrogen
Compression support added, disable with ``-n``. Also, if the destination
path ends in a path separator (i.e. ``/``, or ``\`` on Windows, the
desitination will be assumed to be a directory. Finally, recursion is now
supported, allowing for entire directories to be copied.
Options
=======
@ -46,6 +56,12 @@ Options
.. include:: _includes/target-selection.rst
.. option:: -n, --no-compression
Disable gzip compression.
.. versionadded:: 2016.3.7,2016.11.6,Nitrogen
See also
========

4
doc/ref/clouds/all/index.rst
View File

@ -26,13 +26,15 @@ Full list of Salt Cloud modules
opennebula
openstack
parallels
profitbricks
proxmox
pyrax
qingcloud
rackspace
saltify
scaleway
softlayer
softlayer_hw
virtualbox
vmware
vultrpy
xen

0
doc/ref/clouds/all/salt.cloud.clouds.azureare.rst → doc/ref/clouds/all/salt.cloud.clouds.azurearm.rst
View File

6
doc/ref/clouds/all/salt.cloud.clouds.rackspace.rst
View File

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

4
doc/ref/clouds/all/salt.cloud.clouds.virtualbox.rst
View File

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

6
doc/ref/clouds/all/salt.cloud.clouds.xen.rst Normal file
View File

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

12
doc/ref/configuration/examples.rst
View File

@ -1,3 +1,5 @@
.. _configuration-file-examples:
===========================
Configuration file examples
===========================
@ -20,4 +22,12 @@ Example minion configuration file
=================================
.. literalinclude:: ../../../conf/minion
:language: yaml
:language: yaml
.. _configuration-examples-proxy:
Example proxy minion configuration file
=======================================
.. literalinclude:: ../../../conf/proxy
:language: yaml

13
doc/ref/configuration/index.rst
View File

@ -51,6 +51,19 @@ After updating the configuration file, restart the Salt minion.
See the :ref:`minion configuration reference <configuration-salt-minion>`
for more details about other configurable options.
Proxy Minion Configuration
==========================
A proxy minion emulates the behaviour of a regular minion
and inherits their options.
Similarly, the configuration file is ``/etc/salt/proxy`` and the proxy
tries to connect to the DNS name "salt".
In addition to the regular minion options,
there are several proxy-specific - see the
:ref:`proxy minion configuration reference <configuration-salt-proxy>`.
Running Salt
============

4
doc/ref/configuration/logging/handlers/index.rst
View File

@ -9,5 +9,7 @@ External Logging Handlers
:toctree:
:template: autosummary.rst.tmpl
fluent_mod
log4mongo_mod
logstash_mod
sentry_mod
sentry_mod

5
doc/ref/configuration/logging/handlers/salt.log.handlers.fluent_mod.rst Normal file
View File

@ -0,0 +1,5 @@
============================
salt.log.handlers.fluent_mod
============================
.. automodule:: salt.log.handlers.fluent_mod

5
doc/ref/configuration/logging/handlers/salt.log.handlers.log4mongo_mod.rst Normal file
View File

@ -0,0 +1,5 @@
===============================
salt.log.handlers.log4mongo_mod
===============================
.. automodule:: salt.log.handlers.log4mongo_mod

6
doc/ref/configuration/logging/handlers/salt.log.handlers.logstash_mod.rst
View File

@ -1 +1,5 @@
.. automodule:: salt.log.handlers.logstash_mod
==============================
salt.log.handlers.logstash_mod
==============================
.. automodule:: salt.log.handlers.logstash_mod

6
doc/ref/configuration/logging/handlers/salt.log.handlers.sentry_mod.rst
View File

@ -1 +1,5 @@
.. automodule:: salt.log.handlers.sentry_mod
============================
salt.log.handlers.sentry_mod
============================
.. automodule:: salt.log.handlers.sentry_mod

671
doc/ref/configuration/master.rst
View File

@ -27,7 +27,7 @@ Primary Master Configuration
Default: ``0.0.0.0`` (all interfaces)
The local interface to bind to.
The local interface to bind to, must be an IP address.
.. code-block:: yaml
@ -245,7 +245,49 @@ each of Salt's module types such as ``runners``, ``output``, ``wheel``,
extension_modules: /root/salt_extmods
.. conf_minion:: module_dirs
``extmod_whitelist/extmod_blacklist``
-------------------------------------
.. versionadded:: Nitrogen
By using this dictionary, the modules that are synced to the master's extmod cache using `saltutil.sync_*` can be
limited. If nothing is set to a specific type, then all modules are accepted. To block all modules of a specific type,
whitelist an empty list.
.. code-block:: yaml
extmod_whitelist:
modules:
- custom_module
engines:
- custom_engine
pillars: []
extmod_blacklist:
modules:
- specific_module
Valid options:
- modules
- states
- grains
- renderers
- returners
- output
- proxy
- runners
- wheel
- engines
- queues
- pillar
- utils
- sdb
- cache
- clouds
- tops
- roster
.. conf_master:: module_dirs
``module_dirs``
---------------
@ -471,7 +513,7 @@ are expected to reply from executions.
.. conf_master:: cache
``cache``
---------------------
---------
Default: ``localfs``
@ -481,6 +523,75 @@ Cache subsystem module to use for minion data cache.
cache: consul
.. conf_master:: memcache_expire_seconds
``memcache_expire_seconds``
---------------------------
Default: ``0``
Memcache is an additional cache layer that keeps a limited amount of data
fetched from the minion data cache for a limited period of time in memory that
makes cache operations faster. It doesn't make much sence for the ``localfs``
cache driver but helps for more complex drivers like ``consul``.
This option sets the memcache items expiration time. By default is set to ``0``
that disables the memcache.
.. code-block:: yaml
memcache_expire_seconds: 30
.. conf_master:: memcache_max_items
``memcache_max_items``
----------------------
Default: ``1024``
Set memcache limit in items that are bank-key pairs. I.e the list of
minion_0/data, minion_0/mine, minion_1/data contains 3 items. This value depends
on the count of minions usually targeted in your environment. The best one could
be found by analyzing the cache log with ``memcache_debug`` enabled.
.. code-block:: yaml
memcache_max_items: 1024
.. conf_master:: memcache_full_cleanup
``memcache_full_cleanup``
-------------------------
Default: ``False``
If cache storage got full, i.e. the items count exceeds the
``memcache_max_items`` value, memcache cleans up it's storage. If this option
set to ``False`` memcache removes the only one oldest value from it's storage.
If this set set to ``True`` memcache removes all the expired items and also
removes the oldest one if there are no expired items.
.. code-block:: yaml
memcache_full_cleanup: True
.. conf_master:: memcache_debug
``memcache_debug``
------------------
Default: ``False``
Enable collecting the memcache stats and log it on `debug` log level. If enabled
memcache collect information about how many ``fetch`` calls has been done and
how many of them has been hit by memcache. Also it outputs the rate value that
is the result of division of the first two values. This should help to choose
right values for the expiration time and the cache size.
.. code-block:: yaml
memcache_debug: True
.. conf_master:: ext_job_cache
``ext_job_cache``
@ -760,7 +871,7 @@ Pass in an alternative location for the salt-ssh roster file.
.. conf_master:: ssh_log_file
``ssh_log_file``
-------------------
----------------
.. versionadded:: 2016.3.5
@ -937,7 +1048,8 @@ This is completely disabled by default.
- root
- '^(?!sudo_).*$' # all non sudo users
modules:
- cmd
- cmd.*
- test.echo
.. conf_master:: external_auth
@ -992,6 +1104,35 @@ and usernames may be given:
ldap:
- gary
.. conf_master:: keep_acl_in_token
``keep_acl_in_token``
---------------------
Default: ``False``
Set to True to enable keeping the calculated user's auth list in the token
file. This is disabled by default and the auth list is calculated or requested
from the eauth driver each time.
.. code-block:: yaml
keep_acl_in_token: False
.. conf_master:: eauth_acl_module
``eauth_acl_module``
---------------------
Default: ``''``
Auth subsystem module to use to get authorized access list for a user. By default it's
the same module used for external authentication.
.. code-block:: yaml
eauth_acl_module: django
.. conf_master:: file_recv
``file_recv``
@ -1121,6 +1262,21 @@ constant names without ssl module prefix: ``CERT_REQUIRED`` or ``PROTOCOL_SSLv23
certfile: <path_to_certfile>
ssl_version: PROTOCOL_TLSv1_2
.. conf_master:: allow_minion_key_revoke
``allow_minion_key_revoke``
------------------
Default: ``True``
Controls whether a minion can request its own key revocation. When True
the master will honor the minion's request and revoke its key. When False,
the master will drop the request and the minion's key will remain accepted.
.. code-block:: yaml
rotate_aes_key: True
Master Module Management
========================
@ -1172,6 +1328,99 @@ root of the base environment.
state_top: top.sls
.. conf_master:: state_top_saltenv
``state_top_saltenv``
---------------------
This option has no default value. Set it to an environment name to ensure that
*only* the top file from that environment is considered during a
:ref:`highstate <running-highstate>`.
.. note::
Using this value does not change the merging strategy. For instance, if
:conf_master:`top_file_merging_strategy` is set to ``merge``, and
:conf_master:`state_top_saltenv` is set to ``foo``, then any sections for
environments other than ``foo`` in the top file for the ``foo`` environment
will be ignored. With :conf_master:`state_top_saltenv` set to ``base``, all
states from all environments in the ``base`` top file will be applied,
while all other top files are ignored. The only way to set
:conf_master:`state_top_saltenv` to something other than ``base`` and not
have the other environments in the targeted top file ignored, would be to
set :conf_master:`top_file_merging_strategy` to ``merge_all``.
.. code-block:: yaml
state_top_saltenv: dev
.. conf_master:: top_file_merging_strategy
``top_file_merging_strategy``
-----------------------------
.. versionchanged:: 2016.11.0
A ``merge_all`` strategy has been added.
Default: ``merge``
When no specific fileserver environment (a.k.a. ``saltenv``) has been specified
for a :ref:`highstate <running-highstate>`, all environments' top files are
inspected. This config option determines how the SLS targets in those top files
are handled.
When set to ``merge``, the ``base`` environment's top file is evaluated first,
followed by the other environments' top files. The first target expression
(e.g. ``'*'``) for a given environment is kept, and when the same target
expression is used in a different top file evaluated later, it is ignored.
Because ``base`` is evaluated first, it is authoritative. For example, if there
is a target for ``'*'`` for the ``foo`` environment in both the ``base`` and
``foo`` environment's top files, the one in the ``foo`` environment would be
ignored. The environments will be evaluated in no specific order (aside from
``base`` coming first). For greater control over the order in which the
environments are evaluated, use :conf_master:`env_order`. Note that, aside from
the ``base`` environment's top file, any sections in top files that do not
match that top file's environment will be ignored. So, for example, a section
for the ``qa`` environment would be ignored if it appears in the ``dev``
environment's top file. To keep use cases like this from being ignored, use the
``merge_all`` strategy.
When set to ``same``, then for each environment, only that environment's top
file is processed, with the others being ignored. For example, only the ``dev``
environment's top file will be processed for the ``dev`` environment, and any
SLS targets defined for ``dev`` in the ``base`` environment's (or any other
environment's) top file will be ignored. If an environment does not have a top
file, then the top file from the :conf_master:`default_top` config parameter
will be used as a fallback.
When set to ``merge_all``, then all states in all environments in all top files
will be applied. The order in which individual SLS files will be executed will
depend on the order in which the top files were evaluated, and the environments
will be evaluated in no specific order. For greater control over the order in
which the environments are evaluated, use :conf_master:`env_order`.
.. code-block:: yaml
top_file_merging_strategy: same
.. conf_master:: env_order
``env_order``
-------------
Default: ``[]``
When :conf_master:`top_file_merging_strategy` is set to ``merge``, and no
environment is specified for a :ref:`highstate <running-highstate>`, this
config option allows for the order in which top files are evaluated to be
explicitly defined.
.. code-block:: yaml
env_order:
- base
- dev
- qa
.. conf_master:: master_tops
``master_tops``
@ -1220,6 +1469,23 @@ The renderer to use on the minions to render the state data.
renderer: yaml_jinja
.. conf_master:: userdata_template
``userdata_template``
---------------------
.. versionadded:: 2016.11.4
Default: ``None``
The renderer to use for templating userdata files in salt-cloud, if the
``userdata_template`` is not set in the cloud profile. If no value is set in
the cloud profile or master config file, no templating will be performed.
.. code-block:: yaml
userdata_template: jinja
.. conf_master:: jinja_trim_blocks
``jinja_trim_blocks``
@ -1473,6 +1739,25 @@ on a large number of minions.
fileserver_list_cache_time: 5
.. conf_master:: fileserver_verify_config
``fileserver_verify_config``
------------------------------
.. versionadded:: Nitrogen
Default: ``True``
By default, as the master starts it performs some sanity checks on the
configured fileserver backends. If any of these sanity checks fail (such as
when an invalid configuration is used), the master daemon will abort.
To skip these sanity checks, set this option to ``False``.
.. code-block:: yaml
fileserver_verify_config: False
.. conf_master:: hash_type
``hash_type``
@ -1633,35 +1918,42 @@ Walkthrough <gitfs-per-remote-config>`.
Optional parameter used to specify the provider to be used for gitfs. More
information can be found in the :ref:`GitFS Walkthrough <gitfs-dependencies>`.
Must be one of the following: ``pygit2``, ``gitpython``, or ``dulwich``. If
unset, then each will be tried in that same order, and the first one with a
compatible version installed will be the provider that is used.
Must be either ``pygit2`` or ``gitpython``. If unset, then each will be tried
in that same order, and the first one with a compatible version installed will
be the provider that is used.
.. code-block:: yaml
gitfs_provider: dulwich
gitfs_provider: gitpython
.. conf_master:: gitfs_ssl_verify
``gitfs_ssl_verify``
********************
.. versionchanged:: 2016.11.0
Default: ``True``
Specifies whether or not to ignore SSL certificate errors when contacting the
remote repository. The ``False`` setting is useful if you're using a
git repo that uses a self-signed certificate. However, keep in mind that
setting this to anything other ``True`` is a considered insecure, and using an
SSH-based transport (if available) may be a better option.
In the 2016.11.0 release, the default config value changed from ``False`` to
``True``.
Specifies whether or not to ignore SSL certificate errors when fetching from
the repositories configured in :conf_master:`gitfs_remotes`. The ``False``
setting is useful if you're using a git repo that uses a self-signed
certificate. However, keep in mind that setting this to anything other ``True``
is a considered insecure, and using an SSH-based transport (if available) may
be a better option.
.. code-block:: yaml
gitfs_ssl_verify: True
gitfs_ssl_verify: False
.. note::
pygit2 only supports disabling SSL verification in versions 0.23.2 and
newer.
.. versionchanged:: 2015.8.0
This option can now be configured on individual repositories as well. See
:ref:`here <gitfs-per-remote-config>` for more info.
.. versionchanged:: 2016.11.0
The default config value changed from ``False`` to ``True``.
.. conf_master:: gitfs_mountpoint
@ -1674,8 +1966,8 @@ Default: ``''``
Specifies a path on the salt fileserver which will be prepended to all files
served by gitfs. This option can be used in conjunction with
:conf_master:`gitfs_root`. It can also be configured on a per-remote basis, see
:ref:`here <gitfs-per-remote-config>` for more info.
:conf_master:`gitfs_root`. It can also be configured for an individual
repository, see :ref:`here <gitfs-per-remote-config>` for more info.
.. code-block:: yaml
@ -1707,8 +1999,8 @@ directories above the one specified will be ignored and the relative path will
gitfs_root: somefolder/otherfolder
.. versionchanged:: 2014.7.0
Ability to specify gitfs roots on a per-remote basis was added. See
:ref:`here <gitfs-per-remote-config>` for more info.
This option can now be configured on individual repositories as well. See
:ref:`here <gitfs-per-remote-config>` for more info.
.. conf_master:: gitfs_base
@ -1724,9 +2016,8 @@ Defines which branch/tag should be used as the ``base`` environment.
gitfs_base: salt
.. versionchanged:: 2014.7.0
Ability to specify the base on a per-remote basis was added. See :ref:`here
<gitfs-per-remote-config>` for more info.
This option can now be configured on individual repositories as well. See
:ref:`here <gitfs-per-remote-config>` for more info.
.. conf_master:: gitfs_saltenv
@ -1751,12 +2042,14 @@ gitfs remotes.
- dev:
- ref: develop
.. conf_master:: gitfs_env_whitelist
.. conf_master:: gitfs_saltenv_whitelist
``gitfs_env_whitelist``
***********************
``gitfs_saltenv_whitelist``
***************************
.. versionadded:: 2014.7.0
.. versionchanged:: Oxygen
Renamed from ``gitfs_env_whitelist`` to ``gitfs_saltenv_whitelist``
Default: ``[]``
@ -1767,17 +2060,19 @@ information can be found in the :ref:`GitFS Walkthrough
.. code-block:: yaml
gitfs_env_whitelist:
gitfs_saltenv_whitelist:
- base
- v1.*
- 'mybranch\d+'
.. conf_master:: gitfs_env_blacklist
.. conf_master:: gitfs_saltenv_blacklist
``gitfs_env_blacklist``
***********************
``gitfs_saltenv_blacklist``
***************************
.. versionadded:: 2014.7.0
.. versionchanged:: Oxygen
Renamed from ``gitfs_env_blacklist`` to ``gitfs_saltenv_blacklist``
Default: ``[]``
@ -1788,7 +2083,7 @@ information can be found in the :ref:`GitFS Walkthrough
.. code-block:: yaml
gitfs_env_blacklist:
gitfs_saltenv_blacklist:
- base
- v1.*
- 'mybranch\d+'
@ -1847,6 +2142,11 @@ remotes.
gitfs_user: git
.. note::
This is is a global configuration option, see :ref:`here
<gitfs-per-remote-config>` for examples of configuring it for individual
repositories.
.. conf_master:: gitfs_password
``gitfs_password``
@ -1863,6 +2163,11 @@ This parameter is not required if the repository does not use authentication.
gitfs_password: mypassword
.. note::
This is is a global configuration option, see :ref:`here
<gitfs-per-remote-config>` for examples of configuring it for individual
repositories.
.. conf_master:: gitfs_insecure_auth
``gitfs_insecure_auth``
@ -1879,6 +2184,11 @@ parameter enables authentication over HTTP. **Enable this at your own risk.**
gitfs_insecure_auth: True
.. note::
This is is a global configuration option, see :ref:`here
<gitfs-per-remote-config>` for examples of configuring it for individual
repositories.
.. conf_master:: gitfs_pubkey
``gitfs_pubkey``
@ -1889,14 +2199,18 @@ parameter enables authentication over HTTP. **Enable this at your own risk.**
Default: ``''``
Along with :conf_master:`gitfs_privkey` (and optionally
:conf_master:`gitfs_passphrase`), is used to authenticate to SSH remotes. This
parameter (or its :ref:`per-remote counterpart <gitfs-per-remote-config>`) is
required for SSH remotes.
:conf_master:`gitfs_passphrase`), is used to authenticate to SSH remotes.
Required for SSH remotes.
.. code-block:: yaml
gitfs_pubkey: /path/to/key.pub
.. note::
This is is a global configuration option, see :ref:`here
<gitfs-per-remote-config>` for examples of configuring it for individual
repositories.
.. conf_master:: gitfs_privkey
``gitfs_privkey``
@ -1907,14 +2221,18 @@ required for SSH remotes.
Default: ``''``
Along with :conf_master:`gitfs_pubkey` (and optionally
:conf_master:`gitfs_passphrase`), is used to authenticate to SSH remotes. This
parameter (or its :ref:`per-remote counterpart <gitfs-per-remote-config>`) is
required for SSH remotes.
:conf_master:`gitfs_passphrase`), is used to authenticate to SSH remotes.
Required for SSH remotes.
.. code-block:: yaml
gitfs_privkey: /path/to/key
.. note::
This is is a global configuration option, see :ref:`here
<gitfs-per-remote-config>` for examples of configuring it for individual
repositories.
.. conf_master:: gitfs_passphrase
``gitfs_passphrase``
@ -1931,6 +2249,33 @@ authenticate is protected by a passphrase.
gitfs_passphrase: mypassphrase
.. note::
This is is a global configuration option, see :ref:`here
<gitfs-per-remote-config>` for examples of configuring it for individual
repositories.
.. conf_master:: gitfs_refspecs
``gitfs_refspecs``
~~~~~~~~~~~~~~~~~~
.. versionadded:: Nitrogen
Default: ``['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']``
When fetching from remote repositories, by default Salt will fetch branches and
tags. This parameter can be used to override the default and specify
alternate refspecs to be fetched. More information on how this feature works
can be found in the :ref:`GitFS Walkthrough <gitfs-custom-refspecs>`.
.. code-block:: yaml
gitfs_refspecs:
- '+refs/heads/*:refs/remotes/origin/*'
- '+refs/tags/*:refs/tags/*'
- '+refs/pull/*/head:refs/remotes/origin/pr/*'
- '+refs/pull/*/merge:refs/remotes/origin/merge/*'
hg: Mercurial Remote File Server Backend
----------------------------------------
@ -2071,12 +2416,14 @@ bookmark should be used as the ``base`` environment.
hgfs_base: salt
.. conf_master:: hgfs_env_whitelist
.. conf_master:: hgfs_saltenv_whitelist
``hgfs_env_whitelist``
**********************
``hgfs_saltenv_whitelist``
**************************
.. versionadded:: 2014.7.0
.. versionchanged:: Oxygen
Renamed from ``hgfs_env_whitelist`` to ``hgfs_saltenv_whitelist``
Default: ``[]``
@ -2088,23 +2435,25 @@ expression must match the entire minion ID.
If used, only branches/bookmarks/tags which match one of the specified
expressions will be exposed as fileserver environments.
If used in conjunction with :conf_master:`hgfs_env_blacklist`, then the subset
If used in conjunction with :conf_master:`hgfs_saltenv_blacklist`, then the subset
of branches/bookmarks/tags which match the whitelist but do *not* match the
blacklist will be exposed as fileserver environments.
.. code-block:: yaml
hgfs_env_whitelist:
hgfs_saltenv_whitelist:
- base
- v1.*
- 'mybranch\d+'
.. conf_master:: hgfs_env_blacklist
.. conf_master:: hgfs_saltenv_blacklist
``hgfs_env_blacklist``
**********************
``hgfs_saltenv_blacklist``
**************************
.. versionadded:: 2014.7.0
.. versionchanged:: Oxygen
Renamed from ``hgfs_env_blacklist`` to ``hgfs_saltenv_blacklist``
Default: ``[]``
@ -2116,13 +2465,13 @@ expression must match the entire minion ID.
If used, branches/bookmarks/tags which match one of the specified expressions
will *not* be exposed as fileserver environments.
If used in conjunction with :conf_master:`hgfs_env_whitelist`, then the subset
If used in conjunction with :conf_master:`hgfs_saltenv_whitelist`, then the subset
of branches/bookmarks/tags which match the whitelist but do *not* match the
blacklist will be exposed as fileserver environments.
.. code-block:: yaml
hgfs_env_blacklist:
hgfs_saltenv_blacklist:
- base
- v1.*
- 'mybranch\d+'
@ -2278,12 +2627,14 @@ also be configured on a per-remote basis, see :conf_master:`here
svnfs_tags: tags
.. conf_master:: svnfs_env_whitelist
.. conf_master:: svnfs_saltenv_whitelist
``svnfs_env_whitelist``
***********************
``svnfs_saltenv_whitelist``
***************************
.. versionadded:: 2014.7.0
.. versionchanged:: Oxygen
Renamed from ``svnfs_env_whitelist`` to ``svnfs_saltenv_whitelist``
Default: ``[]``
@ -2295,23 +2646,25 @@ must match the entire minion ID.
If used, only branches/tags which match one of the specified expressions will
be exposed as fileserver environments.
If used in conjunction with :conf_master:`svnfs_env_blacklist`, then the subset
If used in conjunction with :conf_master:`svnfs_saltenv_blacklist`, then the subset
of branches/tags which match the whitelist but do *not* match the blacklist
will be exposed as fileserver environments.
.. code-block:: yaml
svnfs_env_whitelist:
svnfs_saltenv_whitelist:
- base
- v1.*
- 'mybranch\d+'
.. conf_master:: svnfs_env_blacklist
.. conf_master:: svnfs_saltenv_blacklist
``svnfs_env_blacklist``
***********************
``svnfs_saltenv_blacklist``
***************************
.. versionadded:: 2014.7.0
.. versionchanged:: Oxygen
Renamed from ``svnfs_env_blacklist`` to ``svnfs_saltenv_blacklist``
Default: ``[]``
@ -2323,13 +2676,13 @@ expression must match the entire minion ID.
If used, branches/tags which match one of the specified expressions will *not*
be exposed as fileserver environments.
If used in conjunction with :conf_master:`svnfs_env_whitelist`, then the subset
If used in conjunction with :conf_master:`svnfs_saltenv_whitelist`, then the subset
of branches/tags which match the whitelist but do *not* match the blacklist
will be exposed as fileserver environments.
.. code-block:: yaml
svnfs_env_blacklist:
svnfs_saltenv_blacklist:
- base
- v1.*
- 'mybranch\d+'
@ -2455,6 +2808,108 @@ configuration is the same as :conf_master:`file_roots`:
prod:
- /srv/pillar/prod
.. conf_master:: on_demand_ext_pillar
``on_demand_ext_pillar``
------------------------
.. versionadded:: 2016.3.6,2016.11.3,Nitrogen
Default: ``['libvirt', 'virtkey']``
The external pillars permitted to be used on-demand using :py:func:`pillar.ext
<salt.modules.pillar.ext>`.
.. code-block:: yaml
on_demand_ext_pillar:
- libvirt
- virtkey
- git
.. warning::
This will allow minions to request specific pillar data via
:py:func:`pillar.ext <salt.modules.pillar.ext>`, and may be considered a
security risk. However, pillar data generated in this way will not affect
the :ref:`in-memory pillar data <pillar-in-memory>`, so this risk is
limited to instances in which states/modules/etc. (built-in or custom) rely
upon pillar data generated by :py:func:`pillar.ext
<salt.modules.pillar.ext>`.
.. conf_master:: decrypt_pillar
``decrypt_pillar``
------------------
.. versionadded:: Nitrogen
Default: ``[]``
A list of paths to be recursively decrypted during pillar compilation.
.. code-block:: yaml
decrypt_pillar:
- 'foo:bar': gpg
- 'lorem:ipsum:dolor'
Entries in this list can be formatted either as a simple string, or as a
key/value pair, with the key being the pillar location, and the value being the
renderer to use for pillar decryption. If the former is used, the renderer
specified by :conf_master:`decrypt_pillar_default` will be used.
.. conf_master:: decrypt_pillar_delimiter
``decrypt_pillar_delimiter``
----------------------------
.. versionadded:: Nitrogen
Default: ``:``
The delimiter used to distinguish nested data structures in the
:conf_master:`decrypt_pillar` option.
.. code-block:: yaml
decrypt_pillar_delimiter: '|'
decrypt_pillar:
- 'foo|bar': gpg
- 'lorem|ipsum|dolor'
.. conf_master:: decrypt_pillar_default
``decrypt_pillar_default``
--------------------------
.. versionadded:: Nitrogen
Default: ``gpg``
The default renderer used for decryption, if one is not specified for a given
pillar key in :conf_master:`decrypt_pillar`.
.. code-block:: yaml
decrypt_pillar_default: my_custom_renderer
.. conf_master:: decrypt_pillar_renderers
``decrypt_pillar_renderers``
----------------------------
.. versionadded:: Nitrogen
Default: ``['gpg']``
List of renderers which are permitted to be used for pillar decryption.
.. code-block:: yaml
decrypt_pillar_renderers:
- gpg
- my_custom_renderer
.. conf_master:: pillar_opts
``pillar_opts``
@ -2728,6 +3183,10 @@ In the 2016.11.0 release, the default config value changed from ``False`` to
git_pillar_ssl_verify: True
.. note::
pygit2 only supports disabling SSL verification in versions 0.23.2 and
newer.
.. conf_master:: git_pillar_global_lock
``git_pillar_global_lock``
@ -2758,13 +3217,36 @@ they were created by a different master.
.. __: http://www.gluster.org/
.. conf_master:: git_pillar_includes
``git_pillar_includes``
***********************
.. versionadded:: Nitrogen
Default: ``True``
Normally, when processing :ref:`git_pillar remotes
<git-pillar-2015-8-0-and-later>`, if more than one repo under the same ``git``
section in the ``ext_pillar`` configuration refers to the same pillar
environment, then each repo in a given environment will have access to the
other repos' files to be referenced in their top files. However, it may be
desirable to disable this behavior. If so, set this value to ``False``.
For a more detailed examination of how includes work, see :ref:`this
explanation <git-pillar-multiple-remotes>` from the git_pillar documentation.
.. code-block:: yaml
git_pillar_includes: False
.. _git-ext-pillar-auth-opts:
Git External Pillar Authentication Options
******************************************
These parameters only currently apply to the ``pygit2``
:conf_master:`git_pillar_provider`. Authentication works the same as it does
:conf_master:`git_pillar_provider`. Authentication works the same as it does
in gitfs, as outlined in the :ref:`GitFS Walkthrough <gitfs-authentication>`,
though the global configuration options are named differently to reflect that
they are for git_pillar instead of gitfs.
@ -2866,6 +3348,48 @@ authenticate is protected by a passphrase.
git_pillar_passphrase: mypassphrase
.. conf_master:: git_pillar_refspecs
``git_pillar_refspecs``
~~~~~~~~~~~~~~~~~~~~~~~
.. versionadded:: Nitrogen
Default: ``['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']``
When fetching from remote repositories, by default Salt will fetch branches and
tags. This parameter can be used to override the default and specify
alternate refspecs to be fetched. This parameter works similarly to its
:ref:`GitFS counterpart <git_pillar-custom-refspecs>`, in that it can be
configured both globally and for individual remotes.
.. code-block:: yaml
git_pillar_refspecs:
- '+refs/heads/*:refs/remotes/origin/*'
- '+refs/tags/*:refs/tags/*'
- '+refs/pull/*/head:refs/remotes/origin/pr/*'
- '+refs/pull/*/merge:refs/remotes/origin/merge/*'
.. conf_master:: git_pillar_verify_config
``git_pillar_verify_config``
----------------------------
.. versionadded:: Nitrogen
Default: ``True``
By default, as the master starts it performs some sanity checks on the
configured git_pillar repositories. If any of these sanity checks fail (such as
when an invalid configuration is used), the master daemon will abort.
To skip these sanity checks, set this option to ``False``.
.. code-block:: yaml
git_pillar_verify_config: False
.. _pillar-merging-opts:
Pillar Merging Options
@ -3833,3 +4357,26 @@ authenticate is protected by a passphrase.
.. code-block:: yaml
winrepo_passphrase: mypassphrase
.. conf_master:: winrepo_refspecs
``winrepo_refspecs``
~~~~~~~~~~~~~~~~~~~~
.. versionadded:: Nitrogen
Default: ``['+refs/heads/*:refs/remotes/origin/*', '+refs/tags/*:refs/tags/*']``
When fetching from remote repositories, by default Salt will fetch branches and
tags. This parameter can be used to override the default and specify
alternate refspecs to be fetched. This parameter works similarly to its
:ref:`GitFS counterpart <winrepo-custom-refspecs>`, in that it can be
configured both globally and for individual remotes.
.. code-block:: yaml
winrepo_refspecs:
- '+refs/heads/*:refs/remotes/origin/*'
- '+refs/tags/*:refs/tags/*'
- '+refs/pull/*/head:refs/remotes/origin/pr/*'
- '+refs/pull/*/merge:refs/remotes/origin/merge/*'

504
doc/ref/configuration/minion.rst
View File

@ -31,7 +31,8 @@ Minion Primary Configuration
Default: ``salt``
The hostname or ipv4 of the master.
The hostname or IP address of the master. See :conf_minion:`ipv6` for IPv6
connections to the master.
Default: ``salt``
@ -39,6 +40,33 @@ Default: ``salt``
master: salt
master:port Syntax
~~~~~~~~~~~~~~~~~~
.. versionadded:: 2015.8.0
The ``master`` config option can also be set to use the master's IP in
conjunction with a port number by default.
.. code-block:: yaml
master: localhost:1234
For IPv6 formatting with a port, remember to add brackets around the IP address
before adding the port and enclose the line in single quotes to make it a string:
.. code-block:: yaml
master: '[2001:db8:85a3:8d3:1319:8a2e:370:7348]:1234'
.. note::
If a port is specified in the ``master`` as well as :conf_minion:`master_port`,
the ``master_port`` setting will be overridden by the ``master`` configuration.
List of Masters Syntax
~~~~~~~~~~~~~~~~~~~~~~
The option can also be set to a list of masters, enabling
:ref:`multi-master <tutorial-multi-master>` mode.
@ -75,6 +103,36 @@ The option can also be set to a list of masters, enabling
- address2
master_type: failover
.. conf_minion:: ipv6
``ipv6``
--------
Default: ``None``
Whether the master should be connected over IPv6. By default salt minion
will try to automatically detect IPv6 connectivity to master.
.. code-block:: yaml
ipv6: True
.. conf_minion:: master_uri_format
``master_uri_format``
---------------------
.. versionadded:: 2015.8.0
Specify the format in which the master address will be evaluated. Valid options
are ``default`` or ``ip_only``. If ``ip_only`` is specified, then the master
address will not be split into IP and PORT, so be sure that only an IP (or domain
name) is set in the :conf_minion:`master` configuration setting.
.. code-block:: yaml
master_uri_format: ip_only
.. conf_minion:: master_type
``master_type``
@ -191,9 +249,10 @@ to the next master in the list if it finds the existing one is dead.
Default: ``False``
If :conf_minion:`master` is a list of addresses and :conf_minion`master_type` is ``failover``, shuffle them before trying to
connect to distribute the minions over all available masters. This uses
Python's :func:`random.shuffle <python2:random.shuffle>` method.
If :conf_minion:`master` is a list of addresses and :conf_minion`master_type`
is ``failover``, shuffle them before trying to connect to distribute the
minions over all available masters. This uses Python's :func:`random.shuffle
<python2:random.shuffle>` method.
.. code-block:: yaml
@ -206,9 +265,10 @@ Python's :func:`random.shuffle <python2:random.shuffle>` method.
Default: ``False``
If :conf_minion:`master` is a list of addresses, shuffle them before trying to
connect to distribute the minions over all available masters. This uses
Python's :func:`random.randint <python2:random.randint>` method.
If :conf_minion:`master` is a list of addresses, and :conf_minion`master_type`
is set to ``failover`` shuffle them before trying to connect to distribute the
minions over all available masters. This uses Python's :func:`random.shuffle
<python2:random.shuffle>` method.
.. code-block:: yaml
@ -388,6 +448,20 @@ FQDN (for instance, Solaris).
append_domain: foo.org
.. conf_minion:: minion_id_lowercase
``minion_id_lowercase``
-----------------------
Default: ``False``
Convert minion id to lowercase when it is being generated. Helpful when some hosts
get the minion id in uppercase. Cached ids will remain the same and not converted.
.. code-block:: yaml
minion_id_lowercase: True
.. conf_minion:: cachedir
``cachedir``
@ -745,6 +819,24 @@ restart.
.. conf_minion:: recon_default
``random_startup_delay``
------------------------
Default: ``0``
The maximum bound for an interval in which a minion will randomly sleep upon starting
up prior to attempting to connect to a master. This can be used to splay connection attempts
for cases where many minions starting up at once may place undue load on a master.
For example, setting this to ``5`` will tell a minion to sleep for a value between ``0``
and ``5`` seconds.
.. code-block:: yaml
random_startup_delay: 5
.. conf_minion:: random_startup_delay
``recon_default``
-----------------
@ -1183,6 +1275,174 @@ below.
providers:
service: systemd
``extmod_whitelist/extmod_blacklist``
--------------------
.. versionadded:: Nitrogen
By using this dictionary, the modules that are synced to the minion's extmod cache using `saltutil.sync_*` can be
limited. If nothing is set to a specific type, then all modules are accepted. To block all modules of a specific type,
whitelist an empty list.
.. code-block:: yaml
extmod_whitelist:
modules:
- custom_module
engines:
- custom_engine
pillars: []
extmod_blacklist:
modules:
- specific_module
Valid options:
- beacons
- clouds
- sdb
- modules
- states
- grains
- renderers
- returners
- proxy
- engines
- output
- utils
- pillar
Top File Settings
=================
These parameters only have an effect if running a masterless minion.
.. conf_minion:: state_top
``state_top``
-------------
Default: ``top.sls``
The state system uses a "top" file to tell the minions what environment to
use and what modules to use. The state_top file is defined relative to the
root of the base environment.
.. code-block:: yaml
state_top: top.sls
.. conf_minion:: state_top_saltenv
``state_top_saltenv``
---------------------
This option has no default value. Set it to an environment name to ensure that
*only* the top file from that environment is considered during a
:ref:`highstate <running-highstate>`.
.. note::
Using this value does not change the merging strategy. For instance, if
:conf_minion:`top_file_merging_strategy` is set to ``merge``, and
:conf_minion:`state_top_saltenv` is set to ``foo``, then any sections for
environments other than ``foo`` in the top file for the ``foo`` environment
will be ignored. With :conf_minion:`state_top_saltenv` set to ``base``, all
states from all environments in the ``base`` top file will be applied,
while all other top files are ignored. The only way to set
:conf_minion:`state_top_saltenv` to something other than ``base`` and not
have the other environments in the targeted top file ignored, would be to
set :conf_minion:`top_file_merging_strategy` to ``merge_all``.
.. code-block:: yaml
state_top_saltenv: dev
.. conf_minion:: top_file_merging_strategy
``top_file_merging_strategy``
-----------------------------
.. versionchanged:: 2016.11.0
A ``merge_all`` strategy has been added.
Default: ``merge``
When no specific fileserver environment (a.k.a. ``saltenv``) has been specified
for a :ref:`highstate <running-highstate>`, all environments' top files are
inspected. This config option determines how the SLS targets in those top files
are handled.
When set to ``merge``, the ``base`` environment's top file is evaluated first,
followed by the other environments' top files. The first target expression
(e.g. ``'*'``) for a given environment is kept, and when the same target
expression is used in a different top file evaluated later, it is ignored.
Because ``base`` is evaluated first, it is authoritative. For example, if there
is a target for ``'*'`` for the ``foo`` environment in both the ``base`` and
``foo`` environment's top files, the one in the ``foo`` environment would be
ignored. The environments will be evaluated in no specific order (aside from
``base`` coming first). For greater control over the order in which the
environments are evaluated, use :conf_minion:`env_order`. Note that, aside from
the ``base`` environment's top file, any sections in top files that do not
match that top file's environment will be ignored. So, for example, a section
for the ``qa`` environment would be ignored if it appears in the ``dev``
environment's top file. To keep use cases like this from being ignored, use the
``merge_all`` strategy.
When set to ``same``, then for each environment, only that environment's top
file is processed, with the others being ignored. For example, only the ``dev``
environment's top file will be processed for the ``dev`` environment, and any
SLS targets defined for ``dev`` in the ``base`` environment's (or any other
environment's) top file will be ignored. If an environment does not have a top
file, then the top file from the :conf_minion:`default_top` config parameter
will be used as a fallback.
When set to ``merge_all``, then all states in all environments in all top files
will be applied. The order in which individual SLS files will be executed will
depend on the order in which the top files were evaluated, and the environments
will be evaluated in no specific order. For greater control over the order in
which the environments are evaluated, use :conf_minion:`env_order`.
.. code-block:: yaml
top_file_merging_strategy: same
.. conf_minion:: env_order
``env_order``
-------------
Default: ``[]``
When :conf_minion:`top_file_merging_strategy` is set to ``merge``, and no
environment is specified for a :ref:`highstate <running-highstate>`, this
config option allows for the order in which top files are evaluated to be
explicitly defined.
.. code-block:: yaml
env_order:
- base
- dev
- qa
.. conf_minion:: default_top
``default_top``
---------------
Default: ``base``
When :conf_minion:`top_file_merging_strategy` is set to ``same``, and no
environment is specified for a :ref:`highstate <running-highstate>` (i.e.
:conf_minion:`environment` is not set for the minion), this config option
specifies a fallback environment in which to look for a top file if an
environment lacks one.
.. code-block:: yaml
default_top: dev
State Management Settings
=========================
@ -1272,6 +1532,10 @@ enabled and can be disabled by changing this value to ``False``.
clean_dynamic_modules: True
.. note::
If ``extmod_whitelist`` is specified, modules which are not whitelisted will also be cleaned here.
.. conf_minion:: environment
``environment``
@ -1286,111 +1550,6 @@ environments is to isolate via the top file.
environment: dev
.. conf_minion:: state_top_saltenv
``state_top_saltenv``
---------------------
This option has no default value. Set it to an environment name to ensure that
*only* the top file from that environment is considered during a
:ref:`highstate <running-highstate>`.
.. note::
Using this value does not change the merging strategy. For instance, if
:conf_minion:`top_file_merging_strategy` is set to ``merge``, and
:conf_minion:`state_top_saltenv` is set to ``foo``, then any sections for
environments other than ``foo`` in the top file for the ``foo`` environment
will be ignored. With :conf_minion:`state_top_saltenv` set to ``base``, all
states from all environments in the ``base`` top file will be applied,
while all other top files are ignored. The only way to set
:conf_minion:`state_top_saltenv` to something other than ``base`` and not
have the other environments in the targeted top file ignored, would be to
set :conf_minion:`top_file_merging_strategy` to ``merge_all``.
.. code-block:: yaml
state_top_saltenv: dev
.. conf_minion:: top_file_merging_strategy
``top_file_merging_strategy``
-----------------------------
.. versionchanged:: 2016.11.0
A ``merge_all`` strategy has been added.
Default: ``merge``
When no specific fileserver environment (a.k.a. ``saltenv``) has been specified
for a :ref:`highstate <running-highstate>`, all environments' top files are
inspected. This config option determines how the SLS targets in those top files
are handled.
When set to ``merge``, the ``base`` environment's top file is evaluated first,
followed by the other environments' top files. The first target expression
(e.g. ``'*'``) for a given environment is kept, and when the same target
expression is used in a different top file evaluated later, it is ignored.
Because ``base`` is evaluated first, it is authoritative. For example, if there
is a target for ``'*'`` for the ``foo`` environment in both the ``base`` and
``foo`` environment's top files, the one in the ``foo`` environment would be
ignored. The environments will be evaluated in no specific order (aside from
``base`` coming first). For greater control over the order in which the
environments are evaluated, use :conf_minion:`env_order`.
When set to ``same``, then for each environment, only that environment's top
file is processed, with the others being ignored. For example, only the ``dev``
environment's top file will be processed for the ``dev`` environment, and any
SLS targets defined for ``dev`` in the ``base`` environment's (or any other
environment's) top file will be ignored. If an environment does not have a top
file, then the top file from the :conf_minion:`default_top` config parameter
will be used as a fallback.
When set to ``merge_all``, then all states in all environments in all top files
will be applied. The order in which individual SLS files will be executed will
depend on the order in which the top files were evaluated, and the environments
will be evaluated in no specific order. For greater control over the order in
which the environments are evaluated, use :conf_minion:`env_order`.
.. code-block:: yaml
top_file_merging_strategy: same
.. conf_minion:: env_order
``env_order``
-------------
Default: ``[]``
When :conf_minion:`top_file_merging_strategy` is set to ``merge``, and no
environment is specified for a :ref:`highstate <running-highstate>`, this
config option allows for the order in which top files are evaluated to be
explicitly defined.
.. code-block:: yaml
env_order:
- base
- dev
- qa
.. conf_minion:: default_top
``default_top``
---------------
Default: ``base``
When :conf_minion:`top_file_merging_strategy` is set to ``same``, and no
environment is specified for a :ref:`highstate <running-highstate>` (i.e.
:conf_minion:`environment` is not set for the minion), this config option
specifies a fallback environment in which to look for a top file if an
environment lacks one.
.. code-block:: yaml
default_top: dev
.. conf_minion:: snapper_states
``snapper_states``
@ -1583,6 +1742,109 @@ the pillar environments.
prod:
- /srv/pillar/prod
.. conf_minion:: on_demand_ext_pillar
``on_demand_ext_pillar``
------------------------
.. versionadded:: 2016.3.6,2016.11.3,Nitrogen
Default: ``['libvirt', 'virtkey']``
When using a local :conf_minion:`file_client`, this option controls which
external pillars are permitted to be used on-demand using :py:func:`pillar.ext
<salt.modules.pillar.ext>`.
.. code-block:: yaml
on_demand_ext_pillar:
- libvirt
- virtkey
- git
.. warning::
This will allow a masterless minion to request specific pillar data via
:py:func:`pillar.ext <salt.modules.pillar.ext>`, and may be considered a
security risk. However, pillar data generated in this way will not affect
the :ref:`in-memory pillar data <pillar-in-memory>`, so this risk is
limited to instances in which states/modules/etc. (built-in or custom) rely
upon pillar data generated by :py:func:`pillar.ext
<salt.modules.pillar.ext>`.
.. conf_minion:: decrypt_pillar
``decrypt_pillar``
------------------
.. versionadded:: Nitrogen
Default: ``[]``
A list of paths to be recursively decrypted during pillar compilation.
.. code-block:: yaml
decrypt_pillar:
- 'foo:bar': gpg
- 'lorem:ipsum:dolor'
Entries in this list can be formatted either as a simple string, or as a
key/value pair, with the key being the pillar location, and the value being the
renderer to use for pillar decryption. If the former is used, the renderer
specified by :conf_minion:`decrypt_pillar_default` will be used.
.. conf_minion:: decrypt_pillar_delimiter
``decrypt_pillar_delimiter``
----------------------------
.. versionadded:: Nitrogen
Default: ``:``
The delimiter used to distinguish nested data structures in the
:conf_minion:`decrypt_pillar` option.
.. code-block:: yaml
decrypt_pillar_delimiter: '|'
decrypt_pillar:
- 'foo|bar': gpg
- 'lorem|ipsum|dolor'
.. conf_minion:: decrypt_pillar_default
``decrypt_pillar_default``
--------------------------
.. versionadded:: Nitrogen
Default: ``gpg``
The default renderer used for decryption, if one is not specified for a given
pillar key in :conf_minion:`decrypt_pillar`.
.. code-block:: yaml
decrypt_pillar_default: my_custom_renderer
.. conf_minion:: decrypt_pillar_renderers
``decrypt_pillar_renderers``
----------------------------
.. versionadded:: Nitrogen
Default: ``['gpg']``
List of renderers which are permitted to be used for pillar decryption.
.. code-block:: yaml
decrypt_pillar_renderers:
- gpg
- my_custom_renderer
.. conf_minion:: pillarenv
``pillarenv``
@ -1595,13 +1857,15 @@ the environment setting, but for pillar instead of states.
.. code-block:: yaml
pillarenv: None
pillarenv: dev
.. conf_minion:: pillarenv_from_saltenv
``pillarenv_from_saltenv``
--------------------------
.. versionadded:: Nitrogen
Default: ``False``
When set to ``True``, the :conf_minion:`pillarenv` value will assume the value
@ -2025,6 +2289,20 @@ ZeroMQ is installed.
.. conf_minion:: failhard
``tcp_authentication_retries``
------------------------------
Default: ``5``
The number of times to retry authenticating with the salt master when it comes
back online.
Zeromq does a lot to make sure when connections come back online that they
reauthenticate. The tcp transport should try to connect with a new connection
if the old one times out on reauthenticating.
`-1` for infinite tries.
``failhard``
------------

120
doc/ref/configuration/proxy.rst Normal file
View File

@ -0,0 +1,120 @@
.. _configuration-salt-proxy:
=================================
Configuring the Salt Proxy Minion
=================================
The Salt system is amazingly simple and easy to configure. The two components
of the Salt system each have a respective configuration file. The
:command:`salt-master` is configured via the master configuration file, and the
:command:`salt-proxy` is configured via the proxy configuration file.
.. seealso::
:ref:`example proxy minion configuration file <configuration-examples-proxy>`
The Salt Minion configuration is very simple. Typically, the only value that
needs to be set is the master value so the proxy knows where to locate its master.
By default, the salt-proxy configuration will be in :file:`/etc/salt/proxy`.
A notable exception is FreeBSD, where the configuration will be in
:file:`/usr/local/etc/salt/proxy`.
Proxy-specific Configuration Options
====================================
.. conf_proxy:: add_proxymodule_to_opts
``add_proxymodule_to_opts``
--------------------------
.. versionadded:: 2015.8.2
.. versionchanged:: 2016.3.0
Default: ``False``
Add the proxymodule LazyLoader object to opts.
.. code-block:: yaml
add_proxymodule_to_opts: True
.. conf_proxy:: proxy_merge_grains_in_module
``proxy_merge_grains_in_module``
--------------------------------
.. versionadded:: 2016.3.0
.. versionchanged:: Nitrogen
Default: ``True``
If a proxymodule has a function called ``grains``, then call it during
regular grains loading and merge the results with the proxy's grains
dictionary. Otherwise it is assumed that the module calls the grains
function in a custom way and returns the data elsewhere.
.. code-block:: yaml
proxy_merge_grains_in_module: False
.. conf_proxy:: proxy_keep_alive
``proxy_keep_alive``
--------------------
.. versionadded:: Nitrogen
Default: ``True``
Whether the connection with the remote device should be restarted
when dead. The proxy module must implement the ``alive`` function,
otherwise the connection is considered alive.
.. code-block:: yaml
proxy_keep_alive: False
.. conf_proxy:: proxy_keep_alive_interval
``proxy_keep_alive_interval``
-----------------------------
.. versionadded:: Nitrogen
Default: ``1``
The frequency of keepalive checks, in minutes. It requires the
:conf_proxy:`proxy_keep_alive` option to be enabled
(and the proxy module to implement the ``alive`` function).
.. code-block:: yaml
proxy_keep_alive_interval: 5
.. conf_proxy:: proxy_always_alive
``proxy_always_alive``
----------------------
.. versionadded:: Nitrogen
Default: ``True``
Wheter the proxy should maintain the connection with the remote
device. Similarly to :conf_proxy:`proxy_keep_alive`, this option
is very specific to the design of the proxy module.
When :conf_proxy:`proxy_always_alive` is set to ``False``,
the connection with the remote device is not maintained and
has to be closed after every command.
.. code-block:: yaml
proxy_always_alive: False

4
doc/ref/engines/all/index.rst
View File

@ -11,14 +11,18 @@ engine modules
:template: autosummary.rst.tmpl
docker_events
hipchat
http_logstash
ircbot
junos_syslog
logentries
logstash
napalm_syslog
reactor
redis_sentinel
slack
sqs_events
stalekey
test
thorium
webhook

6
doc/ref/engines/all/salt.engines.junos_syslog.rst Normal file
View File

@ -0,0 +1,6 @@
salt.engines.junos_syslog module
================================
.. automodule:: salt.engines.junos_syslog
:members:
:undoc-members:

6
doc/ref/engines/all/salt.engines.napalm_syslog.rst Normal file
View File

@ -0,0 +1,6 @@
===========================
salt.engines.napalm_syslog
===========================
.. automodule:: salt.engines.napalm_syslog
:members:

6
doc/ref/engines/all/salt.engines.stalekey.rst Normal file
View File

@ -0,0 +1,6 @@
salt.engines.stalekey module
============================
.. automodule:: salt.engines.stalekey
:members:
:undoc-members:

15
doc/ref/executors/all/index.rst Normal file
View File

@ -0,0 +1,15 @@
.. _all-salt.executors:
=================
executors modules
=================
.. currentmodule:: salt.executors
.. autosummary::
:toctree:
:template: autosummary.rst.tmpl
direct_call
splay
sudo

85
doc/ref/executors/index.rst Normal file
View File

@ -0,0 +1,85 @@
.. _executors:
=========
Executors
=========
Executors are used by minion to execute module functions. Executors can be used
to modify the functions behavior, do any pre-execution steps or execute in a
specific way like sudo executor.
Executors could be passed as a list and they will be used one-by-one in the
order. If an executor returns ``None`` the next one will be called. If an
executor returns non-``None`` the execution sequence is terminated and the
returned value is used as a result. It's a way executor could control modules
execution working as a filter. Note that executor could actually not execute
the function but just do something else and return ``None`` like ``splay``
executor does. In this case some other executor have to be used as a final
executor that will actually execute the function. See examples below.
Executors list could be passed by minion config file in the following way:
.. code-block:: yaml
module_executors:
- splay
- direct_call
splaytime: 30
The same could be done by command line:
.. code-block:: bash
salt -t 40 --module-executors='[splay, direct_call]' --executor-opts='{splaytime: 30}' '*' test.ping
And the same command called via netapi will look like this:
.. code-block:: bash
curl -sSk https://localhost:8000 \
-H 'Accept: application/x-yaml' \
-H 'X-Auth-Token: 697adbdc8fe971d09ae4c2a3add7248859c87079' \
-H 'Content-type: application/json' \
-d '[{
"client": "local",
"tgt": "*",
"fun": "test.ping",
"module_executors": ["splay", "direct_call"],
"executor_opts": {"splaytime": 10}
}]'
.. seealso:: :ref:`The full list of executors <all-salt.executors>`
Writing Salt Executors
----------------------
A Salt executor is written in a similar manner to a Salt execution module.
Executor is a python module placed into the ``executors`` folder and containing
the ``execute`` function with the following signature:
.. code-block:: python
def execute(opts, data, func, args, kwargs)
Where the args are:
``opts``:
Dictionary containing the minion configuration options
``data``:
Dictionary containing the load data including ``executor_opts`` passed via
cmdline/API.
``func``, ``args``, ``kwargs``:
Execution module function to be executed and it's arguments. For instance the
simplest ``direct_call`` executor just runs it as ``func(*args, **kwargs)``.
``Returns``:
``None`` if the execution sequence must be continued with the next executor.
Error string or execution result if the job is done and execution must be
stopped.
Specific options could be passed to the executor via minion config or via
``executor_opts`` argument. For instance to access ``splaytime`` option set by
minion config executor should access ``opts.get('splaytime')``. To access the
option set by commandline or API ``data.get('executor_opts',
{}).get('splaytime')`` should be used. So if an option is safe and must be
accessible by user executor should check it in both places, but if an option is
unsafe it should be read from the only config ignoring the passed request data.

2
doc/ref/file_server/dynamic-modules.rst
View File

@ -17,6 +17,7 @@ be used.
The directories are prepended with an underscore:
- :file:`_beacons`
- :file:`_clouds`
- :file:`_engines`
- :file:`_grains`
- :file:`_modules`
@ -25,6 +26,7 @@ The directories are prepended with an underscore:
- :file:`_renderers`
- :file:`_returners`
- :file:`_states`
- :file:`_tops`
- :file:`_utils`
The contents of these directories need to be synced over to the minions after

3
doc/ref/file_server/file_roots.rst
View File

@ -25,6 +25,7 @@ environments are not isolated from each other. This allows for logical
isolation of environments by the engineer using Salt, but also allows
for information to be used in multiple environments.
.. _file-roots-directory-overlay:
Directory Overlay
=================
@ -81,4 +82,4 @@ enable running Salt states without a Salt master. To use the local file server
interface, copy the file server data to the minion and set the file_roots
option on the minion to point to the directories copied from the master.
Once the minion ``file_roots`` option has been set, change the ``file_client``
option to local to make sure that the local file server interface is used.
option to local to make sure that the local file server interface is used.

1
doc/ref/index.rst
View File

@ -12,6 +12,7 @@ This section contains a list of the Python modules that are used to extend the v
../ref/beacons/all/index
../ref/cache/all/index
../ref/engines/all/index
../ref/executors/all/index
../ref/file_server/all/index
../ref/grains/all/index
../ref/modules/all/index

131
doc/ref/internals/fileserver-and-client.rst Normal file
View File

@ -0,0 +1,131 @@
.. _internals-fileserver-client:
The Salt Fileserver and Client
==============================
Introduction
------------
Salt has a modular fileserver, and mulitple client classes which are used to
interact with it. This page serves as a developer's reference, to help explain
how the fileserver and clients both work.
Fileserver
----------
The fileserver is not a daemon, so the fileserver and client are not a true
server and client in the traditional sense. Instead, the fileserver is simply a
class (``salt.fileserver.Fileserver``), located in
`salt/fileserver/__init__.py`_. This class has access to the configured
fileserver backends via a loader instance, referenced as ``self.servers``. When
a request comes in from the fileclient, it will ultimately result in a
``Fileserver`` class function being run.
The functions in this class will run corresponding functions in the configured
fileserver backends to perform the requested action. So, in summary:
1. A fileclient class makes a request...
2. which triggers the fileserver to run a function...
3. which runs a named function in each of the configured backends.
Not all of the functions will always execute on every configured backend. For
instance, the ``find_file`` function in the fileserver will stop when it finds
a match, so if it finds a match for the desired path in the first configured
backend, it won't proceed and try to find the file in the next backend in the
list.
Additionally, not all backends implement all functions in the
``salt.fileserver.Fileserver`` class. For instance, there is a function called
``update``, which exists to update remote fileservers such as the ``git``,
``hg``, and ``svn`` backends. This action has no use however in the ``roots``
backend, so it is simply not implemented there, and thus the ``roots`` backend
will be skipped if the ``update`` function is run on the fileserver.
Backends for the fileserver are located in `salt/fileserver/`_ (the files not
named ``__init__.py``).
.. _`salt/fileserver/__init__.py`: https://github.com/saltstack/salt/tree/develop/salt/fileserver/__init__.py
.. _`salt/fileserver/`: https://github.com/saltstack/salt/tree/develop/salt/fileserver
Fileclient
----------
There are three fileclient classes:
salt.fileclient.RemoteClient
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This client is used when :conf_minion:`file_client` is set to ``remote``. This
is how minions request files from the master.
Functions in this client will craft a payload and send it to the master via the
transport channel. This is the same way that the minion asks the minion to do
other things, such as updating and requesting data from the mine. The payload
will be a dictionary with a key called ``cmd``, and other values as needed.
Payloads sent via the transport channel are processed my an MWorker instance on
the master, and the MWorker's ``_handle_aes()`` function will execute the
command. The command will be a function attribute of the
``salt.master.AESFuncs`` class. The AESFuncs class' ``__setup_fileserver()``
function instantiates a ``salt.fileserver.Fileserver`` instance and maps its
member functions to AESFuncs attributes. This is what makes the fileserver
functions available remotely. The result of the function is returned back
through the transport channel to the minion.
Transporting files is done in chunks, the size of which is decided by the
``file_buffer_size`` config option. If you look at the ``serve_file()``
function in any of the fileserver backends, you can see how the ``loc`` value
in the payload determines the offset so that an intermediate chunk of the file
can be served. The RemoteClient's ``get_file()`` function will loop until the
end of the file is reached, retrieving one chunk at a time.
salt.fileclient.FSClient
~~~~~~~~~~~~~~~~~~~~~~~~
This client is used when :conf_minion:`file_client` is set to ``local``. This
is how masterless minions request files.
This class inherits from the RemoteClient, but instead of using a transport
channel (zmq, tcp, etc.), it uses a "fake" transport channel
(``salt.fileserver.FSChan``), which implements its own ``send()`` function.
Thus, when a function that the FSClient inherits from the RemoteClient runs
``self.channel.send()``, it's actually calling
``salt.fileserver.FSChan.send()``, which calls corresponding functions in the
``salt.fileserver.Fileserver()`` class. The result is that local file requests
use the same code as remote file requests, they just bypass sending them
through an actual transport channel and instead call them on the FSChan's
Fileserver instance.
salt.fileclient.LocalClient
~~~~~~~~~~~~~~~~~~~~~~~~~~~
This client is now used exclusively by Pillar. This used to be used when
:conf_minion:`file_client` was set to ``local``, but the ``FSChan`` class was
written to allow minions with ``file_client: local`` to access the full set of
backends. This class will probably be renamed at some point as it is often
confused with ``salt.client.LocalClient``.
The :mod:`cp <salt.modules.cp>` Module
--------------------------------------
Most of the user-facing interaction with the fileclient happens via the
:mod:`cp <salt.modules.cp>` module. The functions in this module instantiate a
fileclient instance (if one is not already saved to the ``__context__``
dunder) and run fileclient functions.
Updating the Fileserver
-----------------------
The master daemon spawns a process dedicated to routine maintenance tasks upon
startup. This process runs an instance of ``salt.master.Maintenance``, which
loops forever, running a series of functions and then sleeping for a length of
time determined by the :conf_master:`loop_interval` config option. One of the
maintenance tasks is to update the fileserver, and it essentially runs
``salt.fileserver.Fileserver.update()``, which as we know from above will run
all configured backends' ``update()`` functions, if present. This is now remote
fileservers like ``git``, ``hg``, and ``svn`` stay up-to-date.
For the local file_client (FSClient), since it does not interact with the
master, upon spawning of its FSChan it will update the fileserver.

65
doc/ref/modules/all/index.rst
View File

@ -1,4 +1,4 @@
.. _all-salt_modules:
.. _all-salt.modules:
=================
execution modules
@ -8,7 +8,9 @@ execution modules
.. toctree::
salt.modules.group
salt.modules.pkg
salt.modules.user
.. currentmodule:: salt.modules
@ -17,11 +19,13 @@ execution modules
:template: autosummary.rst.tmpl
acme
aix_group
aliases
alternatives
apache
apcups
apf
apk
aptpkg
archive
artifactory
@ -33,26 +37,32 @@ execution modules
bcache
beacons
bigip
blockdev
bluez
boto3_elasticache
boto3_route53
boto_apigateway
boto_asg
boto_cfn
boto_cloudtrail
boto_cloudwatch
boto_cloudwatch_event
boto_cognitoidentity
boto_datapipeline
boto_dynamodb
boto_ec2
boto_efs
boto_elasticache
boto_elasticsearch_domain
boto_elb
boto_elbv2
boto_iam
boto_iot
boto_kinesis
boto_kms
boto_lambda
boto_rds
boto_route53
boto_s3_bucket
boto_secgroup
boto_sns
boto_sqs
@ -62,12 +72,16 @@ execution modules
bsd_shadow
btrfs
cabal
capirca_acl
cassandra
cassandra_cql
celery
ceph
chassis
chef
chocolatey
chronos
cisconso
cloud
cmdmod
composer
@ -97,8 +111,7 @@ execution modules
dnsmasq
dnsutil
dockercompose
dockerio
dockerng
dockermod
dpkg
drac
dracr
@ -116,6 +129,7 @@ execution modules
file
firewalld
freebsd_sysctl
freebsd_update
freebsdjail
freebsdkmod
freebsdpkg
@ -131,14 +145,15 @@ execution modules
glusterfs
gnomedesktop
gpg
grafana4
grains
group
groupadd
grub_legacy
guestfs
hadoop
haproxyconn
hashutil
heat
hg
hipchat
hosts
@ -146,16 +161,21 @@ execution modules
http
ifttt
ilo
img
icinga2
incron
influx
influx08
infoblox
ini_manage
inspectlib
inspectlib.collector
inspectlib.dbhandle
inspectlib.entities
inspectlib.exceptions
inspectlib.fsdb
inspectlib.kiwiproc
inspectlib.query
inspector
introspect
ipmi
ipset
@ -176,6 +196,10 @@ execution modules
layman
ldap3
ldapmod
libcloud_compute
libcloud_dns
libcloud_loadbalancer
libcloud_storage
linux_acl
linux_ip
linux_lvm
@ -183,6 +207,7 @@ execution modules
localemod
locate
logadm
logmod
logrotate
lvs
lxc
@ -199,7 +224,6 @@ execution modules
mac_service
mac_shadow
mac_softwareupdate
mac_user
mac_sysctl
mac_system
mac_timezone
@ -208,6 +232,7 @@ execution modules
makeconf
marathon
match
mattermost
mdadm
mdata
memcached
@ -220,11 +245,19 @@ execution modules
moosefs
mount
mssql
msteams
munin
mysql
nacl
nagios
nagios_rpc
namecheap_dns
namecheap_domains
namecheap_ns
namecheap_ssl
namecheap_users
napalm
napalm_acl
napalm_bgp
napalm_network
napalm_ntp
@ -232,6 +265,7 @@ execution modules
napalm_route
napalm_snmp
napalm_users
napalm_yang_mod
netaddress
netbsd_sysctl
netbsdservice
@ -241,6 +275,8 @@ execution modules
nfs3
nftables
nginx
nilrt_ip
nix
nova
npm
nspawn
@ -250,7 +286,9 @@ execution modules
openbsdpkg
openbsdrcctl
openbsdservice
openscap
openstack_config
openstack_mng
openvswitch
opkg
oracle
@ -298,6 +336,7 @@ execution modules
redismod
reg
rest_package
rest_sample_utils
rest_service
restartcheck
ret
@ -323,6 +362,7 @@ execution modules
sensors
serverdensity_device
service
servicenow
shadow
slack_notify
slsutil
@ -341,6 +381,7 @@ execution modules
solarisips
solarispkg
solr
solrcloud
splunk
splunk_search
sqlite3
@ -367,6 +408,7 @@ execution modules
telemetry
temp
test
testinframod
test_virtual
timezone
tls
@ -378,10 +420,10 @@ execution modules
udev
upstart
uptime
user
useradd
uwsgi
varnish
vault
vbox_guest
vboxmanage
victorops
@ -400,16 +442,21 @@ execution modules
win_groupadd
win_iis
win_ip
win_lgpo
win_license
win_network
win_ntp
win_path
win_pkg
win_pki
win_powercfg
win_psget
win_repo
win_servermanager
win_service
win_shadow
win_smtp_server
win_snmp
win_status
win_system
win_task
@ -419,7 +466,7 @@ execution modules
win_wua
x509
xapi
xbps-pkg
xbpspkg
xfs
xmpp
yumpkg

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

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

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

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

6
doc/ref/modules/all/salt.modules.blockdev.rst
View File

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

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

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

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

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

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

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

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

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

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

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

5
doc/ref/modules/all/salt.modules.capirca_acl.rst Normal file
View File

@ -0,0 +1,5 @@
salt.modules.capirca_acl module
===============================
.. automodule:: salt.modules.capirca_acl
:members:

1
doc/ref/modules/all/salt.modules.cytest.rst
View File

@ -3,4 +3,3 @@ salt.modules.cytest module
.. automodule:: salt.modules.cytest
:members:

6
doc/ref/modules/all/salt.modules.dockerio.rst
View File

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

7
doc/ref/modules/all/salt.modules.dockermod.rst Normal file
View File

@ -0,0 +1,7 @@
======================
salt.modules.dockermod
======================
.. automodule:: salt.modules.dockermod
:members:
:exclude-members: cp, freeze, unfreeze

7
doc/ref/modules/all/salt.modules.dockerng.rst
View File

@ -1,7 +0,0 @@
=====================
salt.modules.dockerng
=====================
.. automodule:: salt.modules.dockerng
:members:
:exclude-members: cp, freeze, unfreeze

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

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

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

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

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

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

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

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

7
doc/ref/modules/all/salt.modules.img.rst
View File

@ -1,7 +0,0 @@
================
salt.modules.img
================
.. automodule:: salt.modules.img
:members:
:exclude-members: mnt_image

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

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

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

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

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

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

5
doc/ref/modules/all/salt.modules.logmod.rst Normal file
View File

@ -0,0 +1,5 @@
salt.modules.logmod module
==========================
.. automodule:: salt.modules.logmod
:members:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7
doc/ref/modules/all/salt.modules.napalm.rst Normal file
View File

@ -0,0 +1,7 @@
==========================
salt.modules.napalm module
==========================
.. automodule:: salt.modules.napalm
:members:

7
doc/ref/modules/all/salt.modules.napalm_acl.rst Normal file
View File

@ -0,0 +1,7 @@
==============================
salt.modules.napalm_acl module
==============================
.. automodule:: salt.modules.napalm_acl
:members:

5
doc/ref/modules/all/salt.modules.napalm_yang_mod.rst Normal file
View File

@ -0,0 +1,5 @@
salt.modules.napalm_yang_mod module
===================================
.. automodule:: salt.modules.napalm_yang_mod
:members:

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

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

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

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

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

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

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

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

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

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

5
doc/ref/modules/all/salt.modules.xbps-pkg.rst
View File

@ -1,5 +0,0 @@
salt.modules.xbps-pkg module
============================
.. automodule:: salt.modules.xbps-pkg
:members:

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

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

8
doc/ref/netapi/all/salt.netapi.rest_cherrypy.rst
View File

@ -2,6 +2,9 @@
rest_cherrypy
=============
.. contents::
:local:
.. automodule:: salt.netapi.rest_cherrypy.app
.. automodule:: salt.netapi.rest_cherrypy.wsgi
@ -11,9 +14,6 @@ REST URI Reference
.. py:currentmodule:: salt.netapi.rest_cherrypy.app
.. contents::
:local:
``/``
-----
@ -78,4 +78,4 @@ REST URI Reference
----------
.. autoclass:: Stats
:members: GET
:members: GET

1
doc/ref/output/all/index.rst
View File

@ -20,6 +20,7 @@ Follow one of the below links for further information and examples
no_out
no_return
overstatestage
pony
pprint_out
progress
raw

8
doc/ref/pillar/all/index.rst
View File

@ -16,22 +16,27 @@ pillar modules
cobbler
confidant
consul_pillar
csvpillar
django_orm
ec2_pillar
etcd_pillar
file_tree
foreman
git_pillar
gpg
hg_pillar
hiera
http_json
http_yaml
libvirt
makostack
mongo
mysql
neutron
nodegroups
pepa
pillar_ldap
postgres
puppet
reclass_adapter
redismod
@ -43,4 +48,7 @@ pillar modules
svn_pillar
varstack_pillar
vault
venafi
virtkey
vmware_pillar

6
doc/ref/pillar/all/salt.pillar.gpg.rst Normal file
View File

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

6
doc/ref/pillar/all/salt.pillar.postgres.rst Normal file
View File

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

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