Salt系統(tǒng)非常簡(jiǎn)單并且易于配置，Salt系統(tǒng)的兩個(gè)組件都有各自的配置文件。如"salt-master"是通過(guò)主配置文件來(lái)配置的,"salt-minion"是通過(guò)子節(jié)點(diǎn)配置文件來(lái)配置的。

參見(jiàn)

參考:`Master 配置文件的例子 <configuration-examples-master>`

The configuration file for the salt-master is located at?/etc/salt/master?by default. A notable exception is FreeBSD, where the configuration file is located at?/usr/local/etc/salt. The available options are as follows:

MASTER的主要配置

網(wǎng)絡(luò)接口

默認(rèn):?0.0.0.0?(所有的網(wǎng)絡(luò)接口都可訪問(wèn))

綁定本地接口

interface: 192.168.0.1

IPV6

缺省:'False'

Whether the master should listen for IPv6 connections. If this is set to True, the interface option must be adjusted too (for example: "interface: '::'")

ipv6: True

提供服務(wù)的端口

默認(rèn):?4505

The network port to set up the publication interface.

publish_port: 4505

MASTER_ID

缺省:"None"

The id to be passed in the publish job to minions. This is used for MultiSyndics to return the job to the requesting master.

注解

This must be the same string as the syndic is configured with.

master_id: MasterOfMaster

“USER”

缺省:"root"

用戶運(yùn)行salt的過(guò)程

user: root

最大打開(kāi)文件數(shù)MAX_OPEN_FILES

Default:?100000

Each minion connecting to the master uses AT LEAST one file descriptor, the master subscription connection. If enough minions connect you might start seeing on the console(and then salt-master crashes):

Too many open files (tcp_listener.cpp:335) Aborted (core dumped) max_open_files: 100000

默認(rèn)值是`ulimit -Hn` 命令結(jié)果中的一個(gè)，比如，最大可打開(kāi)文件數(shù)的上限。

To set a different value than the default one, uncomment, and configure this setting. Remember that this value CANNOT be higher than the hard limit. Raising the hard limit depends on the OS and/or distribution, a good way to find the limit is to search the internet for something like this:

raise max open files hard limit debian

工作線程

默認(rèn):?5

接收命令和響應(yīng)minion的線程數(shù)量。如果因?yàn)閙inion太多引起響應(yīng)延遲的話，可提高工作線程worker_threads的值

使用對(duì)稱系統(tǒng)時(shí)工作線程數(shù)量不能小于3，其他情況可最小到1

注解

When the master daemon starts, it is expected behaviour to see multiple salt-master processes, even if 'worker_threads' is set to '1'. At a minimum, a controlling process will start along with a Publisher, an EventPublisher, and a number of MWorker processes will be started. The number of MWorker processes is tuneable by the 'worker_threads' configuration value while the others are not.

worker_threads: 5

返回端口

缺省:"4506"

返回服務(wù)器使用的端口，返回服務(wù)器是指Salt接收?qǐng)?zhí)行返回結(jié)果和命令執(zhí)行情況的服務(wù)器

ret_port: 4506

“PIDFILE”

默認(rèn):?/var/run/salt-master.pid

Specify the location of the master pidfile.

pidfile: /var/run/salt-master.pid

‘ROOT_DIR’

默認(rèn):?/

The system root directory to operate from, change this to make Salt run from an alternative root.

root_dir: /

注解

This directory is prepended to the following options:?pki_dir,?cachedir,?sock_dir,?log_file,?autosign_file,?autoreject_file,?pidfile.

"PKI_DIR"

缺省:?/etc/salt/pki

保存pki認(rèn)證密鑰的路徑

pki_dir: /etc/salt/pki

EXTENSION_MODULES

在 2016.3.0 版更改:?The default location for this directory has been moved. Prior to this version, the location was a directory named?extmods?in the Salt cachedir (on most platforms,?/var/cache/salt/extmods). It has been moved into the master cachedir (on most platforms,?/var/cache/salt/master/extmods).

Directory for custom modules. This directory can contain subdirectories for each of Salt's module types such as?runners,?output,?wheel,?modules,?states,?returners, etc. This path is appended to?root_dir.

extension_modules: /root/salt_extmods

MODULE_DIRS

缺省:'[]'

Like?extension_modules, but a list of extra directories to search for Salt modules.

module_dirs:- /var/cache/salt/minion/extmods

'CACHEDIR'

缺省:?/var/cache/salt

保存緩存信息的位置，特別是執(zhí)行salt命令的作業(yè)信息。

This directory may contain sensitive data and should be protected accordingly.

cachedir: /var/cache/salt

'VERIFY_ENV'

缺省:'True'

在啟動(dòng)的時(shí)候，驗(yàn)證和設(shè)置權(quán)限配置目錄。

verify_env: True

KEEP_JOBS

缺省:?24

Set the number of hours to keep old job information.

TIMEOUT

默認(rèn):?5

Set the default timeout for the salt command and api.

LOOP_INTERVAL

Default:?60

The loop_interval option controls the seconds for the master's maintenance process check cycle. This process updates file server backends, cleans the job cache and executes the scheduler.

OUTPUT

Default:?nested

Set the default outputter used by the salt command.

COLOR

缺省:'True'

By default output is colored, to disable colored output set the color value to False.

color: False

‘SOCK_DIR’

Default:?/var/run/salt/master

Set the location to use for creating Unix sockets for master process communication.

sock_dir: /var/run/salt/master

ENABLE_GPU_GRAINS

缺省:'True'

Enable GPU hardware data for your master. Be aware that the master can take a while to start up when lspci and/or dmidecode is used to populate the grains for the master.

作業(yè)緩存

缺省:'True'

The master maintains a job cache, while this is a great addition it can be a burden on the master for larger deployments (over 5000 minions). Disabling the job cache will make previously executed jobs unavailable to the jobs system and is not generally recommended. Normally it is wise to make sure the master has access to a faster IO system or a tmpfs is mounted to the jobs dir.

MINION數(shù)據(jù)緩存

缺省:'True'

The minion data cache is a cache of information about the minions stored on the master, this information is primarily the pillar and grains data. The data is cached in the Master cachedir under the name of the minion and used to predetermine what minions are expected to reply from executions.

minion_data_cache: True

擴(kuò)展作業(yè)緩存

Default:?''

Used to specify a default returner for all minions, when this option is set the specified returner needs to be properly configured and the minions will always default to sending returns to this returner. This will also disable the local job cache on the master.

ext_job_cache: redis

EVENT_RETURN

2015.5.0 新版功能.

Default:?''

Specify the returner to use to log events. A returner may have installation and configuration requirements. Read the returner's documentation.

注解

Not all returners support event returns. Verify that a returner has anevent_return()?function before configuring this option with a returner.

event_return: cassandra_cql

MASTER_JOB_CACHE

2014.7.0 新版功能.

Default: 'local_cache'

Specify the returner to use for the job cache. The job cache will only be interacted with from the salt master and therefore does not need to be accessible from the minions.

master_job_cache: redis

ENFORCE_MINE_CACHE

Default: False

By-default when disabling the minion_data_cache mine will stop working since it is based on cached data, by enabling this option we explicitly enabling only the cache for the mine system.

enforce_mine_cache: False

MAX_MINIONS

Default: 0

The maximum number of minion connections allowed by the master. Use this to accommodate the number of minions per master if you have different types of hardware serving your minions. The default of?0?means unlimited connections. Please note, that this can slow down the authentication process a bit in large setups.

max_minions: 100

CON_CACHE

Default: False

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 all connected minions to all MWorker-processes and greatly improves the performance of max_minions.

con_cache: True

PRESENCE_EVENTS

Default: False

Causes the master to periodically look for actively connected minions.?Presence events?are fired on the event bus on a regular interval with a list of connected minions, as well as events with lists of newly connected or disconnected minions. This is a master-only operation that does not send executions to minions. Note, this does not detect minions that connect to a master via localhost.

presence_events: False

TRANSPORT

Default:?zeromq

Changes the underlying transport layer. ZeroMQ is the recommended transport while additional transport layers are under development. Supported values arezeromq,?raet?(experimental), and?tcp?(experimental). This setting has a significant impact on performance and should not be changed unless you know what you are doing! Transports are explained in?Salt Transports.

transport: zeromq

SALT-SSH CONFIGURATION

ROSTER_FILE

Default:?/etc/salt/roster

Pass in an alternative location for the salt-ssh roster file.

roster_file: /root/roster

SSH_MINION_OPTS

Default: None

Pass in minion option overrides that will be inserted into the SHIM for salt-ssh calls. The local minion config is not used for salt-ssh. Can be overridden on a per-minion basis in the roster (minion_opts)

minion_opts:gpg_keydir: /root/gpg

MASTER SECURITY SETTINGS

OPEN_MODE

缺省:'False'

Open mode is a dangerous security feature. One problem encountered with pki authentication systems is that keys can become "mixed up" and authentication begins to fail. Open mode turns off authentication and tells the master to accept all authentication. This will clean up the pki keys received from the minions. Open mode should not be turned on for general use. Open mode should only be used for a short period of time to clean up pki keys. To turn on open mode set this value to?True.

open_mode: False

AUTO_ACCEPT

缺省:'False'

Enable auto_accept. This setting will automatically accept all incoming public keys from minions.

auto_accept: False

AUTOSIGN_TIMEOUT

2014.7.0 新版功能.

Default:?120

Time in minutes that a incoming public key with a matching name found in pki_dir/minion_autosign/keyid is automatically accepted. Expired autosign keys are removed when the master checks the minion_autosign directory. This method to auto accept minions can be safer than an autosign_file because the keyid record can expire and is limited to being an exact name match. This should still be considered a less than secure option, due to the fact that trust is based on just the requesting minion id.

AUTOSIGN_FILE

Default:?not?defined

If the?autosign_file?is specified incoming keys specified in the autosign_file will be automatically accepted. Matches will be searched for first by string comparison, then by globbing, then by full-string regex matching. This should still be considered a less than secure option, due to the fact that trust is based on just the requesting minion id.

AUTOREJECT_FILE

2014.1.0 新版功能.

Default:?not?defined

Works like?autosign_file, but instead allows you to specify minion IDs for which keys will automatically be rejected. Will override both membership in the?autosign_file?and the?auto_accept?setting.

PUBLISHER_ACL

Default:?{}

Enable user accounts on the master to execute specific modules. These modules can be expressed as regular expressions. Note that client_acl option is deprecated by publisher_acl option and will be removed in future releases.

publisher_acl:fred:- test.ping - pkg.*

PUBLISHER_ACL_BLACKLIST

Default:?{}

Blacklist users or modules

This example would blacklist all non sudo users, including root from running any commands. It would also blacklist any use of the "cmd" module. Note that client_acl_blacklist option is deprecated by publisher_acl_blacklist option and will be removed in future releases.

This is completely disabled by default.

publisher_acl_blacklist:users:- root - '^(?!sudo_).*$' # all non sudo users modules: - cmd

EXTERNAL_AUTH

Default:?{}

The external auth system uses the Salt auth modules to authenticate and validate users to access areas of the Salt system.

external_auth:pam:fred: - test.*

TOKEN_EXPIRE

Default:?43200

Time (in seconds) for a newly generated token to live.

Default: 12 hours

token_expire: 43200

FILE_RECV

缺省:'False'

Allow minions to push files to the master. This is disabled by default, for security purposes.

file_recv: False

MASTER_SIGN_PUBKEY

缺省:'False'

Sign the master auth-replies with a cryptographic signature of the masters public key. Please see the tutorial how to use these settings in the?Multimaster-PKI with Failover Tutorial

master_sign_pubkey: True

MASTER_SIGN_KEY_NAME

Default:?master_sign

The customizable name of the signing-key-pair without suffix.

master_sign_key_name: <filename_without_suffix>

MASTER_PUBKEY_SIGNATURE

Default:?master_pubkey_signature

The name of the file in the masters pki-directory that holds the pre-calculated signature of the masters public-key.

master_pubkey_signature: <filename>

MASTER_USE_PUBKEY_SIGNATURE

缺省:'False'

Instead of computing the signature for each auth-reply, use a pre-calculated signature. The?master_pubkey_signature?must also be set for this.

master_use_pubkey_signature: True

ROTATE_AES_KEY

缺省:'True'

Rotate the salt-masters AES-key when a minion-public is deleted with salt-key. This is a very important security-setting. Disabling it will enable deleted minions to still listen in on the messages published by the salt-master. Do not disable this unless it is absolutely clear what this does.

rotate_aes_key: True

MASTER MODULE MANAGEMENT

RUNNER_DIRS

缺省:'[]'

Set additional directories to search for runner modules.

CYTHON_ENABLE

缺省:'False'

Set to true to enable Cython modules (.pyx files) to be compiled on the fly on the Salt master.

cython_enable: False

MASTER STATE SYSTEM SETTINGS

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.

state_top: top.sls

MASTER_TOPS

Default:?{}

The master_tops option replaces the external_nodes option by creating a pluggable system for the generation of external top data. The external_nodes option is deprecated by the master_tops option. To gain the capabilities of the classic external_nodes system, use the following configuration:

master_tops:ext_nodes: <Shell command which returns yaml>

EXTERNAL_NODES

Default: None

The external_nodes option allows Salt to gather data that would normally be placed in a top file from and external node controller. The external_nodes option is the executable that will return the ENC data. Remember that Salt will look for external nodes AND top files and combine the results if both are enabled and available!

external_nodes: cobbler-ext-nodes

RENDERER

Default:?yaml_jinja

The renderer to use on the minions to render the state data.

renderer: yaml_jinja

FAILHARD

缺省:'False'

Set the global failhard flag, this informs all states to stop running states at the moment a single state fails.

failhard: False

STATE_VERBOSE

缺省:'True'

Controls the verbosity of state runs. By default, the results of all states are returned, but setting this value to?False?will cause salt to only display output for states which either failed, or succeeded without making any changes to the minion.

state_verbose: False

STATE_OUTPUT

Default:?full

The state_output setting changes if the output is the full multi line output for each changed state if set to 'full', but if set to 'terse' the output will be shortened to a single line. If set to 'mixed', the output will be terse unless a state failed, in which case that output will be full. If set to 'changes', the output will be full unless the state didn't change.

state_output: full

STATE_AGGREGATE

缺省:'False'

Automatically aggregate all states that have support for mod_aggregate by setting to?True. Or pass a list of state module names to automatically aggregate just those types.

state_aggregate:- pkg state_aggregate: True

STATE_EVENTS

缺省:'False'

Send progress events as each function in a state run completes execution by setting to?True. Progress events are in the formatsalt/job/<JID>/prog/<MID>/<RUN?NUM>.

state_events: True

YAML_UTF8

缺省:'False'

Enable extra routines for YAML renderer used states containing UTF characters.

yaml_utf8: False

TEST

缺省:'False'

Set all state calls to only test if they are going to actually make changes or just post what changes are going to be made.

test: False

MASTER FILE SERVER SETTINGS

FILESERVER_BACKEND

Default:?['roots']

Salt supports a modular fileserver backend system, this system allows the salt master to link directly to third party systems to gather and manage the files available to minions. Multiple backends can be configured and will be searched for the requested file in the order in which they are defined here. The default setting only enables the standard backend?roots, which is configured using the?file_roots?option.

范例:

fileserver_backend:- roots- git

HASH_TYPE

Default:?md5

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.

hash_type: md5

FILE_BUFFER_SIZE

Default:?1048576

The buffer size in the file server in bytes.

file_buffer_size: 1048576

FILE_IGNORE_REGEX

Default:?''

A regular expression (or a list of expressions) that will be matched against the file path before syncing the modules and states to the minions. This includes files affected by the file.recurse state. For example, if you manage your custom modules and states in subversion and don't want all the '.svn' folders and content synced to your minions, you could set this to '/.svn($|/)'. By default nothing is ignored.

file_ignore_regex:- '/\.svn($|/)'- '/\.git($|/)'

FILE_IGNORE_GLOB

Default?''

A file glob (or list of file globs) that will be matched against the file path before syncing the modules and states to the minions. This is similar to file_ignore_regex above, but works on globs instead of regex. By default nothing is ignored.

file_ignore_glob:- '\*.pyc'- '\*/somefolder/\*.bak' - '\*.swp'

注解

Vim's .swp files are a common cause of Unicode errors in?file.recurse?states which use templating. Unless there is a good reason to distribute them via the fileserver, it is good practice to include?'\*.swp'?in the?file_ignore_glob.

ROOTS: MASTER'S LOCAL FILE SERVER

FILE_ROOTS

Default:

base:- /srv/salt

Salt runs a lightweight file server written in ZeroMQ to deliver files to minions. This file server is built into the master daemon and does not require a dedicated port.

The file server works on environments passed to the master. Each environment can have multiple root directories. The subdirectories in the multiple file roots cannot match, otherwise the downloaded files will not be able to be reliably ensured. A base environment is required to house the top file.

范例:

file_roots:base:- /srv/salt dev: - /srv/salt/dev/services - /srv/salt/dev/states prod: - /srv/salt/prod/services - /srv/salt/prod/states

GIT: GIT REMOTE FILE SERVER BACKEND

GITFS_REMOTES

缺省:'[]'

When using the?git?fileserver backend at least one git remote needs to be defined. The user running the salt master will need read access to the repo.

The repos will be searched in order to find the file requested by a client and the first repo to have the file will return it. Branches and tags are translated into salt environments.

gitfs_remotes:- git://github.com/saltstack/salt-states.git- file:///var/git/saltmaster

注解

file://?repos will be treated as a remote and copied into the master's gitfs cache, so only the?local?refs for those repos will be exposed as fileserver environments.

As of 2014.7.0, it is possible to have per-repo versions of several of the gitfs configuration parameters. For more information, see the?GitFS Walkthrough.

GITFS_PROVIDER

2014.7.0 新版功能.

Optional parameter used to specify the provider to be used for gitfs. More information can be found in the?GitFS Walkthrough.

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.

gitfs_provider: dulwich

GITFS_SSL_VERIFY

缺省:'True'

Specifies whether or not to ignore SSL certificate errors when contacting the remote repository. You might want to set this to?False?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.

gitfs_ssl_verify: True

GITFS_MOUNTPOINT

2014.7.0 新版功能.

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?gitfs_root. It can also be configured on a per-remote basis, see?here?for more info.

gitfs_mountpoint: salt://foo/bar

注解

The?salt://?protocol designation can be left off (in other words,?foo/bar?and?salt://foo/bar?are equivalent). Assuming a file?baz.sh?in the root of a gitfs remote, and the above example mountpoint, this file would be served up via?salt://foo/bar/baz.sh.

GITFS_ROOT

Default:?''

Relative path to a subdirectory within the repository from which Salt should begin to serve files. This is useful when there are files in the repository that should not be available to the Salt fileserver. Can be used in conjunction with?gitfs_mountpoint. If used, then from Salt's perspective the directories above the one specified will be ignored and the relative path will (for the purposes of gitfs) be considered as the root of the repo.

gitfs_root: somefolder/otherfolder

在 2014.7.0 版更改:?Ability to specify gitfs roots on a per-remote basis was added. See?here?for more info.

GITFS_BASE

Default:?master

Defines which branch/tag should be used as the?base?environment.

gitfs_base: salt

在 2014.7.0 版更改:?Ability to specify the base on a per-remote basis was added. See?here?for more info.

GITFS_ENV_WHITELIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if the repos in?gitfs_remotes?contain many branches/tags. More information can be found in the?GitFS Walkthrough.

gitfs_env_whitelist:- base- v1.* - 'mybranch\d+'

GITFS_ENV_BLACKLIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if the repos in?gitfs_remotes?contain many branches/tags. More information can be found in the?GitFS Walkthrough.

gitfs_env_blacklist:- base- v1.* - 'mybranch\d+'

GITFS AUTHENTICATION OPTIONS

These parameters only currently apply to the pygit2 gitfs provider. Examples of how to use these can be found in the?GitFS Walkthrough.

GITFS_USER

2014.7.0 新版功能.

Default:?''

Along with?gitfs_password, is used to authenticate to HTTPS remotes.

gitfs_user: git

GITFS_PASSWORD

2014.7.0 新版功能.

Default:?''

Along with?gitfs_user, is used to authenticate to HTTPS remotes. This parameter is not required if the repository does not use authentication.

gitfs_password: mypassword

GITFS_INSECURE_AUTH

2014.7.0 新版功能.

缺省:'False'

By default, Salt will not authenticate to an HTTP (non-HTTPS) remote. This parameter enables authentication over HTTP.?Enable this at your own risk.

gitfs_insecure_auth: True

GITFS_PUBKEY

2014.7.0 新版功能.

Default:?''

Along with?gitfs_privkey?(and optionally?gitfs_passphrase), is used to authenticate to SSH remotes. This parameter (or its?per-remote counterpart) is required for SSH remotes.

gitfs_pubkey: /path/to/key.pub

GITFS_PRIVKEY

2014.7.0 新版功能.

Default:?''

Along with?gitfs_pubkey?(and optionally?gitfs_passphrase), is used to authenticate to SSH remotes. This parameter (or its?per-remote counterpart) is required for SSH remotes.

gitfs_privkey: /path/to/key

GITFS_PASSPHRASE

2014.7.0 新版功能.

Default:?''

This parameter is optional, required only when the SSH key being used to authenticate is protected by a passphrase.

gitfs_passphrase: mypassphrase

HG: MERCURIAL REMOTE FILE SERVER BACKEND

HGFS_REMOTES

0.17.0 新版功能.

缺省:'[]'

When using the?hg?fileserver backend at least one mercurial remote needs to be defined. The user running the salt master will need read access to the repo.

The repos will be searched in order to find the file requested by a client and the first repo to have the file will return it. Branches and/or bookmarks are translated into salt environments, as defined by the?hgfs_branch_methodparameter.

hgfs_remotes:- https://username@bitbucket.org/username/reponame

注解

As of 2014.7.0, it is possible to have per-repo versions of the?hgfs_root,?hgfs_mountpoint,?hgfs_base, and?hgfs_branch_method?parameters. For example:

hgfs_remotes:- https://username@bitbucket.org/username/repo1- base: saltstates - https://username@bitbucket.org/username/repo2: - root: salt - mountpoint: salt://foo/bar/baz - https://username@bitbucket.org/username/repo3: - root: salt/states - branch_method: mixed

HGFS_BRANCH_METHOD

0.17.0 新版功能.

Default:?branches

Defines the objects that will be used as fileserver environments.

• branches?- Only branches and tags will be used
• bookmarks?- Only bookmarks and tags will be used
• mixed?- Branches, bookmarks, and tags will be used

hgfs_branch_method: mixed

注解

Starting in version 2014.1.0, the value of the?hgfs_base?parameter defines which branch is used as the?base?environment, allowing for a?base?environment to be used with an?hgfs_branch_method?of?bookmarks.

Prior to this release, the?default?branch will be used as the?base?environment.

HGFS_MOUNTPOINT

2014.7.0 新版功能.

Default:?''

Specifies a path on the salt fileserver which will be prepended to all files served by hgfs. This option can be used in conjunction with?hgfs_root. It can also be configured on a per-remote basis, see?here?for more info.

hgfs_mountpoint: salt://foo/bar

注解

The?salt://?protocol designation can be left off (in other words,?foo/bar?and?salt://foo/bar?are equivalent). Assuming a file?baz.sh?in the root of an hgfs remote, this file would be served up via?salt://foo/bar/baz.sh.

HGFS_ROOT

0.17.0 新版功能.

Default:?''

Relative path to a subdirectory within the repository from which Salt should begin to serve files. This is useful when there are files in the repository that should not be available to the Salt fileserver. Can be used in conjunction with?hgfs_mountpoint. If used, then from Salt's perspective the directories above the one specified will be ignored and the relative path will (for the purposes of hgfs) be considered as the root of the repo.

hgfs_root: somefolder/otherfolder

在 2014.7.0 版更改:?Ability to specify hgfs roots on a per-remote basis was added. See?here?for more info.

HGFS_BASE

2014.1.0 新版功能.

Default:?default

Defines which branch should be used as the?base?environment. Change this ifhgfs_branch_method?is set to?bookmarks?to specify which bookmark should be used as the?base?environment.

hgfs_base: salt

HGFS_ENV_WHITELIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if your hgfs remotes contain many branches/bookmarks/tags. Full names, globs, and regular expressions are supported. If using a regular expression, the 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?hgfs_env_blacklist, then the subset of branches/bookmarks/tags which match the whitelist but do?not?match the blacklist will be exposed as fileserver environments.

hgfs_env_whitelist:- base- v1.* - 'mybranch\d+'

HGFS_ENV_BLACKLIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if your hgfs remotes contain many branches/bookmarks/tags. Full names, globs, and regular expressions are supported. If using a regular expression, the 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?hgfs_env_whitelist, then the subset of branches/bookmarks/tags which match the whitelist but do?not?match the blacklist will be exposed as fileserver environments.

hgfs_env_blacklist:- base- v1.* - 'mybranch\d+'

SVN: SUBVERSION REMOTE FILE SERVER BACKEND

SVNFS_REMOTES

0.17.0 新版功能.

缺省:'[]'

When using the?svn?fileserver backend at least one subversion remote needs to be defined. The user running the salt master will need read access to the repo.

The repos will be searched in order to find the file requested by a client and the first repo to have the file will return it. The trunk, branches, and tags become environments, with the trunk being the?base?environment.

svnfs_remotes:- svn://foo.com/svn/myproject

注解

As of 2014.7.0, it is possible to have per-repo versions of the following configuration parameters:

• svnfs_root
• svnfs_mountpoint
• svnfs_trunk
• svnfs_branches
• svnfs_tags

For example:

svnfs_remotes:- svn://foo.com/svn/project1- svn://foo.com/svn/project2: - root: salt - mountpoint: salt://foo/bar/baz - svn//foo.com/svn/project3: - root: salt/states - branches: branch - tags: tag

SVNFS_MOUNTPOINT

2014.7.0 新版功能.

Default:?''

Specifies a path on the salt fileserver which will be prepended to all files served by hgfs. This option can be used in conjunction with?svnfs_root. It can also be configured on a per-remote basis, see?here?for more info.

svnfs_mountpoint: salt://foo/bar

注解

The?salt://?protocol designation can be left off (in other words,?foo/bar?and?salt://foo/bar?are equivalent). Assuming a file?baz.sh?in the root of an svnfs remote, this file would be served up via?salt://foo/bar/baz.sh.

SVNFS_ROOT

0.17.0 新版功能.

Default:?''

Relative path to a subdirectory within the repository from which Salt should begin to serve files. This is useful when there are files in the repository that should not be available to the Salt fileserver. Can be used in conjunction with?svnfs_mountpoint. If used, then from Salt's perspective the directories above the one specified will be ignored and the relative path will (for the purposes of svnfs) be considered as the root of the repo.

svnfs_root: somefolder/otherfolder

在 2014.7.0 版更改:?Ability to specify svnfs roots on a per-remote basis was added. See?here?for more info.

SVNFS_TRUNK

2014.7.0 新版功能.

Default:?trunk

Path relative to the root of the repository where the trunk is located. Can also be configured on a per-remote basis, see?here?for more info.

svnfs_trunk: trunk

SVNFS_BRANCHES

2014.7.0 新版功能.

Default:?branches

Path relative to the root of the repository where the branches are located. Can also be configured on a per-remote basis, see?here?for more info.

svnfs_branches: branches

SVNFS_TAGS

2014.7.0 新版功能.

Default:?tags

Path relative to the root of the repository where the tags are located. Can also be configured on a per-remote basis, see?here?for more info.

svnfs_tags: tags

SVNFS_ENV_WHITELIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if your svnfs remotes contain many branches/tags. Full names, globs, and regular expressions are supported. If using a regular expression, the expression 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?svnfs_env_blacklist, then the subset of branches/tags which match the whitelist but do?not?match the blacklist will be exposed as fileserver environments.

svnfs_env_whitelist:- base- v1.* - 'mybranch\d+'

SVNFS_ENV_BLACKLIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if your svnfs remotes contain many branches/tags. Full names, globs, and regular expressions are supported. If using a regular expression, the 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?svnfs_env_whitelist, then the subset of branches/tags which match the whitelist but do?not?match the blacklist will be exposed as fileserver environments.

svnfs_env_blacklist:- base- v1.* - 'mybranch\d+'

MINION: MINIONFS REMOTE FILE SERVER BACKEND

MINIONFS_ENV

2014.7.0 新版功能.

Default:?base

Environment from which MinionFS files are made available.

minionfs_env: minionfs

MINIONFS_MOUNTPOINT

2014.7.0 新版功能.

Default:?''

Specifies a path on the salt fileserver from which minionfs files are served.

minionfs_mountpoint: salt://foo/bar

注解

The?salt://?protocol designation can be left off (in other words,?foo/bar?and?salt://foo/bar?are equivalent).

MINIONFS_WHITELIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which minions' pushed files are exposed via minionfs. If using a regular expression, the expression must match the entire minion ID.

If used, only the pushed files from minions which match one of the specified expressions will be exposed.

If used in conjunction with?minionfs_blacklist, then the subset of hosts which match the whitelist but do?not?match the blacklist will be exposed.

minionfs_whitelist:- base- v1.* - 'mybranch\d+'

MINIONFS_BLACKLIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which minions' pushed files are exposed via minionfs. If using a regular expression, the expression must match the entire minion ID.

If used, only the pushed files from minions which match one of the specified expressions will?not?be exposed.

If used in conjunction with?minionfs_whitelist, then the subset of hosts which match the whitelist but do?not?match the blacklist will be exposed.

minionfs_blacklist:- base- v1.* - 'mybranch\d+'

PILLAR CONFIGURATION

PILLAR_ROOTS

Default:

base:- /srv/pillar

Set the environments and directories used to hold pillar sls data. This configuration is the same as?file_roots:

pillar_roots:base:- /srv/pillar dev: - /srv/pillar/dev prod: - /srv/pillar/prod

EXT_PILLAR

The ext_pillar option allows for any number of external pillar interfaces to be called when populating pillar data. The configuration is based on ext_pillar functions. The available ext_pillar functions can be found herein:

https://github.com/saltstack/salt/blob/develop/salt/pillar

By default, the ext_pillar interface is not configured to run.

缺省:"None"

ext_pillar:- hiera: /etc/hiera.yaml - cmd_yaml: cat /etc/salt/yaml - reclass: inventory_base_uri: /etc/reclass

There are additional details at?Pillars

PILLAR_ROOTS_OVERRIDE_EXT_PILLAR

Boron 新版功能.

缺省:'False'

This option allows for external pillar sources to be evaluated beforepillar_roots, which means that values obtained from?pillar_roots?take precedence over those found from?ext_pillar?sources.

pillar_roots_override_ext_pillar: False

EXT_PILLAR_FIRST

2015.5.0 新版功能.

缺省:'False'

This option allows for external pillar sources to be evaluated beforepillar_roots. This allows for targeting file system pillar from ext_pillar. Note that ext_pillar_first option is deprecated by pillar_roots_override_ext_pillar option and will be removed in future releases.

ext_pillar_first: False

GIT EXTERNAL PILLAR (GIT_PILLAR) CONFIGURATION OPTIONS

GIT_PILLAR_PROVIDER

2015.8.0 新版功能.

Specify the provider to be used for git_pillar. Must be either?pygit2?orgitpython. If unset, then both will be tried in that same order, and the first one with a compatible version installed will be the provider that is used.

git_pillar_provider: gitpython

GIT_PILLAR_BASE

2015.8.0 新版功能.

Default:?master

If the desired branch matches this value, and the environment is omitted from the git_pillar configuration, then the environment for that git_pillar remote will be?base. For example, in the configuration below, the?foo?branch/tag would be assigned to the?base?environment, while?bar?would be mapped to the?barenvironment.

git_pillar_base: fooext_pillar:- git: - foo https://mygitserver/git-pillar.git - bar https://mygitserver/git-pillar.git

GIT_PILLAR_BRANCH

2015.8.0 新版功能.

Default:?master

If the branch is omitted from a git_pillar remote, then this branch will be used instead. For example, in the configuration below, the first two remotes would use the?pillardata?branch/tag, while the third would use the?foo?branch/tag.

git_pillar_branch: pillardataext_pillar:- git: - https://mygitserver/pillar1.git - https://mygitserver/pillar2.git: - root: pillar - foo https://mygitserver/pillar3.git

GIT_PILLAR_ENV

2015.8.0 新版功能.

Default:?''?(unset)

Environment to use for git_pillar remotes. This is normally derived from the branch/tag (or from a per-remote?env?parameter), but if set this will override the process of deriving the env from the branch/tag name. For example, in the configuration below the?foo?branch would be assigned to the?baseenvironment, while the?bar?branch would need to explicitly have?barconfigured as it's environment to keep it from also being mapped to the?baseenvironment.

git_pillar_env: baseext_pillar:- git: - foo https://mygitserver/git-pillar.git - bar https://mygitserver/git-pillar.git: - env: bar

For this reason, this option is recommended to be left unset, unless the use case calls for all (or almost all) of the git_pillar remotes to use the same environment irrespective of the branch/tag being used.

GIT_PILLAR_ROOT

2015.8.0 新版功能.

Default:?''

Path relative to the root of the repository where the git_pillar top file and SLS files are located. In the below configuration, the pillar top file and SLS files would be looked for in a subdirectory called?pillar.

git_pillar_root: pillarext_pillar:- git: - master https://mygitserver/pillar1.git - master https://mygitserver/pillar2.git

注解

This is a global option. If only one or two repos need to have their files sourced from a subdirectory, then?git_pillar_root?can be omitted and the root can be specified on a per-remote basis, like so:

ext_pillar:- git:- master https://mygitserver/pillar1.git - master https://mygitserver/pillar2.git: - root: pillar

In this example, for the first remote the top file and SLS files would be looked for in the root of the repository, while in the second remote the pillar data would be retrieved from the?pillar?subdirectory.

GIT_PILLAR_SSL_VERIFY

2015.8.0 新版功能.

缺省:'True'

Specifies whether or not to ignore SSL certificate errors when contacting the remote repository. You might want to set this to?False?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.

git_pillar_ssl_verify: True

GIT EXTERNAL PILLAR AUTHENTICATION OPTIONS

These parameters only currently apply to the?pygit2?git_pillar_provider. Authentication works the same as it does in gitfs, as outlined in the?GitFS Walkthrough, though the global configuration options are named differently to reflect that they are for git_pillar instead of gitfs.

GIT_PILLAR_USER

2015.8.0 新版功能.

Default:?''

Along with?git_pillar_password, is used to authenticate to HTTPS remotes.

git_pillar_user: git

GIT_PILLAR_PASSWORD

2015.8.0 新版功能.

Default:?''

Along with?git_pillar_user, is used to authenticate to HTTPS remotes. This parameter is not required if the repository does not use authentication.

git_pillar_password: mypassword

GIT_PILLAR_INSECURE_AUTH

2015.8.0 新版功能.

缺省:'False'

By default, Salt will not authenticate to an HTTP (non-HTTPS) remote. This parameter enables authentication over HTTP.?Enable this at your own risk.

git_pillar_insecure_auth: True

GIT_PILLAR_PUBKEY

2015.8.0 新版功能.

Default:?''

Along with?git_pillar_privkey?(and optionally?git_pillar_passphrase), is used to authenticate to SSH remotes.

git_pillar_pubkey: /path/to/key.pub

GIT_PILLAR_PRIVKEY

2015.8.0 新版功能.

Default:?''

Along with?git_pillar_pubkey?(and optionally?git_pillar_passphrase), is used to authenticate to SSH remotes.

git_pillar_privkey: /path/to/key

GIT_PILLAR_PASSPHRASE

2015.8.0 新版功能.

Default:?''

This parameter is optional, required only when the SSH key being used to authenticate is protected by a passphrase.

git_pillar_passphrase: mypassphrase

PILLAR_SOURCE_MERGING_STRATEGY

2014.7.0 新版功能.

Default:?smart

The pillar_source_merging_strategy option allows you to configure merging strategy between different sources. It accepts 4 values:

• recurse:

  it will merge recursively mapping of data. For example, theses 2 sources:

  foo: 42 bar:element1: True bar:element2: True baz: quux

  will be merged as:

  foo: 42 bar:element1: True element2: True baz: quux

• aggregate:

  instructs aggregation of elements between sources that use the #!yamlex renderer.

  For example, these two documents:

  #!yamlex foo: 42 bar: !aggregate { element1: True } baz: !aggregate quux #!yamlex bar: !aggregate {element2: True } baz: !aggregate quux2

  will be merged as:

  foo: 42 bar:element1: True element2: True baz: - quux - quux2

• overwrite:

  Will use the behaviour of the 2014.1 branch and earlier.

  Overwrites elements according the order in which they are processed.

  First pillar processed:

  A:first_key: blahsecond_key: blah

  Second pillar processed:

  A:third_key: blahfourth_key: blah

  will be merged as:

  A:third_key: blahfourth_key: blah

• smart (default):

  Guesses the best strategy based on the "renderer" setting.

PILLAR_MERGE_LISTS

2015.8.0 新版功能.

缺省:'False'

Recursively merge lists by aggregating them instead of replacing them.

pillar_merge_lists: False

SYNDIC SERVER SETTINGS

A Salt syndic is a Salt master used to pass commands from a higher Salt master to minions below the syndic. Using the syndic is simple. If this is a master that will have syndic servers(s) below it, set the "order_masters" setting to True.

If this is a master that will be running a syndic daemon for passthrough the "syndic_master" setting needs to be set to the location of the master server.

Do not not forget that, in other words, it means that it shares with the local minion its ID and PKI_DIR.

ORDER_MASTERS

缺省:'False'

Extra data needs to be sent with publications if the master is controlling a lower level master via a syndic minion. If this is the case the order_masters value must be set to True

order_masters: False

SYNDIC_MASTER

缺省:"None"

If this master will be running a salt-syndic to connect to a higher level master, specify the higher level master with this configuration value.

syndic_master: masterofmasters

You can optionally connect a syndic to multiple higher level masters by setting the 'syndic_master' value to a list:

syndic_master:- masterofmasters1- masterofmasters2

Each higher level master must be set up in a multimaster configuration.

SYNDIC_MASTER_PORT

缺省:"4506"

If this master will be running a salt-syndic to connect to a higher level master, specify the higher level master port with this configuration value.

syndic_master_port: 4506

SYNDIC_PIDFILE

Default:?salt-syndic.pid

If this master will be running a salt-syndic to connect to a higher level master, specify the pidfile of the syndic daemon.

syndic_pidfile: syndic.pid

SYNDIC_LOG_FILE

Default:?syndic.log

If this master will be running a salt-syndic to connect to a higher level master, specify the log_file of the syndic daemon.

syndic_log_file: salt-syndic.log

PEER PUBLISH SETTINGS

Salt minions can send commands to other minions, but only if the minion is allowed to. By default "Peer Publication" is disabled, and when enabled it is enabled for specific minions and specific commands. This allows secure compartmentalization of commands based on individual minions.

PEER

Default:?{}

The configuration uses regular expressions to match minions and then a list of regular expressions to match functions. The following will allow the minion authenticated as foo.example.com to execute functions from the test and pkg modules.

peer:foo.example.com:- test.* - pkg.*

This will allow all minions to execute all commands:

peer:.*:- .*

This is not recommended, since it would allow anyone who gets root on any single minion to instantly have root on all of the minions!

By adding an additional layer you can limit the target hosts in addition to the accessible commands:

peer:foo.example.com:'db*': - test.* - pkg.*

PEER_RUN

Default:?{}

The peer_run option is used to open up runners on the master to access from the minions. The peer_run configuration matches the format of the peer configuration.

The following example would allow foo.example.com to execute the manage.up runner:

peer_run:foo.example.com:- manage.up

MASTER LOGGING SETTINGS

LOG_FILE

Default:?/var/log/salt/master

The master log can be sent to a regular file, local path name, or network location. See also?log_file.

Examples:

log_file: /var/log/salt/master log_file: file:///dev/log log_file: udp://loghost:10514

LOG_LEVEL

Default:?warning

The level of messages to send to the console. See also?log_level.

log_level: warning

LOG_LEVEL_LOGFILE

Default:?warning

The level of messages to send to the log file. See also?log_level_logfile. When it is not set explicitly it will inherit the level set by?log_level?option.

log_level_logfile: warning

LOG_DATEFMT

Default:?%H:%M:%S

The date and time format used in console log messages. See also?log_datefmt.

log_datefmt: '%H:%M:%S'

LOG_DATEFMT_LOGFILE

Default:?%Y-%m-%d?%H:%M:%S

The date and time format used in log file messages. See alsolog_datefmt_logfile.

log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'

LOG_FMT_CONSOLE

Default:?[%(levelname)-8s]?%(message)s

The format of the console logging messages. See also?log_fmt_console.

注解

Log colors are enabled in?log_fmt_console?rather than the?color?config since the logging system is loaded before the master config.

Console log colors are specified by these additional formatters:

%(colorlevel)s %(colorname)s %(colorprocess)s %(colormsg)s

Since it is desirable to include the surrounding brackets, '[' and ']', in the coloring of the messages, these color formatters also include padding as well. Color LogRecord attributes are only available for console logging.

log_fmt_console: '%(colorlevel)s %(colormsg)s' log_fmt_console: '[%(levelname)-8s] %(message)s'

LOG_FMT_LOGFILE

Default:?%(asctime)s,%(msecs)03.0f?[%(name)-17s][%(levelname)-8s]?%(message)s

The format of the log file logging messages. See also?log_fmt_logfile.

log_fmt_logfile: '%(asctime)s,%(msecs)03.0f [%(name)-17s][%(levelname)-8s] %(message)s'

LOG_GRANULAR_LEVELS

Default:?{}

This can be used to control logging levels more specifically. See alsolog_granular_levels.

NODE GROUPS

Default:?{}

Node groups allow for logical groupings of minion nodes. A group consists of a group name and a compound target.

nodegroups:group1: 'L@foo.domain.com,bar.domain.com,baz.domain.com or bl*.domain.com' group2: 'G@os:Debian and foo.domain.com' group3: 'G@os:Debian and N@group1' group4: - 'G@foo:bar' - 'or' - 'G@foo:baz'

More information on using nodegroups can be found?here.

RANGE CLUSTER SETTINGS

RANGE_SERVER

Default:?''

The range server (and optional port) that serves your cluster informationhttps://github.com/ytoolshed/range/wiki/%22yamlfile%22-module-file-spec

range_server: range:80

INCLUDE CONFIGURATION

DEFAULT_INCLUDE

Default:?master.d/*.conf

The master can include configuration from other files. Per default the master will automatically include all config files from?master.d/*.conf?where?master.dis relative to the directory of the master configuration file.

INCLUDE

Default:?not?defined

The master can include configuration from other files. To enable this, pass a list of paths to this option. The paths can be either relative or absolute; if relative, they are considered to be relative to the directory the main minion configuration file lives in. Paths can make use of shell-style globbing. If no files are matched by a path passed to this option then the master will log a warning message.

# Include files from a master.d directory in the same # directory as the master config file include: master.d/*# Include a single extra file into the configuration include: /etc/roles/webserver # Include several files and the master.d directory include: - extra_config - master.d/* - /etc/roles/webserver

WINDOWS SOFTWARE REPO SETTINGS

WINREPO_PROVIDER

2015.8.0 新版功能.

Specify the provider to be used for winrepo. Must be either?pygit2?orgitpython. If unset, then both will be tried in that same order, and the first one with a compatible version installed will be the provider that is used.

winrepo_provider: gitpython

WINREPO_DIR

在 2015.8.0 版更改:?Renamed from?win_repo?to?winrepo_dir.

Default:?/srv/salt/win/repo

Location on the master where the?winrepo_remotes?are checked out for pre-2015.8.0 minions. 2015.8.0 and later minions use?winrepo_remotes_ng?instead.

winrepo_dir: /srv/salt/win/repo

WINREPO_DIR_NG

2015.8.0 新版功能:?A new?ng?repo was added.

Default:?/srv/salt/win/repo-ng

Location on the master where the?winrepo_remotes_ng?are checked out for 2015.8.0 and later minions.

winrepo_dir_ng: /srv/salt/win/repo-ng

WINREPO_CACHEFILE

在 2015.8.0 版更改:?Renamed from?win_repo_mastercachefile?to?winrepo_cachefile

注解

2015.8.0 and later minions do not use this setting since the cachefile is now located on the minion.

Default:?winrepo.p

Path relative to?winrepo_dir?where the winrepo cache should be created.

winrepo_cachefile: winrepo.p

WINREPO_REMOTES

在 2015.8.0 版更改:?Renamed from?win_gitrepos?to?winrepo_remotes.

Default:?['https://github.com/saltstack/salt-winrepo.git']

List of git repositories to checkout and include in the winrepo for pre-2015.8.0 minions. 2015.8.0 and later minions use?winrepo_remotes_ng?instead.

winrepo_remotes:- https://github.com/saltstack/salt-winrepo.git

To specify a specific revision of the repository, prepend a commit ID to the URL of the repository:

winrepo_remotes:- '<commit_id> https://github.com/saltstack/salt-winrepo.git'

Replace?<commit_id>?with the SHA1 hash of a commit ID. Specifying a commit ID is useful in that it allows one to revert back to a previous version in the event that an error is introduced in the latest revision of the repo.

WINREPO_REMOTES_NG

2015.8.0 新版功能:?A new?ng?repo was added.

Default:?['https://github.com/saltstack/salt-winrepo-ng.git']

List of git repositories to checkout and include in the winrepo for 2015.8.0 and later minions.

winrepo_remotes_ng:- https://github.com/saltstack/salt-winrepo-ng.git

To specify a specific revision of the repository, prepend a commit ID to the URL of the repository:

winrepo_remotes:- '<commit_id> https://github.com/saltstack/salt-winrepo-ng.git'

Replace?<commit_id>?with the SHA1 hash of a commit ID. Specifying a commit ID is useful in that it allows one to revert back to a previous version in the event that an error is introduced in the latest revision of the repo.

WINREPO_BRANCH

2015.8.0 新版功能.

Default:?master

If the branch is omitted from a winrepo remote, then this branch will be used instead. For example, in the configuration below, the first two remotes would use the?winrepo?branch/tag, while the third would use the?foo?branch/tag.

winrepo_branch: winrepoext_pillar:- git: - https://mygitserver/winrepo1.git - https://mygitserver/winrepo2.git: - foo https://mygitserver/winrepo3.git

WINREPO_SSL_VERIFY

2015.8.0 新版功能.

缺省:'True'

Specifies whether or not to ignore SSL certificate errors when contacting the remote repository. You might want to set this to?False?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.

winrepo_ssl_verify: True

WINREPO AUTHENTICATION OPTIONS

These parameters only currently apply to the?pygit2?winrepo_provider. Authentication works the same as it does in gitfs, as outlined in the?GitFS Walkthrough, though the global configuration options are named differently to reflect that they are for winrepo instead of gitfs.

WINREPO_USER

2015.8.0 新版功能.

Default:?''

Along with?winrepo_password, is used to authenticate to HTTPS remotes.

winrepo_user: git

WINREPO_PASSWORD

2015.8.0 新版功能.

Default:?''

Along with?winrepo_user, is used to authenticate to HTTPS remotes. This parameter is not required if the repository does not use authentication.

winrepo_password: mypassword

WINREPO_INSECURE_AUTH

2015.8.0 新版功能.

缺省:'False'

By default, Salt will not authenticate to an HTTP (non-HTTPS) remote. This parameter enables authentication over HTTP.?Enable this at your own risk.

winrepo_insecure_auth: True

WINREPO_PUBKEY

2015.8.0 新版功能.

Default:?''

Along with?winrepo_privkey?(and optionally?winrepo_passphrase), is used to authenticate to SSH remotes.

winrepo_pubkey: /path/to/key.pub

WINREPO_PRIVKEY

2015.8.0 新版功能.

Default:?''

Along with?winrepo_pubkey?(and optionally?winrepo_passphrase), is used to authenticate to SSH remotes.

winrepo_privkey: /path/to/key

WINREPO_PASSPHRASE

2015.8.0 新版功能.

Default:?''

This parameter is optional, required only when the SSH key being used to authenticate is protected by a passphrase.

winrepo_passphrase: mypassphrase

Salt系統(tǒng)非常簡(jiǎn)單并且易于配置，Salt系統(tǒng)的兩個(gè)組件都有各自的配置文件。如"salt-master"是通過(guò)主配置文件來(lái)配置的,"salt-minion"是通過(guò)子節(jié)點(diǎn)配置文件來(lái)配置的。

參見(jiàn)

:參考:`Master 配置文件的例子 <configuration-examples-master>`

The configuration file for the salt-master is located at?/etc/salt/master?by default. A notable exception is FreeBSD, where the configuration file is located at?/usr/local/etc/salt. The available options are as follows:

MASTER的主要配置

網(wǎng)絡(luò)接口

默認(rèn):?0.0.0.0?(所有的網(wǎng)絡(luò)接口都可訪問(wèn))

綁定本地接口

interface: 192.168.0.1

IPV6

缺省:'False'

Whether the master should listen for IPv6 connections. If this is set to True, the interface option must be adjusted too (for example: "interface: '::'")

ipv6: True

提供服務(wù)的端口

默認(rèn):?4505

The network port to set up the publication interface.

publish_port: 4505

MASTER_ID

缺省:"None"

The id to be passed in the publish job to minions. This is used for MultiSyndics to return the job to the requesting master.

注解

This must be the same string as the syndic is configured with.

master_id: MasterOfMaster

“USER”

缺省:"root"

用戶運(yùn)行salt的過(guò)程

user: root

最大打開(kāi)文件數(shù)MAX_OPEN_FILES

Default:?100000

Each minion connecting to the master uses AT LEAST one file descriptor, the master subscription connection. If enough minions connect you might start seeing on the console(and then salt-master crashes):

Too many open files (tcp_listener.cpp:335) Aborted (core dumped) max_open_files: 100000

默認(rèn)值是`ulimit -Hn` 命令結(jié)果中的一個(gè)，比如，最大可打開(kāi)文件數(shù)的上限。

To set a different value than the default one, uncomment, and configure this setting. Remember that this value CANNOT be higher than the hard limit. Raising the hard limit depends on the OS and/or distribution, a good way to find the limit is to search the internet for something like this:

raise max open files hard limit debian

工作線程

默認(rèn):?5

接收命令和響應(yīng)minion的線程數(shù)量。如果因?yàn)閙inion太多引起響應(yīng)延遲的話，可提高工作線程worker_threads的值

使用對(duì)稱系統(tǒng)時(shí)工作線程數(shù)量不能小于3，其他情況可最小到1

注解

When the master daemon starts, it is expected behaviour to see multiple salt-master processes, even if 'worker_threads' is set to '1'. At a minimum, a controlling process will start along with a Publisher, an EventPublisher, and a number of MWorker processes will be started. The number of MWorker processes is tuneable by the 'worker_threads' configuration value while the others are not.

worker_threads: 5

返回端口

缺省:"4506"

返回服務(wù)器使用的端口，返回服務(wù)器是指Salt接收?qǐng)?zhí)行返回結(jié)果和命令執(zhí)行情況的服務(wù)器

ret_port: 4506

“PIDFILE”

默認(rèn):?/var/run/salt-master.pid

Specify the location of the master pidfile.

pidfile: /var/run/salt-master.pid

‘ROOT_DIR’

默認(rèn):?/

The system root directory to operate from, change this to make Salt run from an alternative root.

root_dir: /

注解

This directory is prepended to the following options:?pki_dir,?cachedir,?sock_dir,?log_file,?autosign_file,?autoreject_file,?pidfile.

"PKI_DIR"

缺省:?/etc/salt/pki

保存pki認(rèn)證密鑰的路徑

pki_dir: /etc/salt/pki

EXTENSION_MODULES

在 2016.3.0 版更改:?The default location for this directory has been moved. Prior to this version, the location was a directory named?extmods?in the Salt cachedir (on most platforms,?/var/cache/salt/extmods). It has been moved into the master cachedir (on most platforms,?/var/cache/salt/master/extmods).

Directory for custom modules. This directory can contain subdirectories for each of Salt's module types such as?runners,?output,?wheel,?modules,?states,?returners, etc. This path is appended to?root_dir.

extension_modules: /root/salt_extmods

MODULE_DIRS

缺省:'[]'

Like?extension_modules, but a list of extra directories to search for Salt modules.

module_dirs:- /var/cache/salt/minion/extmods

'CACHEDIR'

缺省:?/var/cache/salt

保存緩存信息的位置，特別是執(zhí)行salt命令的作業(yè)信息。

This directory may contain sensitive data and should be protected accordingly.

cachedir: /var/cache/salt

'VERIFY_ENV'

缺省:'True'

在啟動(dòng)的時(shí)候，驗(yàn)證和設(shè)置權(quán)限配置目錄。

verify_env: True

KEEP_JOBS

缺省:?24

Set the number of hours to keep old job information.

TIMEOUT

默認(rèn):?5

Set the default timeout for the salt command and api.

LOOP_INTERVAL

Default:?60

The loop_interval option controls the seconds for the master's maintenance process check cycle. This process updates file server backends, cleans the job cache and executes the scheduler.

OUTPUT

Default:?nested

Set the default outputter used by the salt command.

COLOR

缺省:'True'

By default output is colored, to disable colored output set the color value to False.

color: False

‘SOCK_DIR’

Default:?/var/run/salt/master

Set the location to use for creating Unix sockets for master process communication.

sock_dir: /var/run/salt/master

ENABLE_GPU_GRAINS

缺省:'True'

Enable GPU hardware data for your master. Be aware that the master can take a while to start up when lspci and/or dmidecode is used to populate the grains for the master.

作業(yè)緩存

缺省:'True'

The master maintains a job cache, while this is a great addition it can be a burden on the master for larger deployments (over 5000 minions). Disabling the job cache will make previously executed jobs unavailable to the jobs system and is not generally recommended. Normally it is wise to make sure the master has access to a faster IO system or a tmpfs is mounted to the jobs dir.

MINION數(shù)據(jù)緩存

缺省:'True'

The minion data cache is a cache of information about the minions stored on the master, this information is primarily the pillar and grains data. The data is cached in the Master cachedir under the name of the minion and used to predetermine what minions are expected to reply from executions.

minion_data_cache: True

擴(kuò)展作業(yè)緩存

Default:?''

Used to specify a default returner for all minions, when this option is set the specified returner needs to be properly configured and the minions will always default to sending returns to this returner. This will also disable the local job cache on the master.

ext_job_cache: redis

EVENT_RETURN

2015.5.0 新版功能.

Default:?''

Specify the returner to use to log events. A returner may have installation and configuration requirements. Read the returner's documentation.

注解

Not all returners support event returns. Verify that a returner has anevent_return()?function before configuring this option with a returner.

event_return: cassandra_cql

MASTER_JOB_CACHE

2014.7.0 新版功能.

Default: 'local_cache'

Specify the returner to use for the job cache. The job cache will only be interacted with from the salt master and therefore does not need to be accessible from the minions.

master_job_cache: redis

ENFORCE_MINE_CACHE

Default: False

By-default when disabling the minion_data_cache mine will stop working since it is based on cached data, by enabling this option we explicitly enabling only the cache for the mine system.

enforce_mine_cache: False

MAX_MINIONS

Default: 0

The maximum number of minion connections allowed by the master. Use this to accommodate the number of minions per master if you have different types of hardware serving your minions. The default of?0?means unlimited connections. Please note, that this can slow down the authentication process a bit in large setups.

max_minions: 100

CON_CACHE

Default: False

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 all connected minions to all MWorker-processes and greatly improves the performance of max_minions.

con_cache: True

PRESENCE_EVENTS

Default: False

Causes the master to periodically look for actively connected minions.?Presence events?are fired on the event bus on a regular interval with a list of connected minions, as well as events with lists of newly connected or disconnected minions. This is a master-only operation that does not send executions to minions. Note, this does not detect minions that connect to a master via localhost.

presence_events: False

TRANSPORT

Default:?zeromq

Changes the underlying transport layer. ZeroMQ is the recommended transport while additional transport layers are under development. Supported values arezeromq,?raet?(experimental), and?tcp?(experimental). This setting has a significant impact on performance and should not be changed unless you know what you are doing! Transports are explained in?Salt Transports.

transport: zeromq

SALT-SSH CONFIGURATION

ROSTER_FILE

Default:?/etc/salt/roster

Pass in an alternative location for the salt-ssh roster file.

roster_file: /root/roster

SSH_MINION_OPTS

Default: None

Pass in minion option overrides that will be inserted into the SHIM for salt-ssh calls. The local minion config is not used for salt-ssh. Can be overridden on a per-minion basis in the roster (minion_opts)

minion_opts:gpg_keydir: /root/gpg

MASTER SECURITY SETTINGS

OPEN_MODE

缺省:'False'

Open mode is a dangerous security feature. One problem encountered with pki authentication systems is that keys can become "mixed up" and authentication begins to fail. Open mode turns off authentication and tells the master to accept all authentication. This will clean up the pki keys received from the minions. Open mode should not be turned on for general use. Open mode should only be used for a short period of time to clean up pki keys. To turn on open mode set this value to?True.

open_mode: False

AUTO_ACCEPT

缺省:'False'

Enable auto_accept. This setting will automatically accept all incoming public keys from minions.

auto_accept: False

AUTOSIGN_TIMEOUT

2014.7.0 新版功能.

Default:?120

Time in minutes that a incoming public key with a matching name found in pki_dir/minion_autosign/keyid is automatically accepted. Expired autosign keys are removed when the master checks the minion_autosign directory. This method to auto accept minions can be safer than an autosign_file because the keyid record can expire and is limited to being an exact name match. This should still be considered a less than secure option, due to the fact that trust is based on just the requesting minion id.

AUTOSIGN_FILE

Default:?not?defined

If the?autosign_file?is specified incoming keys specified in the autosign_file will be automatically accepted. Matches will be searched for first by string comparison, then by globbing, then by full-string regex matching. This should still be considered a less than secure option, due to the fact that trust is based on just the requesting minion id.

AUTOREJECT_FILE

2014.1.0 新版功能.

Default:?not?defined

Works like?autosign_file, but instead allows you to specify minion IDs for which keys will automatically be rejected. Will override both membership in the?autosign_file?and the?auto_accept?setting.

PUBLISHER_ACL

Default:?{}

Enable user accounts on the master to execute specific modules. These modules can be expressed as regular expressions. Note that client_acl option is deprecated by publisher_acl option and will be removed in future releases.

publisher_acl:fred:- test.ping - pkg.*

PUBLISHER_ACL_BLACKLIST

Default:?{}

Blacklist users or modules

This example would blacklist all non sudo users, including root from running any commands. It would also blacklist any use of the "cmd" module. Note that client_acl_blacklist option is deprecated by publisher_acl_blacklist option and will be removed in future releases.

This is completely disabled by default.

publisher_acl_blacklist:users:- root - '^(?!sudo_).*$' # all non sudo users modules: - cmd

EXTERNAL_AUTH

Default:?{}

The external auth system uses the Salt auth modules to authenticate and validate users to access areas of the Salt system.

external_auth:pam:fred: - test.*

TOKEN_EXPIRE

Default:?43200

Time (in seconds) for a newly generated token to live.

Default: 12 hours

token_expire: 43200

FILE_RECV

缺省:'False'

Allow minions to push files to the master. This is disabled by default, for security purposes.

file_recv: False

MASTER_SIGN_PUBKEY

缺省:'False'

Sign the master auth-replies with a cryptographic signature of the masters public key. Please see the tutorial how to use these settings in the?Multimaster-PKI with Failover Tutorial

master_sign_pubkey: True

MASTER_SIGN_KEY_NAME

Default:?master_sign

The customizable name of the signing-key-pair without suffix.

master_sign_key_name: <filename_without_suffix>

MASTER_PUBKEY_SIGNATURE

Default:?master_pubkey_signature

The name of the file in the masters pki-directory that holds the pre-calculated signature of the masters public-key.

master_pubkey_signature: <filename>

MASTER_USE_PUBKEY_SIGNATURE

缺省:'False'

Instead of computing the signature for each auth-reply, use a pre-calculated signature. The?master_pubkey_signature?must also be set for this.

master_use_pubkey_signature: True

ROTATE_AES_KEY

缺省:'True'

Rotate the salt-masters AES-key when a minion-public is deleted with salt-key. This is a very important security-setting. Disabling it will enable deleted minions to still listen in on the messages published by the salt-master. Do not disable this unless it is absolutely clear what this does.

rotate_aes_key: True

MASTER MODULE MANAGEMENT

RUNNER_DIRS

缺省:'[]'

Set additional directories to search for runner modules.

CYTHON_ENABLE

缺省:'False'

Set to true to enable Cython modules (.pyx files) to be compiled on the fly on the Salt master.

cython_enable: False

MASTER STATE SYSTEM SETTINGS

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.

state_top: top.sls

MASTER_TOPS

Default:?{}

The master_tops option replaces the external_nodes option by creating a pluggable system for the generation of external top data. The external_nodes option is deprecated by the master_tops option. To gain the capabilities of the classic external_nodes system, use the following configuration:

master_tops:ext_nodes: <Shell command which returns yaml>

EXTERNAL_NODES

Default: None

The external_nodes option allows Salt to gather data that would normally be placed in a top file from and external node controller. The external_nodes option is the executable that will return the ENC data. Remember that Salt will look for external nodes AND top files and combine the results if both are enabled and available!

external_nodes: cobbler-ext-nodes

RENDERER

Default:?yaml_jinja

The renderer to use on the minions to render the state data.

renderer: yaml_jinja

FAILHARD

缺省:'False'

Set the global failhard flag, this informs all states to stop running states at the moment a single state fails.

failhard: False

STATE_VERBOSE

缺省:'True'

Controls the verbosity of state runs. By default, the results of all states are returned, but setting this value to?False?will cause salt to only display output for states which either failed, or succeeded without making any changes to the minion.

state_verbose: False

STATE_OUTPUT

Default:?full

The state_output setting changes if the output is the full multi line output for each changed state if set to 'full', but if set to 'terse' the output will be shortened to a single line. If set to 'mixed', the output will be terse unless a state failed, in which case that output will be full. If set to 'changes', the output will be full unless the state didn't change.

state_output: full

STATE_AGGREGATE

缺省:'False'

Automatically aggregate all states that have support for mod_aggregate by setting to?True. Or pass a list of state module names to automatically aggregate just those types.

state_aggregate:- pkg state_aggregate: True

STATE_EVENTS

缺省:'False'

Send progress events as each function in a state run completes execution by setting to?True. Progress events are in the formatsalt/job/<JID>/prog/<MID>/<RUN?NUM>.

state_events: True

YAML_UTF8

缺省:'False'

Enable extra routines for YAML renderer used states containing UTF characters.

yaml_utf8: False

TEST

缺省:'False'

Set all state calls to only test if they are going to actually make changes or just post what changes are going to be made.

test: False

MASTER FILE SERVER SETTINGS

FILESERVER_BACKEND

Default:?['roots']

Salt supports a modular fileserver backend system, this system allows the salt master to link directly to third party systems to gather and manage the files available to minions. Multiple backends can be configured and will be searched for the requested file in the order in which they are defined here. The default setting only enables the standard backend?roots, which is configured using the?file_roots?option.

范例:

fileserver_backend:- roots- git

HASH_TYPE

Default:?md5

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.

hash_type: md5

FILE_BUFFER_SIZE

Default:?1048576

The buffer size in the file server in bytes.

file_buffer_size: 1048576

FILE_IGNORE_REGEX

Default:?''

A regular expression (or a list of expressions) that will be matched against the file path before syncing the modules and states to the minions. This includes files affected by the file.recurse state. For example, if you manage your custom modules and states in subversion and don't want all the '.svn' folders and content synced to your minions, you could set this to '/.svn($|/)'. By default nothing is ignored.

file_ignore_regex:- '/\.svn($|/)'- '/\.git($|/)'

FILE_IGNORE_GLOB

Default?''

A file glob (or list of file globs) that will be matched against the file path before syncing the modules and states to the minions. This is similar to file_ignore_regex above, but works on globs instead of regex. By default nothing is ignored.

file_ignore_glob:- '\*.pyc'- '\*/somefolder/\*.bak' - '\*.swp'

注解

Vim's .swp files are a common cause of Unicode errors in?file.recurse?states which use templating. Unless there is a good reason to distribute them via the fileserver, it is good practice to include?'\*.swp'?in the?file_ignore_glob.

ROOTS: MASTER'S LOCAL FILE SERVER

FILE_ROOTS

Default:

base:- /srv/salt

Salt runs a lightweight file server written in ZeroMQ to deliver files to minions. This file server is built into the master daemon and does not require a dedicated port.

The file server works on environments passed to the master. Each environment can have multiple root directories. The subdirectories in the multiple file roots cannot match, otherwise the downloaded files will not be able to be reliably ensured. A base environment is required to house the top file.

范例:

file_roots:base:- /srv/salt dev: - /srv/salt/dev/services - /srv/salt/dev/states prod: - /srv/salt/prod/services - /srv/salt/prod/states

GIT: GIT REMOTE FILE SERVER BACKEND

GITFS_REMOTES

缺省:'[]'

When using the?git?fileserver backend at least one git remote needs to be defined. The user running the salt master will need read access to the repo.

The repos will be searched in order to find the file requested by a client and the first repo to have the file will return it. Branches and tags are translated into salt environments.

gitfs_remotes:- git://github.com/saltstack/salt-states.git- file:///var/git/saltmaster

注解

file://?repos will be treated as a remote and copied into the master's gitfs cache, so only the?local?refs for those repos will be exposed as fileserver environments.

As of 2014.7.0, it is possible to have per-repo versions of several of the gitfs configuration parameters. For more information, see the?GitFS Walkthrough.

GITFS_PROVIDER

2014.7.0 新版功能.

Optional parameter used to specify the provider to be used for gitfs. More information can be found in the?GitFS Walkthrough.

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.

gitfs_provider: dulwich

GITFS_SSL_VERIFY

缺省:'True'

Specifies whether or not to ignore SSL certificate errors when contacting the remote repository. You might want to set this to?False?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.

gitfs_ssl_verify: True

GITFS_MOUNTPOINT

2014.7.0 新版功能.

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?gitfs_root. It can also be configured on a per-remote basis, see?here?for more info.

gitfs_mountpoint: salt://foo/bar

注解

The?salt://?protocol designation can be left off (in other words,?foo/bar?and?salt://foo/bar?are equivalent). Assuming a file?baz.sh?in the root of a gitfs remote, and the above example mountpoint, this file would be served up via?salt://foo/bar/baz.sh.

GITFS_ROOT

Default:?''

Relative path to a subdirectory within the repository from which Salt should begin to serve files. This is useful when there are files in the repository that should not be available to the Salt fileserver. Can be used in conjunction with?gitfs_mountpoint. If used, then from Salt's perspective the directories above the one specified will be ignored and the relative path will (for the purposes of gitfs) be considered as the root of the repo.

gitfs_root: somefolder/otherfolder

在 2014.7.0 版更改:?Ability to specify gitfs roots on a per-remote basis was added. See?here?for more info.

GITFS_BASE

Default:?master

Defines which branch/tag should be used as the?base?environment.

gitfs_base: salt

在 2014.7.0 版更改:?Ability to specify the base on a per-remote basis was added. See?here?for more info.

GITFS_ENV_WHITELIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if the repos in?gitfs_remotes?contain many branches/tags. More information can be found in the?GitFS Walkthrough.

gitfs_env_whitelist:- base- v1.* - 'mybranch\d+'

GITFS_ENV_BLACKLIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if the repos in?gitfs_remotes?contain many branches/tags. More information can be found in the?GitFS Walkthrough.

gitfs_env_blacklist:- base- v1.* - 'mybranch\d+'

GITFS AUTHENTICATION OPTIONS

These parameters only currently apply to the pygit2 gitfs provider. Examples of how to use these can be found in the?GitFS Walkthrough.

GITFS_USER

2014.7.0 新版功能.

Default:?''

Along with?gitfs_password, is used to authenticate to HTTPS remotes.

gitfs_user: git

GITFS_PASSWORD

2014.7.0 新版功能.

Default:?''

Along with?gitfs_user, is used to authenticate to HTTPS remotes. This parameter is not required if the repository does not use authentication.

gitfs_password: mypassword

GITFS_INSECURE_AUTH

2014.7.0 新版功能.

缺省:'False'

By default, Salt will not authenticate to an HTTP (non-HTTPS) remote. This parameter enables authentication over HTTP.?Enable this at your own risk.

gitfs_insecure_auth: True

GITFS_PUBKEY

2014.7.0 新版功能.

Default:?''

Along with?gitfs_privkey?(and optionally?gitfs_passphrase), is used to authenticate to SSH remotes. This parameter (or its?per-remote counterpart) is required for SSH remotes.

gitfs_pubkey: /path/to/key.pub

GITFS_PRIVKEY

2014.7.0 新版功能.

Default:?''

Along with?gitfs_pubkey?(and optionally?gitfs_passphrase), is used to authenticate to SSH remotes. This parameter (or its?per-remote counterpart) is required for SSH remotes.

gitfs_privkey: /path/to/key

GITFS_PASSPHRASE

2014.7.0 新版功能.

Default:?''

This parameter is optional, required only when the SSH key being used to authenticate is protected by a passphrase.

gitfs_passphrase: mypassphrase

HG: MERCURIAL REMOTE FILE SERVER BACKEND

HGFS_REMOTES

0.17.0 新版功能.

缺省:'[]'

When using the?hg?fileserver backend at least one mercurial remote needs to be defined. The user running the salt master will need read access to the repo.

The repos will be searched in order to find the file requested by a client and the first repo to have the file will return it. Branches and/or bookmarks are translated into salt environments, as defined by the?hgfs_branch_methodparameter.

hgfs_remotes:- https://username@bitbucket.org/username/reponame

注解

As of 2014.7.0, it is possible to have per-repo versions of the?hgfs_root,?hgfs_mountpoint,?hgfs_base, and?hgfs_branch_method?parameters. For example:

hgfs_remotes:- https://username@bitbucket.org/username/repo1- base: saltstates - https://username@bitbucket.org/username/repo2: - root: salt - mountpoint: salt://foo/bar/baz - https://username@bitbucket.org/username/repo3: - root: salt/states - branch_method: mixed

HGFS_BRANCH_METHOD

0.17.0 新版功能.

Default:?branches

Defines the objects that will be used as fileserver environments.

• branches?- Only branches and tags will be used
• bookmarks?- Only bookmarks and tags will be used
• mixed?- Branches, bookmarks, and tags will be used

hgfs_branch_method: mixed

注解

Starting in version 2014.1.0, the value of the?hgfs_base?parameter defines which branch is used as the?base?environment, allowing for a?base?environment to be used with an?hgfs_branch_method?of?bookmarks.

Prior to this release, the?default?branch will be used as the?base?environment.

HGFS_MOUNTPOINT

2014.7.0 新版功能.

Default:?''

Specifies a path on the salt fileserver which will be prepended to all files served by hgfs. This option can be used in conjunction with?hgfs_root. It can also be configured on a per-remote basis, see?here?for more info.

hgfs_mountpoint: salt://foo/bar

注解

The?salt://?protocol designation can be left off (in other words,?foo/bar?and?salt://foo/bar?are equivalent). Assuming a file?baz.sh?in the root of an hgfs remote, this file would be served up via?salt://foo/bar/baz.sh.

HGFS_ROOT

0.17.0 新版功能.

Default:?''

Relative path to a subdirectory within the repository from which Salt should begin to serve files. This is useful when there are files in the repository that should not be available to the Salt fileserver. Can be used in conjunction with?hgfs_mountpoint. If used, then from Salt's perspective the directories above the one specified will be ignored and the relative path will (for the purposes of hgfs) be considered as the root of the repo.

hgfs_root: somefolder/otherfolder

在 2014.7.0 版更改:?Ability to specify hgfs roots on a per-remote basis was added. See?here?for more info.

HGFS_BASE

2014.1.0 新版功能.

Default:?default

Defines which branch should be used as the?base?environment. Change this ifhgfs_branch_method?is set to?bookmarks?to specify which bookmark should be used as the?base?environment.

hgfs_base: salt

HGFS_ENV_WHITELIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if your hgfs remotes contain many branches/bookmarks/tags. Full names, globs, and regular expressions are supported. If using a regular expression, the 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?hgfs_env_blacklist, then the subset of branches/bookmarks/tags which match the whitelist but do?not?match the blacklist will be exposed as fileserver environments.

hgfs_env_whitelist:- base- v1.* - 'mybranch\d+'

HGFS_ENV_BLACKLIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if your hgfs remotes contain many branches/bookmarks/tags. Full names, globs, and regular expressions are supported. If using a regular expression, the 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?hgfs_env_whitelist, then the subset of branches/bookmarks/tags which match the whitelist but do?not?match the blacklist will be exposed as fileserver environments.

hgfs_env_blacklist:- base- v1.* - 'mybranch\d+'

SVN: SUBVERSION REMOTE FILE SERVER BACKEND

SVNFS_REMOTES

0.17.0 新版功能.

缺省:'[]'

When using the?svn?fileserver backend at least one subversion remote needs to be defined. The user running the salt master will need read access to the repo.

The repos will be searched in order to find the file requested by a client and the first repo to have the file will return it. The trunk, branches, and tags become environments, with the trunk being the?base?environment.

svnfs_remotes:- svn://foo.com/svn/myproject

注解

As of 2014.7.0, it is possible to have per-repo versions of the following configuration parameters:

• svnfs_root
• svnfs_mountpoint
• svnfs_trunk
• svnfs_branches
• svnfs_tags

For example:

svnfs_remotes:- svn://foo.com/svn/project1- svn://foo.com/svn/project2: - root: salt - mountpoint: salt://foo/bar/baz - svn//foo.com/svn/project3: - root: salt/states - branches: branch - tags: tag

SVNFS_MOUNTPOINT

2014.7.0 新版功能.

Default:?''

Specifies a path on the salt fileserver which will be prepended to all files served by hgfs. This option can be used in conjunction with?svnfs_root. It can also be configured on a per-remote basis, see?here?for more info.

svnfs_mountpoint: salt://foo/bar

注解

The?salt://?protocol designation can be left off (in other words,?foo/bar?and?salt://foo/bar?are equivalent). Assuming a file?baz.sh?in the root of an svnfs remote, this file would be served up via?salt://foo/bar/baz.sh.

SVNFS_ROOT

0.17.0 新版功能.

Default:?''

Relative path to a subdirectory within the repository from which Salt should begin to serve files. This is useful when there are files in the repository that should not be available to the Salt fileserver. Can be used in conjunction with?svnfs_mountpoint. If used, then from Salt's perspective the directories above the one specified will be ignored and the relative path will (for the purposes of svnfs) be considered as the root of the repo.

svnfs_root: somefolder/otherfolder

在 2014.7.0 版更改:?Ability to specify svnfs roots on a per-remote basis was added. See?here?for more info.

SVNFS_TRUNK

2014.7.0 新版功能.

Default:?trunk

Path relative to the root of the repository where the trunk is located. Can also be configured on a per-remote basis, see?here?for more info.

svnfs_trunk: trunk

SVNFS_BRANCHES

2014.7.0 新版功能.

Default:?branches

Path relative to the root of the repository where the branches are located. Can also be configured on a per-remote basis, see?here?for more info.

svnfs_branches: branches

SVNFS_TAGS

2014.7.0 新版功能.

Default:?tags

Path relative to the root of the repository where the tags are located. Can also be configured on a per-remote basis, see?here?for more info.

svnfs_tags: tags

SVNFS_ENV_WHITELIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if your svnfs remotes contain many branches/tags. Full names, globs, and regular expressions are supported. If using a regular expression, the expression 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?svnfs_env_blacklist, then the subset of branches/tags which match the whitelist but do?not?match the blacklist will be exposed as fileserver environments.

svnfs_env_whitelist:- base- v1.* - 'mybranch\d+'

SVNFS_ENV_BLACKLIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which environments are made available. Can speed up state runs if your svnfs remotes contain many branches/tags. Full names, globs, and regular expressions are supported. If using a regular expression, the 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?svnfs_env_whitelist, then the subset of branches/tags which match the whitelist but do?not?match the blacklist will be exposed as fileserver environments.

svnfs_env_blacklist:- base- v1.* - 'mybranch\d+'

MINION: MINIONFS REMOTE FILE SERVER BACKEND

MINIONFS_ENV

2014.7.0 新版功能.

Default:?base

Environment from which MinionFS files are made available.

minionfs_env: minionfs

MINIONFS_MOUNTPOINT

2014.7.0 新版功能.

Default:?''

Specifies a path on the salt fileserver from which minionfs files are served.

minionfs_mountpoint: salt://foo/bar

注解

The?salt://?protocol designation can be left off (in other words,?foo/bar?and?salt://foo/bar?are equivalent).

MINIONFS_WHITELIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which minions' pushed files are exposed via minionfs. If using a regular expression, the expression must match the entire minion ID.

If used, only the pushed files from minions which match one of the specified expressions will be exposed.

If used in conjunction with?minionfs_blacklist, then the subset of hosts which match the whitelist but do?not?match the blacklist will be exposed.

minionfs_whitelist:- base- v1.* - 'mybranch\d+'

MINIONFS_BLACKLIST

2014.7.0 新版功能.

缺省:'[]'

Used to restrict which minions' pushed files are exposed via minionfs. If using a regular expression, the expression must match the entire minion ID.

If used, only the pushed files from minions which match one of the specified expressions will?not?be exposed.

If used in conjunction with?minionfs_whitelist, then the subset of hosts which match the whitelist but do?not?match the blacklist will be exposed.

minionfs_blacklist:- base- v1.* - 'mybranch\d+'

PILLAR CONFIGURATION

PILLAR_ROOTS

Default:

base:- /srv/pillar

Set the environments and directories used to hold pillar sls data. This configuration is the same as?file_roots:

pillar_roots:base:- /srv/pillar dev: - /srv/pillar/dev prod: - /srv/pillar/prod

EXT_PILLAR

The ext_pillar option allows for any number of external pillar interfaces to be called when populating pillar data. The configuration is based on ext_pillar functions. The available ext_pillar functions can be found herein:

https://github.com/saltstack/salt/blob/develop/salt/pillar

By default, the ext_pillar interface is not configured to run.

缺省:"None"

ext_pillar:- hiera: /etc/hiera.yaml - cmd_yaml: cat /etc/salt/yaml - reclass: inventory_base_uri: /etc/reclass

There are additional details at?Pillars

PILLAR_ROOTS_OVERRIDE_EXT_PILLAR

Boron 新版功能.

缺省:'False'

This option allows for external pillar sources to be evaluated beforepillar_roots, which means that values obtained from?pillar_roots?take precedence over those found from?ext_pillar?sources.

pillar_roots_override_ext_pillar: False

EXT_PILLAR_FIRST

2015.5.0 新版功能.

缺省:'False'

This option allows for external pillar sources to be evaluated beforepillar_roots. This allows for targeting file system pillar from ext_pillar. Note that ext_pillar_first option is deprecated by pillar_roots_override_ext_pillar option and will be removed in future releases.

ext_pillar_first: False

GIT EXTERNAL PILLAR (GIT_PILLAR) CONFIGURATION OPTIONS

GIT_PILLAR_PROVIDER

2015.8.0 新版功能.

Specify the provider to be used for git_pillar. Must be either?pygit2?orgitpython. If unset, then both will be tried in that same order, and the first one with a compatible version installed will be the provider that is used.

git_pillar_provider: gitpython

GIT_PILLAR_BASE

2015.8.0 新版功能.

Default:?master

If the desired branch matches this value, and the environment is omitted from the git_pillar configuration, then the environment for that git_pillar remote will be?base. For example, in the configuration below, the?foo?branch/tag would be assigned to the?base?environment, while?bar?would be mapped to the?barenvironment.

git_pillar_base: fooext_pillar:- git: - foo https://mygitserver/git-pillar.git - bar https://mygitserver/git-pillar.git

GIT_PILLAR_BRANCH

2015.8.0 新版功能.

Default:?master

If the branch is omitted from a git_pillar remote, then this branch will be used instead. For example, in the configuration below, the first two remotes would use the?pillardata?branch/tag, while the third would use the?foo?branch/tag.

git_pillar_branch: pillardataext_pillar:- git: - https://mygitserver/pillar1.git - https://mygitserver/pillar2.git: - root: pillar - foo https://mygitserver/pillar3.git

GIT_PILLAR_ENV

2015.8.0 新版功能.

Default:?''?(unset)

Environment to use for git_pillar remotes. This is normally derived from the branch/tag (or from a per-remote?env?parameter), but if set this will override the process of deriving the env from the branch/tag name. For example, in the configuration below the?foo?branch would be assigned to the?baseenvironment, while the?bar?branch would need to explicitly have?barconfigured as it's environment to keep it from also being mapped to the?baseenvironment.

git_pillar_env: baseext_pillar:- git: - foo https://mygitserver/git-pillar.git - bar https://mygitserver/git-pillar.git: - env: bar

For this reason, this option is recommended to be left unset, unless the use case calls for all (or almost all) of the git_pillar remotes to use the same environment irrespective of the branch/tag being used.

GIT_PILLAR_ROOT

2015.8.0 新版功能.

Default:?''

Path relative to the root of the repository where the git_pillar top file and SLS files are located. In the below configuration, the pillar top file and SLS files would be looked for in a subdirectory called?pillar.

git_pillar_root: pillarext_pillar:- git: - master https://mygitserver/pillar1.git - master https://mygitserver/pillar2.git

注解

This is a global option. If only one or two repos need to have their files sourced from a subdirectory, then?git_pillar_root?can be omitted and the root can be specified on a per-remote basis, like so:

ext_pillar:- git:- master https://mygitserver/pillar1.git - master https://mygitserver/pillar2.git: - root: pillar

In this example, for the first remote the top file and SLS files would be looked for in the root of the repository, while in the second remote the pillar data would be retrieved from the?pillar?subdirectory.

GIT_PILLAR_SSL_VERIFY

2015.8.0 新版功能.

缺省:'True'

Specifies whether or not to ignore SSL certificate errors when contacting the remote repository. You might want to set this to?False?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.

git_pillar_ssl_verify: True

GIT EXTERNAL PILLAR AUTHENTICATION OPTIONS

These parameters only currently apply to the?pygit2?git_pillar_provider. Authentication works the same as it does in gitfs, as outlined in the?GitFS Walkthrough, though the global configuration options are named differently to reflect that they are for git_pillar instead of gitfs.

GIT_PILLAR_USER

2015.8.0 新版功能.

Default:?''

Along with?git_pillar_password, is used to authenticate to HTTPS remotes.

git_pillar_user: git

GIT_PILLAR_PASSWORD

2015.8.0 新版功能.

Default:?''

Along with?git_pillar_user, is used to authenticate to HTTPS remotes. This parameter is not required if the repository does not use authentication.

git_pillar_password: mypassword

GIT_PILLAR_INSECURE_AUTH

2015.8.0 新版功能.

缺省:'False'

By default, Salt will not authenticate to an HTTP (non-HTTPS) remote. This parameter enables authentication over HTTP.?Enable this at your own risk.

git_pillar_insecure_auth: True

GIT_PILLAR_PUBKEY

2015.8.0 新版功能.

Default:?''

Along with?git_pillar_privkey?(and optionally?git_pillar_passphrase), is used to authenticate to SSH remotes.

git_pillar_pubkey: /path/to/key.pub

GIT_PILLAR_PRIVKEY

2015.8.0 新版功能.

Default:?''

Along with?git_pillar_pubkey?(and optionally?git_pillar_passphrase), is used to authenticate to SSH remotes.

git_pillar_privkey: /path/to/key

GIT_PILLAR_PASSPHRASE

2015.8.0 新版功能.

Default:?''

This parameter is optional, required only when the SSH key being used to authenticate is protected by a passphrase.

git_pillar_passphrase: mypassphrase

PILLAR_SOURCE_MERGING_STRATEGY

2014.7.0 新版功能.

Default:?smart

The pillar_source_merging_strategy option allows you to configure merging strategy between different sources. It accepts 4 values:

• recurse:

  it will merge recursively mapping of data. For example, theses 2 sources:

  foo: 42 bar:element1: True bar:element2: True baz: quux

  will be merged as:

  foo: 42 bar:element1: True element2: True baz: quux

• aggregate:

  instructs aggregation of elements between sources that use the #!yamlex renderer.

  For example, these two documents:

  #!yamlex foo: 42 bar: !aggregate { element1: True } baz: !aggregate quux #!yamlex bar: !aggregate {element2: True } baz: !aggregate quux2

  will be merged as:

  foo: 42 bar:element1: True element2: True baz: - quux - quux2

• overwrite:

  Will use the behaviour of the 2014.1 branch and earlier.

  Overwrites elements according the order in which they are processed.

  First pillar processed:

  A:first_key: blahsecond_key: blah

  Second pillar processed:

  A:third_key: blahfourth_key: blah

  will be merged as:

  A:third_key: blahfourth_key: blah

• smart (default):

  Guesses the best strategy based on the "renderer" setting.

PILLAR_MERGE_LISTS

2015.8.0 新版功能.

缺省:'False'

Recursively merge lists by aggregating them instead of replacing them.

pillar_merge_lists: False

SYNDIC SERVER SETTINGS

A Salt syndic is a Salt master used to pass commands from a higher Salt master to minions below the syndic. Using the syndic is simple. If this is a master that will have syndic servers(s) below it, set the "order_masters" setting to True.

If this is a master that will be running a syndic daemon for passthrough the "syndic_master" setting needs to be set to the location of the master server.

Do not not forget that, in other words, it means that it shares with the local minion its ID and PKI_DIR.

ORDER_MASTERS

缺省:'False'

Extra data needs to be sent with publications if the master is controlling a lower level master via a syndic minion. If this is the case the order_masters value must be set to True

order_masters: False

SYNDIC_MASTER

缺省:"None"

If this master will be running a salt-syndic to connect to a higher level master, specify the higher level master with this configuration value.

syndic_master: masterofmasters

You can optionally connect a syndic to multiple higher level masters by setting the 'syndic_master' value to a list:

syndic_master:- masterofmasters1- masterofmasters2

Each higher level master must be set up in a multimaster configuration.

SYNDIC_MASTER_PORT

缺省:"4506"

If this master will be running a salt-syndic to connect to a higher level master, specify the higher level master port with this configuration value.

syndic_master_port: 4506

SYNDIC_PIDFILE

Default:?salt-syndic.pid

If this master will be running a salt-syndic to connect to a higher level master, specify the pidfile of the syndic daemon.

syndic_pidfile: syndic.pid

SYNDIC_LOG_FILE

Default:?syndic.log

If this master will be running a salt-syndic to connect to a higher level master, specify the log_file of the syndic daemon.

syndic_log_file: salt-syndic.log

PEER PUBLISH SETTINGS

Salt minions can send commands to other minions, but only if the minion is allowed to. By default "Peer Publication" is disabled, and when enabled it is enabled for specific minions and specific commands. This allows secure compartmentalization of commands based on individual minions.

PEER

Default:?{}

The configuration uses regular expressions to match minions and then a list of regular expressions to match functions. The following will allow the minion authenticated as foo.example.com to execute functions from the test and pkg modules.

peer:foo.example.com:- test.* - pkg.*

This will allow all minions to execute all commands:

peer:.*:- .*

This is not recommended, since it would allow anyone who gets root on any single minion to instantly have root on all of the minions!

By adding an additional layer you can limit the target hosts in addition to the accessible commands:

peer:foo.example.com:'db*': - test.* - pkg.*

PEER_RUN

Default:?{}

The peer_run option is used to open up runners on the master to access from the minions. The peer_run configuration matches the format of the peer configuration.

The following example would allow foo.example.com to execute the manage.up runner:

peer_run:foo.example.com:- manage.up

MASTER LOGGING SETTINGS

LOG_FILE

Default:?/var/log/salt/master

The master log can be sent to a regular file, local path name, or network location. See also?log_file.

Examples:

log_file: /var/log/salt/master log_file: file:///dev/log log_file: udp://loghost:10514

LOG_LEVEL

Default:?warning

The level of messages to send to the console. See also?log_level.

log_level: warning

LOG_LEVEL_LOGFILE

Default:?warning

The level of messages to send to the log file. See also?log_level_logfile. When it is not set explicitly it will inherit the level set by?log_level?option.

log_level_logfile: warning

LOG_DATEFMT

Default:?%H:%M:%S

The date and time format used in console log messages. See also?log_datefmt.

log_datefmt: '%H:%M:%S'

LOG_DATEFMT_LOGFILE

Default:?%Y-%m-%d?%H:%M:%S

The date and time format used in log file messages. See alsolog_datefmt_logfile.

log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'

LOG_FMT_CONSOLE

Default:?[%(levelname)-8s]?%(message)s

The format of the console logging messages. See also?log_fmt_console.

注解

Log colors are enabled in?log_fmt_console?rather than the?color?config since the logging system is loaded before the master config.

Console log colors are specified by these additional formatters:

%(colorlevel)s %(colorname)s %(colorprocess)s %(colormsg)s

Since it is desirable to include the surrounding brackets, '[' and ']', in the coloring of the messages, these color formatters also include padding as well. Color LogRecord attributes are only available for console logging.

log_fmt_console: '%(colorlevel)s %(colormsg)s' log_fmt_console: '[%(levelname)-8s] %(message)s'

LOG_FMT_LOGFILE

Default:?%(asctime)s,%(msecs)03.0f?[%(name)-17s][%(levelname)-8s]?%(message)s

The format of the log file logging messages. See also?log_fmt_logfile.

log_fmt_logfile: '%(asctime)s,%(msecs)03.0f [%(name)-17s][%(levelname)-8s] %(message)s'

LOG_GRANULAR_LEVELS

Default:?{}

This can be used to control logging levels more specifically. See alsolog_granular_levels.

NODE GROUPS

Default:?{}

Node groups allow for logical groupings of minion nodes. A group consists of a group name and a compound target.

nodegroups:group1: 'L@foo.domain.com,bar.domain.com,baz.domain.com or bl*.domain.com' group2: 'G@os:Debian and foo.domain.com' group3: 'G@os:Debian and N@group1' group4: - 'G@foo:bar' - 'or' - 'G@foo:baz'

More information on using nodegroups can be found?here.

RANGE CLUSTER SETTINGS

RANGE_SERVER

Default:?''

The range server (and optional port) that serves your cluster informationhttps://github.com/ytoolshed/range/wiki/%22yamlfile%22-module-file-spec

range_server: range:80

INCLUDE CONFIGURATION

DEFAULT_INCLUDE

Default:?master.d/*.conf

The master can include configuration from other files. Per default the master will automatically include all config files from?master.d/*.conf?where?master.dis relative to the directory of the master configuration file.

INCLUDE

Default:?not?defined

The master can include configuration from other files. To enable this, pass a list of paths to this option. The paths can be either relative or absolute; if relative, they are considered to be relative to the directory the main minion configuration file lives in. Paths can make use of shell-style globbing. If no files are matched by a path passed to this option then the master will log a warning message.

# Include files from a master.d directory in the same # directory as the master config file include: master.d/*# Include a single extra file into the configuration include: /etc/roles/webserver # Include several files and the master.d directory include: - extra_config - master.d/* - /etc/roles/webserver

WINDOWS SOFTWARE REPO SETTINGS

WINREPO_PROVIDER

2015.8.0 新版功能.

Specify the provider to be used for winrepo. Must be either?pygit2?orgitpython. If unset, then both will be tried in that same order, and the first one with a compatible version installed will be the provider that is used.

winrepo_provider: gitpython

WINREPO_DIR

在 2015.8.0 版更改:?Renamed from?win_repo?to?winrepo_dir.

Default:?/srv/salt/win/repo

Location on the master where the?winrepo_remotes?are checked out for pre-2015.8.0 minions. 2015.8.0 and later minions use?winrepo_remotes_ng?instead.

winrepo_dir: /srv/salt/win/repo

WINREPO_DIR_NG

2015.8.0 新版功能:?A new?ng?repo was added.

Default:?/srv/salt/win/repo-ng

Location on the master where the?winrepo_remotes_ng?are checked out for 2015.8.0 and later minions.

winrepo_dir_ng: /srv/salt/win/repo-ng

WINREPO_CACHEFILE

在 2015.8.0 版更改:?Renamed from?win_repo_mastercachefile?to?winrepo_cachefile

注解

2015.8.0 and later minions do not use this setting since the cachefile is now located on the minion.

Default:?winrepo.p

Path relative to?winrepo_dir?where the winrepo cache should be created.

winrepo_cachefile: winrepo.p

WINREPO_REMOTES

在 2015.8.0 版更改:?Renamed from?win_gitrepos?to?winrepo_remotes.

Default:?['https://github.com/saltstack/salt-winrepo.git']

List of git repositories to checkout and include in the winrepo for pre-2015.8.0 minions. 2015.8.0 and later minions use?winrepo_remotes_ng?instead.

winrepo_remotes:- https://github.com/saltstack/salt-winrepo.git

To specify a specific revision of the repository, prepend a commit ID to the URL of the repository:

winrepo_remotes:- '<commit_id> https://github.com/saltstack/salt-winrepo.git'

Replace?<commit_id>?with the SHA1 hash of a commit ID. Specifying a commit ID is useful in that it allows one to revert back to a previous version in the event that an error is introduced in the latest revision of the repo.

WINREPO_REMOTES_NG

2015.8.0 新版功能:?A new?ng?repo was added.

Default:?['https://github.com/saltstack/salt-winrepo-ng.git']

List of git repositories to checkout and include in the winrepo for 2015.8.0 and later minions.

winrepo_remotes_ng:- https://github.com/saltstack/salt-winrepo-ng.git

To specify a specific revision of the repository, prepend a commit ID to the URL of the repository:

winrepo_remotes:- '<commit_id> https://github.com/saltstack/salt-winrepo-ng.git'

Replace?<commit_id>?with the SHA1 hash of a commit ID. Specifying a commit ID is useful in that it allows one to revert back to a previous version in the event that an error is introduced in the latest revision of the repo.

WINREPO_BRANCH

2015.8.0 新版功能.

Default:?master

If the branch is omitted from a winrepo remote, then this branch will be used instead. For example, in the configuration below, the first two remotes would use the?winrepo?branch/tag, while the third would use the?foo?branch/tag.

winrepo_branch: winrepoext_pillar:- git: - https://mygitserver/winrepo1.git - https://mygitserver/winrepo2.git: - foo https://mygitserver/winrepo3.git

WINREPO_SSL_VERIFY

2015.8.0 新版功能.

缺省:'True'

Specifies whether or not to ignore SSL certificate errors when contacting the remote repository. You might want to set this to?False?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.

winrepo_ssl_verify: True

WINREPO AUTHENTICATION OPTIONS

These parameters only currently apply to the?pygit2?winrepo_provider. Authentication works the same as it does in gitfs, as outlined in the?GitFS Walkthrough, though the global configuration options are named differently to reflect that they are for winrepo instead of gitfs.

WINREPO_USER

2015.8.0 新版功能.

Default:?''

Along with?winrepo_password, is used to authenticate to HTTPS remotes.

winrepo_user: git

WINREPO_PASSWORD

2015.8.0 新版功能.

Default:?''

Along with?winrepo_user, is used to authenticate to HTTPS remotes. This parameter is not required if the repository does not use authentication.

winrepo_password: mypassword

WINREPO_INSECURE_AUTH

2015.8.0 新版功能.

缺省:'False'

By default, Salt will not authenticate to an HTTP (non-HTTPS) remote. This parameter enables authentication over HTTP.?Enable this at your own risk.

winrepo_insecure_auth: True

WINREPO_PUBKEY

2015.8.0 新版功能.

Default:?''

Along with?winrepo_privkey?(and optionally?winrepo_passphrase), is used to authenticate to SSH remotes.

winrepo_pubkey: /path/to/key.pub

WINREPO_PRIVKEY

2015.8.0 新版功能.

Default:?''

Along with?winrepo_pubkey?(and optionally?winrepo_passphrase), is used to authenticate to SSH remotes.

winrepo_privkey: /path/to/key

WINREPO_PASSPHRASE

2015.8.0 新版功能.

Default:?''

This parameter is optional, required only when the SSH key being used to authenticate is protected by a passphrase.

winrepo_passphrase: mypassphrase

轉(zhuǎn)載于:https://www.cnblogs.com/benjamin77/p/7837149.html

總結(jié)

以上是生活随笔為你收集整理的slatstack Master的配置的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。