neulab/tldr huggingface dataset:
• Targeting minions using pillar data - The user can configure certain information in the Pillar data and then use it to identify minions
Master configuration example, to match the event and react:
reactor: - 'napalm/syslog/*/BGP_PREFIX_THRESH_EXCEEDED/*': - salt://increase_prefix_limit_on_thresh_exceeded.sls
Which matches the events having the error code BGP_PREFIX_THRESH_EXCEEDED from any network operating system, from any host and reacts, executing the increase_prefix_limit_on_thresh_exceeded.sls reactor, found under one of the file_roots paths.
Reactor example:
increase_prefix_limit_on_thresh_exceeded: local.net.load_template: - tgt: "hostname:{{ data['host'] }}" - tgt_type: grain - kwarg: template_name: salt://increase_prefix_limit.jinja openconfig_structure: {{ data['open_config'] }}
The reactor in the example increases the BGP prefix limit when triggered by an event as above. The minion is matched using the host field from the data (which is the body of the event), compared to the hostname grain field. When the event occurs, the reactor will execute the net.load_template function, sending as arguments the template salt://increase_prefix_limit.jinja defined by the user in their environment and the complete OpenConfig object under the variable name openconfig_structure. Inside the Jinja template, the user can process the object from openconfig_structure and define the bussiness logic as required.
salt.engines.napalm_syslog.start(transport='zmq', address='0.0.0.0', port=49017, auth_address='0.0.0.0', auth_port=49018, disable_security=False, certificate=None, os_whitelist=None, os_blacklist=None, error_whitelist=None, error_blacklist=None, host_whitelist=None, host_blacklist=None) Listen to napalm-logs and publish events into the Salt event bus.
transport: zmq Choose the desired transport.
NOTE: Currently zmq is the only valid option.
address: 0.0.0.0 The address of the publisher, as configured on napalm-logs.
port: 49017 The port of the publisher, as configured on napalm-logs.
auth_address: 0.0.0.0 The address used for authentication when security is not disabled.
auth_port: 49018 Port used for authentication.
disable_security: False Trust unencrypted messages.  Strongly discouraged in production.
certificate: None Absolute path to the SSL certificate.
os_whitelist: None List of operating systems allowed. By default everything is allowed.
os_blacklist: None List of operating system to be ignored. Nothing ignored by default.
error_whitelist: None List of errors allowed.
error_blacklist: None List of errors ignored.
host_whitelist: None List of hosts or IPs to be allowed.
host_blacklist: None List of hosts of IPs to be ignored.
salt.engines.reactor Setup Reactor
Example Config in Master or Minion config
engines: - reactor: refresh_interval: 60 worker_threads: 10 worker_hwm: 10000
reactor: - 'salt/cloud/*/destroyed': - /srv/reactor/destroy/*.sls
salt.engines.reactor.start(refresh_interval=None, worker_threads=None, worker_hwm=None)
salt.engines.redis_sentinel An engine that reads messages from the redis sentinel pubsub and sends reactor events based on the channels they are subscribed to.
engines: - redis_sentinel: hosts: matching: 'board*' port: 26379 interface: eth2 channels: - '+switch-master' - '+odown' - '-odown'
depends redis
class salt.engines.redis_sentinel.Listener(host=None, port=None, channels=None, tag=None)
work(item)
salt.engines.redis_sentinel.start(hosts, channels, tag=None)
salt.engines.script Send events based on a script's stdout
engines: - script: cmd: /some/script.py -a 1 -b 2 output: json interval: 5
Script engine configs: cmd: Script or command to execute output: Any available saltstack deserializer interval: How often in seconds to execute the command
salt.engines.script.start(cmd, output='json', interval=1) Parse stdout of a command and generate an event
The script engine will scrap stdout of the given script and generate an event based on the presence of the 'tag' key and its value.
If there is a data obj available, that will also be fired along with the tag.
Given the following json output from a script:
{ "tag" : "lots/of/tacos", "data" : { "toppings" : "cilantro" } }
This will fire the event 'lots/of/tacos' on the event bus with the data obj as is.
• cmd -- The command to execute
• output -- How to deserialize stdout of the script
• interval -- How often to execute the script
salt.engines.slack An engine that reads messages from Slack and can act on them
depends slackclient Python module
IMPORTANT: This engine requires a bot user. To create a bot user, first go to the Custom Integrations page in your Slack Workspace. Copy and paste the following URL, and replace myworkspace with the proper value for your workspace:
https://myworkspace.slack.com/apps/manage/custom-integrations
Next, click on the Bots integration and request installation. Once approved by an admin, you will be able to proceed with adding the bot user.  Once the bot user has been added, you can configure it by adding an avatar, setting the display name, etc. You will also at this time have access to your API token, which will be needed to configure this engine.
Finally, add this bot user to a channel by switching to the channel and using /invite @mybotuser. Keep in mind that this engine will process messages from each channel in which the bot is a member, so it is recommended to narrowly define the commands which can be executed, and the Slack users which are allowed to run commands.
This engine has two boolean configuration parameters that toggle specific features (both default to False):
1. control - If set to True, then any message which starts with the trigger string (which defaults to ! and can be overridden by setting the trigger option in the engine configuration) will be interpreted as a Salt CLI command and the engine will attempt to run it. The permissions defined in the various groups will determine if the Slack user is allowed to run the command. The targets and default_target options can be used to set targets for a given command, but the engine can also read the following two keyword arguments:
• target - The target expression to use for the command
• tgt_type - The match type, can be one of glob, list, pcre, grain, grain_pcre, pillar, nodegroup, range, ipcidr, or compound. The default value is glob.
!test.ping target=* !state.apply foo target=os:CentOS tgt_type=grain !pkg.version mypkg target=role:database tgt_type=pillar
2. fire_all - If set to True, all messages which are not prefixed with the trigger string will fired as events onto Salt's ref:event bus <event-system>. The tag for these veents will be prefixed with the string specified by the tag config option (default: salt/engines/slack).
The groups_pillar_name config option can be used to pull group configuration from the specified pillar key.
NOTE: In order to use groups_pillar_name, the engine must be running as a minion running on the master, so that the Caller client can be used to retrieve that minions pillar data, because the master process does not have pillar data.
Configuration Examples Changed in version 2017.7.0: Access control group support added
This example uses a single group called default. In addition, other groups are being loaded from pillar data. The group names do not have any significance, it is the users and commands defined within them that are used to determine whether the Slack user has permission to run the desired command.
engines: - slack: token: 'xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx' control: True fire_all: False groups_pillar_name: 'slack_engine:groups_pillar' groups: default: users: - '*' commands: - test.ping - cmd.run - list_jobs - list_commands aliases: list_jobs: cmd: jobs.list_jobs list_commands: cmd: 'pillar.get salt:engines:slack:valid_commands target=saltmaster tgt_type=list' default_target: target: saltmaster tgt_type: glob targets: test.ping: target: '*' tgt_type: glob cmd.run: target: saltmaster tgt_type: list
This example shows multiple groups applying to different users, with all users having access to run test.ping. Keep in mind that when using *, the value must be quoted, or else PyYAML will fail to load the configuration.
engines: - slack: groups_pillar: slack_engine_pillar token: 'xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx' control: True fire_all: True tag: salt/engines/slack groups_pillar_name: 'slack_engine:groups_pillar' groups: default: users: - '*' commands: - test.ping aliases: list_jobs: cmd: jobs.list_jobs list_commands: cmd: 'pillar.get salt:engines:slack:valid_commands target=saltmaster tgt_type=list' gods: users: - garethgreenaway commands: - '*'
class salt.engines.slack.SlackClient(token)
can_user_run(user, command, groups) Break out the permissions into the following:
Check whether a user is in any group, including whether a group has the '*' membership
• user (str) -- The username being checked against
• command (str) -- The command that is being invoked (e.g. test.ping)
• groups (dict) -- the dictionary with groups permissions structure.
Returns On a successful permitting match, returns 2-element tuple that contains the name of the group that successfully matched, and a dictionary containing the configuration of the group so it can be referenced.
On failure it returns an empty tuple
commandline_to_list(cmdline_str, trigger_string) cmdline_str is the string of the command line trigger_string is the trigger string, to be removed
control_message_target(slack_user_name, text, loaded_groups, trigger_string) Returns a tuple of (target, cmdline,) for the response
Raises IndexError if a user can't be looked up from all_slack_users
Returns (False, False) if the user doesn't have permission
These are returned together because the commandline and the targeting interact with the group config (specifically aliases and targeting configuration) so taking care of them together works out.
The cmdline that is returned is the actual list that should be processed by salt, and not the alias.
fire(tag, msg) This replaces a function in main called 'fire'
It fires an event into the salt bus.
format_return_text(data, function, **kwargs) Print out YAML using the block mode
generate_triggered_messages(token, trigger_string, groups, groups_pillar_name) slack_token = string trigger_string = string input_valid_users = set input_valid_commands = set
When the trigger_string prefixes the message text, yields a dictionary of:
{ 'message_data': m_data, 'cmdline': cmdline_list, # this is a list 'channel': channel, 'user': m_data['user'], 'slack_client': sc }
else yields {'message_data': m_data} and the caller can handle that
When encountering an error (e.g. invalid message), yields {}, the caller can proceed to the next message
When the websocket being read from has given up all its messages, yields {'done': True} to indicate that the caller has read all of the relevant data for now, and should continue its own processing and check back for more data later.
This relies on the caller sleeping between checks, otherwise this could flood
get_config_groups(groups_conf, groups_pillar_name) get info from groups in config, and from the named pillar
todo: add specification for the minion to use to recover pillar
get_jobs_from_runner(outstanding_jids) Given a list of job_ids, return a dictionary of those job_ids that have completed and their results.
Query the salt event bus via the jobs runner. jobs.list_job will show a job in progress, jobs.lookup_jid will return a job that has completed.
returns a dictionary of job id: result
get_slack_channels(token) Get all channel names from Slack
get_slack_users(token) Get all users from Slack
get_target(permitted_group, cmdline, alias_cmdline) When we are permitted to run a command on a target, look to see what the default targeting is for that group, and for that specific command (if provided).
It's possible for None or False to be the result of either, which means that it's expected that the caller provide a specific target.
If no configured target is provided, the command line will be parsed for target=foo and tgt_type=bar
Test for this:
h = {'aliases': {}, 'commands': {'cmd.run', 'pillar.get'}, 'default_target': {'target': '*', 'tgt_type': 'glob'}, 'targets': {'pillar.get': {'target': 'you_momma', 'tgt_type': 'list'}}, 'users': {'dmangot', 'jmickle', 'pcn'}} f = {'aliases': {}, 'commands': {'cmd.run', 'pillar.get'}, 'default_target': {}, 'targets': {},'users': {'dmangot', 'jmickle', 'pcn'}}
g = {'aliases': {}, 'commands': {'cmd.run', 'pillar.get'}, 'default_target': {'target': '*', 'tgt_type': 'glob'}, 'targets': {}, 'users': {'dmangot', 'jmickle', 'pcn'}}
Run each of them through get_configured_target(('foo', f), 'pillar.get') and confirm a valid target
message_text(m_data) Raises ValueError if a value doesn't work out, and TypeError if this isn't a message type
parse_args_and_kwargs(cmdline) cmdline: list
returns tuple of: args (list), kwargs (dict)
run_command_async(msg)
• message_generator (generator of dict) -- Generates messages from slack that should be run
• fire_all (bool) -- Whether to also fire messages to the event bus
• tag (str) -- The tag to send to use to send to the event bus
• interval (int) -- time to wait between ending a loop and beginning the next
run_commands_from_slack_async(message_generator, fire_all, tag, control, interval=1) Pull any pending messages from the message_generator, sending each one to either the event bus, the command_async or both, depending on the values of fire_all and command
salt.engines.slack.start(token, control=False, trigger='!', groups=None, groups_pillar_name=None, fire_all=False, tag='salt/engines/slack') Listen to slack events and forward them to salt, new version
salt.engines.sqs_events An engine that continuously reads messages from SQS and fires them as events.
Note that long polling is utilized to avoid excessive CPU usage.
depends boto
Configuration This engine can be run on the master or on a minion.
Example Config:
sqs.keyid: GKTADJGHEIQSXMKKRBJ08H sqs.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs sqs.message_format: json
Explicit sqs credentials are accepted but this engine can also utilize IAM roles assigned to the instance through Instance Profiles. Dynamic credentials are then automatically obtained from AWS API and no further configuration is necessary. More Information available at:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
If IAM roles are not (or for boto version < 2.5.1) used you need to specify them either in a pillar or in the config file of the master or minion, as appropriate:
To deserialize the message from json:
sqs.message_format: json
It's also possible to specify key, keyid and region via a profile:
sqs.keyid: GKTADJGHEIQSXMKKRBJ08H sqs.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
A region may also be specified in the configuration:
sqs.region: us-east-1
If a region is not specified, the default is us-east-1.
myprofile: keyid: GKTADJGHEIQSXMKKRBJ08H key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs region: us-east-1
Additionally you can define cross account sqs:
engines: - sqs_events: queue: prod owner_acct_id: 111111111111
salt.engines.sqs_events.start(queue, profile=None, tag='salt/engine/sqs', owner_acct_id=None) Listen to sqs and fire message on event bus
salt.engines.stalekey An engine that uses presence detection to keep track of which minions have been recently connected and remove their keys if they have not been connected for a certain period of time.
Requires that the minion_data_cache option be enabled.
configuration Example configuration:
engines: - stalekey: interval: 3600 expire: 86400
salt.engines.stalekey.start(interval=3600, expire=604800) Start the engine
salt.engines.test A simple test engine, not intended for real use but as an example
salt.engines.test.event_bus_context(opts)
salt.engines.test.start() Listen to events and write them to a log file
salt.engines.thorium Manage the Thorium complex event reaction system
salt.engines.thorium.start(grains=False, grain_keys=None, pillar=False, pillar_keys=None) Execute the Thorium runtime
salt.engines.webhook Send events from webhook api
salt.engines.webhook.start(address=None, port=5000, ssl_crt=None, ssl_key=None) Api to listen for webhooks to send to the reactor.
Implement the webhook behavior in an engine.  rest_cherrypy Webhook docs
Unlike the rest_cherrypy Webhook, this is only an unauthenticated webhook endpoint.  If an authenticated webhook endpoint is needed, use the salt-api webhook which runs on the master and authenticates through eauth.
WARNING: Unauthenticated endpoint
This engine sends webhook calls to the event stream.  If the engine is running on a minion with file_client: local the event is sent to the minion event stream.  Otherwise it is sent to the master event stream.
engines: - webhook: {}
engines: - webhook: port: 8000 address: 10.128.1.145 ssl_crt: /etc/pki/tls/certs/localhost.crt ssl_key: /etc/pki/tls/certs/localhost.key
executors modules ┌─────────────────────┬─────────────────────────────┐ │direct_call          │ Direct call executor module │ ├─────────────────────┼─────────────────────────────┤ │docker               │ Docker executor module      │ ├─────────────────────┼─────────────────────────────┤ │splay                │ Splay function calls across │ │                     │ targeted minions            │ ├─────────────────────┼─────────────────────────────┤ │sudo                 │ Sudo executor module        │ ├─────────────────────┼─────────────────────────────┤ │transactional_update │ Transactional executor      │ │                     │ module                      │ └─────────────────────┴─────────────────────────────┘
salt.executors.direct_call Direct call executor module
salt.executors.direct_call.execute(opts, data, func, args, kwargs) Directly calls the given function with arguments
salt.executors.docker Docker executor module
Used with the docker proxy minion.
salt.executors.docker.allow_missing_func(function) Allow all calls to be passed through to docker container.
The docker call will use direct_call, which will return back if the module was unable to be run.
salt.executors.docker.execute(opts, data, func, args, kwargs) Directly calls the given function with arguments
salt.executors.splay Splay function calls across targeted minions
salt.executors.splay.execute(opts, data, func, args, kwargs) Splay a salt function call execution time across minions over a number of seconds (default: 300)
NOTE: You probably want to use --async here and look up the job results later.  If you're dead set on getting the output from the CLI command, then make sure to set the timeout (with the -t flag) to something greater than the splaytime (max splaytime + time to execute job).  Otherwise, it's very likely that the cli will time out before the job returns.
# With default splaytime salt --async --module-executors='[splay, direct_call]' '*' pkg.install cowsay version=3.03-8.el6
# With specified splaytime (5 minutes) and timeout with 10 second buffer salt -t 310 --module-executors='[splay, direct_call]' --executor-opts='{splaytime: 300}' '*' pkg.version cowsay
salt.executors.sudo Sudo executor module
salt.executors.sudo.execute(opts, data, func, args, kwargs) Allow for the calling of execution modules via sudo.
This module is invoked by the minion if the sudo_user minion config is present.
Example minion config:
sudo_user: saltdev
Once this setting is made, any execution module call done by the minion will be run under sudo -u <sudo_user> salt-call.  For example, with the above minion config,
salt sudo_minion cmd.run 'cat /etc/sudoers'
sudo -u saltdev salt-call cmd.run 'cat /etc/sudoers'
being run on sudo_minion.
salt.executors.transactional_update module Transactional executor module
New in version 3004.
salt.executors.transactional_update.execute(opts, data, func, args, kwargs) Delegate into transactional_update module
The transactional_update module support the execution of functions inside a transaction, as support apply a state (via apply, sls, single or highstate).
This execution module can be used to route some Salt modules and functions to be executed inside the transaction snapshot.
Add this executor in the minion configuration file:
module_executors: - transactional_update - direct_call
Or use the command line parameter:
salt-call --module-executors='[transactional_update, direct_call]' test.version
You can also schedule a reboot if needed:
salt-call --module-executors='[transactional_update]' state.sls stuff activate_transaction=True
There are some configuration parameters supported:
# Replace the list of default modules that all the functions # are delegated to `transactional_update.call()` delegated_modules: [cmd, pkg]
# Replace the list of default functions that are delegated to # `transactional_update.call()` delegated_functions: [pip.install]
# Expand the default list of modules add_delegated_modules: [ansible]
# Expand the default list of functions add_delegated_functions: [file.copy]
fileserver modules ┌─────────┬────────────────────────────┐ │azurefs  │ The backend for serving    │ │         │ files from the Azure blob  │ │         │ storage service.           │ ├─────────┼────────────────────────────┤ │gitfs    │ Git Fileserver Backend     │ ├─────────┼────────────────────────────┤ │hgfs     │ Mercurial Fileserver       │ │         │ Backend                    │ ├─────────┼────────────────────────────┤ │minionfs │ Fileserver backend which   │ │         │ serves files pushed to the │ │         │ Master                     │ ├─────────┼────────────────────────────┤ │roots    │ The default file server    │ │         │ backend                    │ ├─────────┼────────────────────────────┤ │s3fs     │ Amazon S3 Fileserver       │ │         │ Backend                    │ ├─────────┼────────────────────────────┤ │svnfs    │ Subversion Fileserver      │ │         │ Backend                    │ └─────────┴────────────────────────────┘
salt.fileserver.azurefs The backend for serving files from the Azure blob storage service.
To enable, add azurefs to the fileserver_backend option in the Master config file.
fileserver_backend: - azurefs
Starting in Salt 2018.3.0, this fileserver requires the standalone Azure Storage SDK for Python. Theoretically any version >= v0.20.0 should work, but it was developed against the v0.33.0 version.
Each storage container will be mapped to an environment. By default, containers will be mapped to the base environment. You can override this behavior with the saltenv configuration option. You can have an unlimited number of storage containers, and can have a storage container serve multiple environments, or have multiple storage containers mapped to the same environment. Normal first-found rules apply, and storage containers are searched in the order they are defined.
You must have either an account_key or a sas_token defined for each container, if it is private. If you use a sas_token, it must have READ and LIST permissions.
azurefs: - account_name: my_storage account_key: 'fNH9cRp0+qVIVYZ+5rnZAhHc9ycOUcJnHtzpfOr0W0sxrtL2KVLuMe1xDfLwmfed+JJInZaEdWVCPHD4d/oqeA==' container_name: my_container - account_name: my_storage sas_token: 'ss=b&sp=&sv=2015-07-08&sig=cohxXabx8FQdXsSEHyUXMjsSfNH2tZ2OB97Ou44pkRE%3D&srt=co&se=2017-04-18T21%3A38%3A01Z' container_name: my_dev_container saltenv: dev - account_name: my_storage container_name: my_public_container
NOTE: Do not include the leading ? for sas_token if generated from the web
salt.fileserver.gitfs Git Fileserver Backend
With this backend, branches and tags in a remote git repository are exposed to salt as different environments.
To enable, add gitfs to the fileserver_backend option in the Master config file.
The Git fileserver backend supports both pygit2 and GitPython, to provide the Python interface to git. If both are present, the order of preference for which one will be chosen is the same as the order in which they were listed: pygit2, then GitPython.
An optional master config parameter (gitfs_provider) can be used to specify which provider should be used, in the event that compatible versions of both pygit2 and GitPython are installed.
More detailed information on how to use GitFS can be found in the GitFS Walkthrough.
NOTE: Minimum requirements
To use pygit2 for GitFS requires a minimum pygit2 version of 0.20.3. pygit2 0.20.3 requires libgit2 0.20.0. pygit2 and libgit2 are developed alongside one another, so it is recommended to keep them both at the same major release to avoid unexpected behavior. For example, pygit2 0.21.x requires libgit2 0.21.x, pygit2 0.22.x will require libgit2 0.22.x, etc.
To use GitPython for GitFS requires a minimum GitPython version of 0.3.0, as well as the git CLI utility. Instructions for installing GitPython can be found here.
To clear stale refs the git CLI utility must also be installed.
salt.fileserver.hgfs Mercurial Fileserver Backend
To enable, add hgfs to the fileserver_backend option in the Master config file.
fileserver_backend: - hgfs
NOTE: hg also works here. Prior to the 2018.3.0 release, only hg would work.
After enabling this backend, branches, bookmarks, and tags in a remote mercurial repository are exposed to salt as different environments. This feature is managed by the fileserver_backend option in the salt master config file.
This fileserver has an additional option hgfs_branch_method that will set the desired branch method. Possible values are: branches, bookmarks, or mixed. If using branches or mixed, the default branch will be mapped to base.
Changed in version 2014.1.0: The hgfs_base master config parameter was added, allowing for a branch other than default to be used for the base environment, and allowing for a base environment to be specified when using an hgfs_branch_method of bookmarks.
• mercurial
• python bindings for mercurial (python-hglib)
salt.fileserver.minionfs Fileserver backend which serves files pushed to the Master
The cp.push function allows Minions to push files up to the Master. Using this backend, these pushed files are exposed to other Minions via the Salt fileserver.
To enable minionfs, file_recv needs to be set to True in the master config file (otherwise cp.push will not be allowed to push files to the Master), and minionfs must be added to the fileserver_backends list.
fileserver_backend: - minionfs
Other minionfs settings include: minionfs_whitelist, minionfs_blacklist, minionfs_mountpoint, and minionfs_env.
SEE ALSO: tutorial-minionfs
salt.fileserver.roots The default file server backend
This fileserver backend serves files from the Master's local filesystem. If fileserver_backend is not defined in the Master config file, then this backend is enabled by default. If it is defined then roots must be in the fileserver_backend list to enable this backend.
fileserver_backend: - roots
Fileserver environments are defined using the file_roots configuration option.
salt.fileserver.s3fs Amazon S3 Fileserver Backend
New in version 0.16.0.
This backend exposes directories in S3 buckets as Salt environments. To enable this backend, add s3fs to the fileserver_backend option in the Master config file.
fileserver_backend: - s3fs
S3 credentials must also be set in the master config file:
s3.keyid: GKTADJGHEIQSXMKKRBJ08H s3.key: askdjghsdfjkghWupUjasdflkdfklgjsdfjajkghs
Alternatively, if on EC2 these credentials can be automatically loaded from instance metadata.
This fileserver supports two modes of operation for the buckets:
1. A single bucket per environment
s3.buckets: production: - bucket1 - bucket2 staging: - bucket3 - bucket4
2. Multiple environments per bucket
s3.buckets: - bucket1 - bucket2 - bucket3 - bucket4
Note that bucket names must be all lowercase both in the AWS console and in Salt, otherwise you may encounter SignatureDoesNotMatch errors.
A multiple-environment bucket must adhere to the following root directory structure:
s3://<bucket name>/<environment>/<files>
NOTE: This fileserver back-end requires the use of the MD5 hashing algorithm.  MD5 may not be compliant with all security policies.
NOTE: This fileserver back-end is only compatible with MD5 ETag hashes in the S3 metadata. This means that you must use SSE-S3 or plaintext for bucket encryption, and that you must not use multipart upload when uploading to your bucket. More information here: https://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonResponseHeaders.html
Objects without an MD5 ETag will be fetched on every fileserver update.
If you deal with objects greater than 8MB, then you should use the following AWS CLI config to avoid mutipart upload:
s3 = multipart_threshold = 1024MB
More info here: https://docs.aws.amazon.com/cli/latest/topic/s3-config.html
salt.fileserver.svnfs Subversion Fileserver Backend
After enabling this backend, branches and tags in a remote subversion repository are exposed to salt as different environments. To enable this backend, add svnfs to the fileserver_backend option in the Master config file.
fileserver_backend: - svnfs
NOTE: svn also works here. Prior to the 2018.3.0 release, only svn would work.
This backend assumes a standard svn layout with directories for branches, tags, and trunk, at the repository root.
• subversion
• pysvn
Changed in version 2014.7.0: The paths to the trunk, branches, and tags have been made configurable, via the config options svnfs_trunk, svnfs_branches, and svnfs_tags.  svnfs_mountpoint was also added. Finally, support for per-remote configuration parameters was added. See the documentation for more information.
salt.grains.chronos Generate chronos proxy minion grains.
New in version 2015.8.2.
salt.grains.chronos.kernel()
salt.grains.chronos.os()
salt.grains.chronos.os_data()
salt.grains.chronos.os_family()
salt.grains.cimc Generate baseline proxy minion grains for cimc hosts.
salt.grains.cimc.cimc(proxy=None)
salt.grains.core The static grains, these are the core, or built in grains.
When grains are loaded they are not loaded in the same way that modules are loaded, grain functions are detected and executed, the functions MUST return a dict which will be applied to the main grains dict. This module will always be executed first, so that any grains loaded here in the core module can be overwritten just by returning dict keys with the same value as those returned here
salt.grains.core.append_domain() Return append_domain if set
salt.grains.core.cwd() Current working directory
salt.grains.core.default_gateway() Populates grains which describe whether a server has a default gateway configured or not. Uses ip -4 route show and ip -6 route show and greps for a default at the beginning of any line. Assuming the standard default via <ip> format for default gateways, it will also parse out the ip address of the default gateway, and put it in ip4_gw or ip6_gw.
If the ip command is unavailable, no grains will be populated.
Currently does not support multiple default gateways. The grains will be set to the first default gateway found.
List of grains: ip4_gw: True  # ip/True/False if default ipv4 gateway ip6_gw: True  # ip/True/False if default ipv6 gateway ip_gw: True   # True if either of the above is True, False otherwise
salt.grains.core.dns() Parse the resolver configuration file New in version 2016.3.0.
salt.grains.core.fqdns() Return all known FQDNs for the system by enumerating all interfaces and then trying to reverse resolve them (excluding 'lo' interface).  To disable the fqdns grain, set enable_fqdns_grains: False in the minion configuration file.
salt.grains.core.get_machine_id() Provide the machine-id for machine/virtualization combination
salt.grains.core.get_master() Provides the minion with the name of its master.  This is useful in states to target other services running on the master.
salt.grains.core.get_server_id() Provides an integer based on the FQDN of a machine.  Useful as server-id in MySQL replication or anywhere else you'll need an ID like this.
salt.grains.core.hostname() Return fqdn, hostname, domainname
NOTE: On Windows the domain grain may refer to the dns entry for the host instead of the Windows domain to which the host is joined. It may also be empty if not a part of any domain. Refer to the windowsdomain grain instead
salt.grains.core.hwaddr_interfaces() Provide a dict of the connected interfaces and their hw addresses (Mac Address)
salt.grains.core.id_() Return the id
salt.grains.core.ip4_interfaces() Provide a dict of the connected interfaces and their ip4 addresses The addresses will be passed as a list for each interface
salt.grains.core.ip6_interfaces() Provide a dict of the connected interfaces and their ip6 addresses The addresses will be passed as a list for each interface
salt.grains.core.ip_fqdn() Return ip address and FQDN grains
salt.grains.core.ip_interfaces() Provide a dict of the connected interfaces and their ip addresses The addresses will be passed as a list for each interface
salt.grains.core.kernelparams() Return the kernel boot parameters
salt.grains.core.locale_info()
Provides defaultlanguage defaultencoding
salt.grains.core.os_data() Return grains pertaining to the operating system
salt.grains.core.path() Return the path
salt.grains.core.pythonexecutable() Return the python executable in use
salt.grains.core.pythonpath() Return the Python path
salt.grains.core.pythonversion() Return the Python version
salt.grains.core.saltpath() Return the path of the salt module
salt.grains.core.saltversion() Return the version of salt
salt.grains.core.saltversioninfo() Return the version_info of salt New in version 0.17.0.
salt.grains.core.zmqversion() Return the zeromq version
salt.grains.disks Detect disks
salt.grains.disks.disks() Return list of disk devices
salt.grains.esxi Generate baseline proxy minion grains for ESXi hosts.
New in version 2015.8.4.
salt.grains.esxi.esxi()
salt.grains.esxi.kernel()
salt.grains.esxi.os()
salt.grains.esxi.os_family()
salt.grains.extra salt.grains.extra.config() Return the grains set in the grains file
salt.grains.extra.shell() Return the default shell to use on this system
salt.grains.extra.transactional() Determine if the system is transactional.
salt.grains.extra.uefi() Populate UEFI grains.
salt.grains.fibre_channel Grains for Fibre Channel WWN's. On Windows this runs a PowerShell command that queries WMI to get the Fibre Channel WWN's available.
To enable these grains set fibre_channel_grains: True in the minion config.
salt.grains.fibre_channel.fibre_channel_wwns() Return list of fiber channel HBA WWNs
salt.grains.fx2 Generate baseline proxy minion grains for Dell FX2 chassis.  The challenge is that most of Salt isn't bootstrapped yet, so we need to repeat a bunch of things that would normally happen in proxy/fx2.py--just enough to get data from the chassis to include in grains.
salt.grains.fx2.fx2()
salt.grains.fx2.kernel()
salt.grains.fx2.location()
salt.grains.fx2.os_data()
salt.grains.fx2.os_family()
salt.grains.iscsi Grains for iSCSI Qualified Names (IQN).
To enable these grains set iscsi_grains: True in the minion config.
salt.grains.iscsi.iscsi_iqn() Return iSCSI IQN
salt.grains.junos Grains for junos.  NOTE this is a little complicated--junos can only be accessed via salt-proxy-minion. Thus, some grains make sense to get them from the minion (PYTHONPATH), but others don't (ip_interfaces)
salt.grains.junos.defaults()
salt.grains.junos.facts(proxy=None)
salt.grains.junos.os_family()
salt.grains.lvm Detect LVM Volumes
salt.grains.lvm.lvm() Return list of LVM devices
salt.grains.marathon Generate marathon proxy minion grains.
salt.grains.marathon.kernel()
salt.grains.marathon.marathon()
salt.grains.marathon.os()
salt.grains.marathon.os_data()
salt.grains.marathon.os_family()
salt.grains.mdadm Detect MDADM RAIDs
salt.grains.mdadm.mdadm() Return list of mdadm devices
salt.grains.mdata SmartOS Metadata grain provider
maintainer Jorge Schrauwen <sjorge@blackdot.be>
depends salt.utils, salt.module.cmdmod
platform SmartOS
salt.grains.mdata.mdata() Provide grains from the SmartOS metadata
salt.grains.metadata Grains from cloud metadata servers at 169.254.169.254
To enable these grains that pull from the http://169.254.169.254/latest metadata server set metadata_server_grains: True in the minion config.
salt.grains.metadata.metadata()
salt.grains.minion_process Set grains describing the minion process.
salt.grains.minion_process.grains() Return the grains dictionary
salt.grains.napalm NAPALM Grains codeauthor Mircea Ulinic <ping@mirceaulinic.net>
depends napalm
platform unix
Dependencies • NAPALM proxy module
salt.grains.napalm.getos(proxy=None) Returns the Operating System name running on the network device.
Example: junos, iosxr, eos, ios etc.
CLI Example - select all network devices running JunOS:
salt -G 'os:junos' test.ping
salt.grains.napalm.host(proxy=None) This grain is set by the NAPALM grain module only when running in a proxy minion.  When Salt is installed directly on the network device, thus running a regular minion, the host grain provides the physical hostname of the network device, as it would be on an ordinary minion server.  When running in a proxy minion, host points to the value configured in the pillar: NAPALM proxy module.
NOTE: The diference between host and hostname is that host provides the physical location - either domain name or IP address, while hostname provides the hostname as configured on the device. They are not necessarily the same.
salt 'device*' grains.get host
device1: ip-172-31-13-136.us-east-2.compute.internal device2: ip-172-31-11-193.us-east-2.compute.internal device3: ip-172-31-2-181.us-east-2.compute.internal
salt.grains.napalm.host_dns(proxy=None) Return the DNS information of the host.  This grain is a dictionary having two keys:
• A
• AAAA
NOTE: This grain is disabled by default, as the proxy startup may be slower when the lookup fails.  The user can enable it using the napalm_host_dns_grain option (in the pillar or proxy configuration file):
napalm_host_dns_grain: true
salt 'device*' grains.get host_dns
device1: A: - 172.31.9.153 AAAA: - fd52:188c:c068::1 device2: A: - 172.31.46.249 AAAA: - fdca:3b17:31ab::17 device3: A: - 172.31.8.167 AAAA: - fd0f:9fd6:5fab::1
salt.grains.napalm.hostname(proxy=None) Return the hostname as configured on the network device.
salt 'device*' grains.get hostname
device1: edge01.yyz01 device2: edge01.bjm01 device3: edge01.flw01
salt.grains.napalm.interfaces(proxy=None) Returns the complete interfaces list of the network device.
Example: ['lc-0/0/0', 'pfe-0/0/0', 'xe-1/3/0', 'lo0', 'irb', 'demux0', 'fxp0']
CLI Example - select all devices that have a certain interface, e.g.: xe-1/1/1:
salt -G 'interfaces:xe-1/1/1' test.ping
edge01.yyz01: True edge01.maa01: True edge01.syd01: True edge01.del01: True edge01.dus01: True edge01.kix01: True
salt.grains.napalm.model(proxy=None) Returns the network device chassis model.
Example: MX480, ASR-9904-AC etc.
CLI Example - select all Juniper MX480 routers and execute traceroute to 8.8.8.8:
salt -G 'model:MX480' net.traceroute 8.8.8.8
salt.grains.napalm.optional_args(proxy=None) Return the connection optional args.
NOTE: Sensible data will not be returned.
CLI Example - select all devices connecting via port 1234:
salt -G 'optional_args:port:1234' test.ping
device1: True device2: True
salt.grains.napalm.serial(proxy=None) Returns the chassis serial number.
Example: FOX1234W00F
CLI Example - select all devices whose serial number begins with FOX and display the serial number value:
salt -G 'serial:FOX*' grains.get serial
edge01.icn01: FOXW00F001 edge01.del01: FOXW00F002 edge01.yyz01: FOXW00F003 edge01.mrs01: FOXW00F004
salt.grains.napalm.uptime(proxy=None) Returns the uptime in seconds.
CLI Example - select all devices started/restarted within the last hour:
salt -G 'uptime<3600' test.ping
salt.grains.napalm.username(proxy=None) Return the username.
CLI Example - select all devices using foobar as username for connection:
salt -G 'username:foobar' test.ping
salt.grains.napalm.vendor(proxy=None) Returns the network device vendor.
Example: juniper, cisco, arista etc.
CLI Example - select all devices produced by Cisco and shutdown:
salt -G 'vendor:cisco' net.cli "shut"
salt.grains.napalm.version(proxy=None) Returns the OS version.
Example: 13.3R6.5, 6.0.2 etc.
CLI Example - select all network devices running JunOS 13.3R6.5 and return the model:
salt -G 'os:junos and version:13.3R6.5' grains.get model
edge01.bjm01: MX2000 edge01.sjc01: MX960 edge01.mrs01: MX480 edge01.muc01: MX240
salt.grains.nvme Grains for NVMe Qualified Names (NQN).
To enable these grains set nvme_grains: True in the minion config.
salt.grains.nvme.nvme_nqn() Return NVMe NQN
salt.grains.nxos Grains for Cisco NX-OS minions
For documentation on setting up the nxos proxy minion look in the documentation for salt.proxy.nxos.
salt.grains.nxos.system_information(proxy=None)
salt.grains.opts Simple grain to merge the opts into the grains directly if the grain_opts configuration value is set.
salt.grains.opts.opts() Return the minion configuration settings
salt.grains.panos Generate baseline proxy minion grains for panos hosts.
salt.grains.panos.panos(proxy=None)
salt.grains.pending_reboot Grain that indicates the system is pending a reboot See functions in salt.utils.win_system to see what conditions would indicate a reboot is pending
salt.grains.pending_reboot.pending_reboot() A grain that indicates that a Windows system is pending a reboot.
salt.grains.philips_hue Static grains for the Philips HUE lamps
salt.grains.philips_hue.kernel()
salt.grains.philips_hue.os()
salt.grains.philips_hue.os_family()
salt.grains.philips_hue.product()
salt.grains.philips_hue.vendor()
salt.grains.rest_sample Generate baseline proxy minion grains
salt.grains.rest_sample.kernel()
salt.grains.rest_sample.location()
salt.grains.rest_sample.os()
salt.grains.rest_sample.os_data()
salt.grains.rest_sample.os_family()
salt.grains.rest_sample.proxy_functions(proxy) The loader will execute functions with one argument and pass a reference to the proxymodules LazyLoader object.  However, grains sometimes get called before the LazyLoader object is setup so proxy might be None.
salt.grains.smartos SmartOS grain provider
salt.grains.smartos.smartos() Provide grains for SmartOS
salt.grains.ssh_sample Generate baseline proxy minion grains
salt.grains.ssh_sample.kernel()
salt.grains.ssh_sample.location()
salt.grains.ssh_sample.os_data()
salt.grains.ssh_sample.proxy_functions(proxy) The loader will execute functions with one argument and pass a reference to the proxymodules LazyLoader object.  However, grains sometimes get called before the LazyLoader object is setup so proxy might be None.
salt.grains.zfs ZFS grain provider
depends salt.module.cmdmod
platform illumos,freebsd,linux
salt.grains.zfs.zfs() Provide grains for zfs/zpool
execution modules Virtual modules
salt.modules.group group is a virtual module that is fulfilled by one of the following modules:
┌─────────────────┬─────────────────────────────┐ │Execution Module │ Used for                    │ ├─────────────────┼─────────────────────────────┤ │groupadd         │ Linux, NetBSD, and OpenBSD  │ │                 │ systems using groupadd(8),  │ │                 │ groupdel(8), and            │ │                 │ groupmod(8)                 │ ├─────────────────┼─────────────────────────────┤ │pw_group         │ FreeBSD-based OSes using    │ │                 │ pw(8)                       │ ├─────────────────┼─────────────────────────────┤ │solaris_group    │ Solaris-based OSes using    │ │                 │ groupadd(1M), groupdel(1M), │ │                 │ and groupmod(1M)            │ ├─────────────────┼─────────────────────────────┤ │win_groupadd     │ Windows                     │ └─────────────────┴─────────────────────────────┘
salt.modules.kernelpkg kernelpkg is a virtual module that is fulfilled by one of the following modules:
┌────────────────────┬─────────────────────────────┐ │Execution Module    │ Used for                    │ ├────────────────────┼─────────────────────────────┤ │kernelpkg_linux_apt │ Debian/Ubuntu-based distros │ │                    │ which use apt-get for       │ │                    │ package management          │ ├────────────────────┼─────────────────────────────┤ │kernelpkg_linux_yum │ RedHat-based distros and    │ │                    │ derivatives using yum or    │ │                    │ dnf                         │ └────────────────────┴─────────────────────────────┘
salt.modules.pkg pkg is a virtual module that is fulfilled by one of the following modules:
┌─────────────────┬─────────────────────────────┐ │Execution Module │ Used for                    │ ├─────────────────┼─────────────────────────────┤ │aixpkg           │ AIX OS using installp and   │ │                 │ rpm                         │ └─────────────────┴─────────────────────────────┘
│aptpkg           │ Debian/Ubuntu-based distros │ │                 │ which use apt-get(8) for    │ │                 │ package management          │ ├─────────────────┼─────────────────────────────┤ │mac_brew_pkg     │ Mac OS software management  │ │                 │ using Homebrew              │ ├─────────────────┼─────────────────────────────┤ │ebuildpkg        │ Gentoo-based systems        │ │                 │ (utilizes the portage       │ │                 │ python module as well as    │ │                 │ emerge(1))                  │ ├─────────────────┼─────────────────────────────┤ │freebsdpkg       │ FreeBSD-based OSes using    │ │                 │ pkg_add(1)                  │ ├─────────────────┼─────────────────────────────┤ │openbsdpkg       │ OpenBSD-based OSes using    │ │                 │ pkg_add(1)                  │ ├─────────────────┼─────────────────────────────┤ │pacmanpkg        │ Arch Linux-based distros    │ │                 │ using pacman(8)             │ ├─────────────────┼─────────────────────────────┤ │pkgin            │ NetBSD-based OSes using     │ │                 │ pkgin(1)                    │ ├─────────────────┼─────────────────────────────┤ │pkgng            │ FreeBSD-based OSes using    │ │                 │ pkg(8)                      │ ├─────────────────┼─────────────────────────────┤ │pkgutil          │ Solaris-based OSes using    │ │                 │ OpenCSW's pkgutil(1)        │ ├─────────────────┼─────────────────────────────┤ │solarispkg       │ Solaris-based OSes using    │ │                 │ pkgadd(1M)                  │ ├─────────────────┼─────────────────────────────┤ │solarisipspkg    │ Solaris-based OSes using    │ │                 │ IPS pkg(1)                  │ ├─────────────────┼─────────────────────────────┤ │win_pkg          │ Salt's Windows Package      │ │                 │ Manager                     │ ├─────────────────┼─────────────────────────────┤ │yumpkg           │ RedHat-based distros and    │ │                 │ derivatives using yum(8) or │ │                 │ dnf(8)                      │ ├─────────────────┼─────────────────────────────┤ │zypperpkg        │ SUSE-based distros using    │ │                 │ zypper(8)                   │ └─────────────────┴─────────────────────────────┘
salt.modules.service service is a virtual module that is fulfilled by one of the following modules: