saltstack官方文档——Configuring the Salt Master

浪人

　　转自：http://docs.saltstack.com/ref/configuration/master.html
　　

Configuring the Salt Master
　　
　　The Salt system is amazingly simple and easy to configure, the two components of the Salt system each have a respective configuration file. The salt-master is configured via the master configuration file, and
the salt-minion is configured via the minion configuration file.

See also
example master configuration file
　　The configuration file for the salt-master is located at /etc/salt/master. The available options are as follows:

PRIMARY MASTER CONFIGURATION


INTERFACE
　　Default: 0.0.0.0 (all interfaces)
　　The local interface to bind to.

interface: 192.168.0.1



PUBLISH_PORT
　　Default: 4505
　　The network port to set up the publication interface

publish_port: 4505



USER
　　Default: root
　　The user to run the Salt processes

user: root



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

Too many open files (tcp_listener.cpp:335)
Aborted (core dumped)
　　By default this value will be the one of ulimit -Hn, i.e., the hard limit for max open files.
　　If you wish to set a different value than the default one, uncomment and configure this setting. Remember that this value CANNOT be higher than the hard limit. Raising the hard limit depends on your OS and/or distribution, a good way to find the
limit is to search the internet for(for example):

raise max open files hard limit debian

max_open_files: 100000



WORKER_THREADS
　　Default: 5
　　The number of threads to start for receiving commands and replies from minions. If minions are stalling on replies because you have many minions, raise the worker_threads value.

worker_threads: 5



RET_PORT
　　Default: 4506
　　The port used by the return server, this is the server used by Salt to receive execution returns and command executions.

ret_port: 4506



PIDFILE
　　Default: /var/run/salt-master.pid
　　Specify the location of the master pidfile

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



ROOT_DIR
　　Default: /
　　The system root directory to operate from, change this to make Salt run from an alternative root

root_dir: /



PKI_DIR
　　Default: /etc/salt/pki
　　The directory to store the pki authentication keys.

pki_dir: /etc/salt/pki



CACHEDIR
　　Default: /var/cache/salt
　　The location used to store cache information, particularly the job information for executed salt commands.

cachedir: /var/cache/salt



KEEP_JOBS
　　Default: 24
　　Set the number of hours to keep old job information


JOB_CACHE
　　Default: 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


EXT_JOB_CACHE
　　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



SOCK_DIR
　　Default:: /tmp/salt-unix
　　Set the location to use for creating Unix sockets for master process communication

MASTER SECURITY SETTINGS


OPEN_MODE
　　Default: 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
　　Default: False
　　Enable auto_accept. This setting will automatically accept all incoming public keys from the minions

auto_accept: False



AUTOSIGN_FILE
　　Default not defined
　　If the autosign_file is specified incoming keys specified in the autosign_file will be automatically accepted. Regular expressions as well as globbing can be used. This is insecure!


CLIENT_ACL
　　Default: {}
　　Enable user accounts on the master to execute specific modules. These modules can be expressed as regular expressions

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


MASTER MODULE MANAGEMENT


RUNNER_DIRS
　　Default: []
　　Set additional directories to search for runner modules


CYTHON_ENABLE
　　Default: 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_VERBOSE
　　Default: False
　　state_verbose allows for the data returned from the minion to be more verbose. Normally only states that fail or states that have changes are returned, but setting state_verbose to True will
return all states that were checked

state_verbose: True



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.

state_output: full



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



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
　　Default:: False
　　Set the global failhard flag, this informs all states to stop running states at the moment a single state fails

failhard: False



TEST
　　Default:: 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


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. Example:

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


base:
- /srv/salt



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



PILLAR CONFIGURATION


PILLAR_ROOTS
　　Set the environments and directories used to hold pillar sls data. This configuration is the same as file_roots:
　　Default: base: [/srv/pillar]

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


base:
- /srv/pillar



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 are: hiera, cmd_yaml. By default the ext_pillar
interface is not configured to run.
　　Default:: None

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

　　There are additional details at Pillars

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


ORDER_MASTERS
　　Default: 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
　　Default: 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


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!


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


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 and bl*.domain.com'
group2: 'G@os:Debian and foo.domain.com'


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. Remote logging works best when configured to use rsyslogd(8) (e.g.: file:///dev/log),
with rsyslogd(8) configured for network logging. The format for remote addresses is: <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>. 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. One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.

log_level: warning



LOG_LEVEL_LOGFILE
　　Default: warning
　　The level of messages to send to the log file. One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.

log_level_logfile: warning



LOG_DATEFMT
　　Default: %H:%M:%S
　　The date and time format used in console log messages. Allowed date/time formatting can be seen onhttp://docs.python.org/library/time.html#time.strftime

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. Allowed date/time formatting can be seen onhttp://docs.python.org/library/time.html#time.strftime

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



LOG_FMT_CONSOLE
　　Default: [%(levelname)-8s] %(message)s
　　The format of the console logging messages. Allowed formatting options can be seen onhttp://docs.python.org/library/logging.html#logrecord-attributes

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. Allowed formatting options can be seen onhttp://docs.python.org/library/logging.html#logrecord-attributes

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. The example sets the main salt library at the 'warning' level, but sets 'salt.modules' to log at the 'debug' level:

log_granular_levels:
'salt': 'warning',
'salt.modules': 'debug'

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.d is relative to the directory of the master configuration file.