neulab/tldr huggingface dataset:
peer_vpc_id ID of the VPC tp crete VPC peering connection with.  This can be a VPC in another account. Exclusive with peer_vpc_name. String type.
peer_vpc_name Name tag of the VPC tp crete VPC peering connection with. This can only be a VPC the same account. Exclusive with peer_vpc_id.  String type.
conn_name The (optional) name to use for this VPC peering connection. String type.
peer_owner_id ID of the owner of the peer VPC. String type. If this isn't supplied AWS uses your account ID.  Required if peering to a different account.
request a vpc peering connection: boto_vpc.request_vpc_peering_connection: - requester_vpc_id: vpc-4b3522e - peer_vpc_id: vpc-ae83f9ca - conn_name: salt_peering_connection
salt.states.boto_vpc.route_table_absent(name, region=None, key=None, keyid=None, profile=None) Ensure the named route table is absent.
name   Name of the route table.
salt.states.boto_vpc.route_table_present(name, vpc_name=None, vpc_id=None, routes=None, subnet_ids=None, subnet_names=None, tags=None, region=None, key=None, keyid=None, profile=None) Ensure route table with routes exists and is associated to a VPC.
This function requires boto3 to be installed if nat gatewyas are specified.
boto_vpc.route_table_present: - name: my_route_table - vpc_id: vpc-123456 - routes: - destination_cidr_block: 0.0.0.0/0 internet_gateway_name: InternetGateway - destination_cidr_block: 10.10.11.0/24 instance_id: i-123456 - destination_cidr_block: 10.10.12.0/24 interface_id: eni-123456 - destination_cidr_block: 10.10.13.0/24 instance_name: mygatewayserver - subnet_names: - subnet1 - subnet2
vpc_name Name of the VPC with which the route table should be associated.
vpc_id Id of the VPC with which the route table should be associated.  Either vpc_name or vpc_id must be provided.
routes A list of routes.  Each route has a cidr and a target.
subnet_ids A list of subnet ids to associate
subnet_names A list of subnet names to associate
salt.states.boto_vpc.subnet_absent(name=None, subnet_id=None, region=None, key=None, keyid=None, profile=None) Ensure subnet with passed properties is absent.
name   Name of the subnet.
salt.states.boto_vpc.subnet_present(name, cidr_block, vpc_name=None, vpc_id=None, availability_zone=None, tags=None, region=None, key=None, keyid=None, profile=None, route_table_id=None, route_table_name=None, auto_assign_public_ipv4=False) Ensure a subnet exists.
cidr_block The range if IPs for the subnet, in CIDR format. For example: 10.0.0.0/24. Block size must be between /16 and /28 netmask.
vpc_name Name of the VPC in which the subnet should be placed. Either vpc_name or vpc_id must be provided.
vpc_id Id of the VPC in which the subnet should be placed. Either vpc_name or vpc_id must be provided.
availability_zone AZ in which the subnet should be placed.
route_table_id A route table ID to explicitly associate the subnet with. If both route_table_id and route_table_name are specified, route_table_id will take precedence.
route_table_name A route table name to explicitly associate the subnet with. If both route_table_id and route_table_name are specified, route_table_id will take precedence.
salt.states.boto_vpc.vpc_peering_connection_absent(name, conn_id=None, conn_name=None, region=None, key=None, keyid=None, profile=None)
salt.states.boto_vpc.vpc_peering_connection_present(name, requester_vpc_id=None, requester_vpc_name=None, peer_vpc_id=None, peer_vpc_name=None, conn_name=None, peer_owner_id=None, region=None, key=None, keyid=None, profile=None)
peer_vpc_id ID of the VPC tp crete VPC peering connection with. This can be a VPC in another account. Exclusive with peer_vpc_name.
peer_vpc_name Name tag of the VPC tp crete VPC peering connection with. This can only be a VPC in the same account, else resolving it into a vpc ID will fail.  Exclusive with peer_vpc_id.
conn_name The name to use for this VPC peering connection.
ensure peering twixt local vpc and the other guys: boto_vpc.vpc_peering_connection_present: - requester_vpc_name: my_local_vpc - peer_vpc_name: some_other_guys_vpc - conn_name: peering_from_here_to_there - peer_owner_id: 012345654321
salt.states.bower Installation of Bower Packages These states manage the installed packages using Bower.  Note that npm, git and bower must be installed for these states to be available, so bower states should include requisites to pkg.installed states for the packages which provide npm and git (simply npm and git in most cases), and npm.installed state for the package which provides bower.
npm: pkg.installed git: pkg.installed bower: npm.installed require: - pkg: npm - pkg: git
underscore: bower.installed: - dir: /path/to/project - require: - npm: bower
salt.states.bower.bootstrap(name, user=None) Bootstraps a frontend distribution.
Will execute 'bower install' on the specified directory.
user   The user to run Bower with
salt.states.bower.installed(name, dir, pkgs=None, user=None, env=None) Verify that the given package is installed and is at the correct version (if specified).
underscore: bower.installed: - dir: /path/to/project - user: someuser
jquery#2.0: bower.installed: - dir: /path/to/project
name   The package to install
pkgs   A list of packages to install with a single Bower invocation; specifying this argument will ignore the name argument
env    A list of environment variables to be set prior to execution. The format is the same as the cmd.run.  state function.
salt.states.bower.pruned(name, user=None, env=None) New in version 2017.7.0.
Cleans up local bower_components directory.
Will execute 'bower prune' on the specified directory (param: name)
salt.states.bower.removed(name, dir, user=None) Verify that the given package is not installed.
salt.states.btrfs maintainer Alberto Planas <aplanas@suse.com>
salt.states.btrfs.properties(name, device, use_default=False, __dest=None, **properties) Makes sure that a list of properties are set in a subvolume, file or device.
name   Name of the object to change
device Device where the object lives, if None, the device will be in name
use_default If True, this subvolume will be resolved to the default subvolume assigned during the create operation
properties Dictionary of properties
Valid properties are 'ro', 'label' or 'compression'. Check the documentation to see where those properties are valid for each object.
salt.states.btrfs.subvolume_created(name, device, qgroupids=None, set_default=False, copy_on_write=True, force_set_default=True, __dest=None) Makes sure that a btrfs subvolume is present.
name   Name of the subvolume to add
device Device where to create the subvolume
set_default If True, this new subvolume will be set as default when mounted, unless subvol option in mount is used
copy_on_write If false, set the subvolume with chattr +C
force_set_default If false and the subvolume is already present, it will not force it as default if set_default is True
salt.states.btrfs.subvolume_deleted(name, device, commit=False, __dest=None) Makes sure that a btrfs subvolume is removed.
device Device where to remove the subvolume
commit Wait until the transaction is over
salt.states.cabal Installation of Cabal Packages New in version 2015.8.0.
These states manage the installed packages for Haskell using cabal. Note that cabal-install must be installed for these states to be available, so cabal states should include a requisite to a pkg.installed state for the package which provides cabal (cabal-install in case of Debian based distributions). Example:
cabal-install: pkg.installed
ShellCheck:
cabal.installed:
• require: - pkg: cabal-install
salt.states.cabal.installed(name, pkgs=None, user=None, install_global=False, env=None) Verify that the given package is installed and is at the correct version (if specified).
ShellCheck-0.3.5: cabal: - installed:
salt.states.cabal.removed(name, user=None, env=None) Verify that given package is not installed.
salt.states.ceph Manage ceph with salt.
salt.states.ceph.quorum(name, **kwargs) Quorum state
This state checks the mon daemons are in quorum. It does not alter the cluster but can be used in formula as a dependency for many cluster operations.
Example usage in sls file:
quorum: sesceph.quorum: - require: - sesceph: mon_running
salt.states.chef Execute Chef client runs Run chef-client or chef-solo
my-chef-run: chef.client: - override-runlist: 'demo1,demo2' - server: 'https://chef.domain.com'
default-chef-run: chef.client: []
my-solo-run: chef.solo: - environment: dev
salt.states.chef.client(name, **kwargs)
name   Unique identifier for the state. Does not affect the Chef run.
salt.states.chef.solo(name, **kwargs)
salt.states.chocolatey Manage Chocolatey package installs .. versionadded:: 2016.3.0
NOTE: Chocolatey pulls data from the Chocolatey internet database to determine current versions, find available versions, etc. This is normally a slow operation and may be optimized by specifying a local, smaller chocolatey repo.
salt.states.chocolatey.installed(name, version=None, source=None, force=False, pre_versions=False, install_args=None, override_args=False, force_x86=False, package_args=None, allow_multiple=False, execution_timeout=None) Installs a package if not already installed
• name (str) -- The name of the package to be installed. Required.
• version (str) -- Install a specific version of the package. Defaults to latest version. If the version is different to the one installed then the specified version will be installed. Default is None.
• source (str) -- Chocolatey repository (directory, share or remote URL, feed).  Defaults to the official Chocolatey feed. Default is None.
• install_args (str) -- Install arguments you want to pass to the installation process, i.e product key or feature list. Default is None.
• override_args (bool) -- Set to True if you want to override the original install arguments (for the native installer) in the package and use your own. When this is set to False install_args will be appended to the end of the default arguments. Default is False.
Allow mulitiple versions of the package to be installed. Do not use with force. Does not work with all packages. Default is False.
• execution_timeout (str) -- Chocolatey execution timeout value you want to pass to the installation process. Default is None.
Installsomepackage: chocolatey.installed: - name: packagename - version: '12.04' - source: 'mychocolatey/source' - force: True
salt.states.chocolatey.source_present(name, source_location, username=None, password=None, force=False) Instructs Chocolatey to add a source if not already present.
force  Salt will not modify a existing repository with the same name. Set this option to true to update an existing repository.
add_some_source: chocolatey.source_present: - name: reponame - source: https://repo.exemple.com - username: myuser - password: mypassword
salt.states.chocolatey.uninstalled(name, version=None, uninstall_args=None, override_args=False) Uninstalls a package
name   The name of the package to be uninstalled
override_args Set to true if you want to override the original uninstall arguments ( for the native uninstaller)in the package and use your own.  When this is set to False uninstall_args will be appended to the end of the default arguments
Removemypackage: chocolatey.uninstalled: - name: mypackage - version: '21.5'
salt.states.chocolatey.upgraded(name, version=None, source=None, force=False, pre_versions=False, install_args=None, override_args=False, force_x86=False, package_args=None) Upgrades a package. Will install the package if not installed.
• version (str) -- Install a specific version of the package. Defaults to latest version. If the version is greater than the one installed then the specified version will be installed. Default is None.
• force (bool) -- True will reinstall an existing package with the same version.  Default is False.
• pre_versions (bool) -- True will nclude pre-release packages. Default is False.
• override_args (bool) -- True will override the original install arguments (for the native installer) in the package and use those specified in install_args. False will append install_args to the end of the default arguments. Default is False.
• force_x86 (bool) -- True forces 32bit installation on 64 bit systems. Default is False.
upgrade_some_package: chocolatey.upgraded: - name: packagename - version: '12.04' - source: 'mychocolatey/source'
salt.states.chronos_job Configure Chronos jobs via a salt proxy.
my_job: chronos_job.config: - config: schedule: "R//PT2S" command: "echo 'hi'" owner: "me@example.com"
salt.states.chronos_job.absent(name) Ensure that the chronos job with the given name is not present.
Parameters name -- The app name
Returns A standard Salt changes dictionary
salt.states.chronos_job.config(name, config) Ensure that the chronos job with the given name is present and is configured to match the given config values.
• name -- The job name
• config -- The configuration to apply (dict)
salt.states.cimc A state module to manage Cisco UCS chassis devices.
About This state module was designed to handle connections to a Cisco Unified Computing System (UCS) chassis. This module relies on the CIMC proxy module to interface with the device.
SEE ALSO: CIMC Proxy Module
salt.states.cimc.hostname(name, hostname=None) Ensures that the hostname is set to the specified value.
name: The name of the module function to execute.
hostname(str): The hostname of the server.
set_name: cimc.hostname: - hostname: foobar
salt.states.cimc.logging_levels(name, remote=None, local=None) Ensures that the logging levels are set on the device. The logging levels must match the following options: emergency, alert, critical, error, warning, notice, informational, debug.
remote(str): The logging level for SYSLOG logs.
local(str): The logging level for the local device.
logging_levels: cimc.logging_levels: - remote: informational - local: notice
salt.states.cimc.ntp(name, servers) Ensures that the NTP servers are configured. Servers are provided as an individual string or list format. Only four NTP servers will be reviewed. Any entries past four will be ignored.
servers(str, list): The IP address or FQDN of the NTP servers.
ntp_configuration_list: cimc.ntp: - servers: - foo.bar.com - 10.10.10.10
ntp_configuration_str: cimc.ntp: - servers: foo.bar.com
salt.states.cimc.power_configuration(name, policy=None, delayType=None, delayValue=None) Ensures that the power configuration is configured on the system. This is only available on some C-Series servers.
policy(str): The action to be taken when chassis power is restored after an unexpected power loss. This can be one of the following: reset: The server is allowed to boot up normally when power is restored. The server can restart immediately or, optionally, after a fixed or random delay.
delayType(str): If the selected policy is reset, the restart can be delayed with this option. This can be one of the following: fixed: The server restarts after a fixed delay.
delayValue(int): If a fixed delay is selected, once chassis power is restored and the Cisco IMC has finished rebooting, the system waits for the specified number of seconds before restarting the server. Enter an integer between 0 and 240.
reset_power: cimc.power_configuration: - policy: reset - delayType: fixed - delayValue: 0
power_off: cimc.power_configuration: - policy: stay-off
salt.states.cimc.syslog(name, primary=None, secondary=None) Ensures that the syslog servers are set to the specified values. A value of None will be ignored.
primary(str): The IP address or FQDN of the primary syslog server.
secondary(str): The IP address or FQDN of the secondary syslog server.
syslog_configuration: cimc.syslog: - primary: 10.10.10.10 - secondary: foo.bar.com
salt.states.cimc.user(name, id='', user='', priv='', password='', status='active') Ensures that a user is configured on the device. Due to being unable to verify the user password. This is a forced operation.
id(int): The user ID slot on the device.
user(str): The username of the user.
priv(str): The privilege level of the user.
password(str): The password of the user.
status(str): The status of the user. Can be either active or inactive.
user_configuration: cimc.user: - id: 11 - user: foo - priv: admin - password: mypassword - status: active
salt.states.cisconso State module for Cisco NSO Proxy minions
salt.states.cisconso.value_present(name, datastore, path, config) Ensure a specific value exists at a given path
• name (str) -- The name for this rule
• config (dict) -- The new value at the given path
enable pap auth: cisconso.config_present: - name: enable_pap_auth - datastore: running - path: devices/device/ex0/config/sys/interfaces/serial/ppp0/authentication - config: authentication: method: pap "list-name": foobar
salt.states.cloud Using states instead of maps to deploy clouds New in version 2014.1.0.
Use this minion to spin up a cloud instance:
my-ec2-instance: cloud.profile: my-ec2-config
salt.states.cloud.absent(name, onlyif=None, unless=None) Ensure that no instances with the specified names exist.
CAUTION: This is a destructive state, which will search all configured cloud providers for the named instance, and destroy it.
name   The name of the instance to destroy
onlyif Do run the state only if is unless succeed
unless Do not run the state at least unless succeed
salt.states.cloud.present(name, cloud_provider, onlyif=None, unless=None, opts=None, **kwargs) Spin up a single instance on a cloud provider, using salt-cloud. This state does not take a profile argument; rather, it takes the arguments that would normally be configured as part of the state.
Note that while this function does take any configuration argument that would normally be used to create an instance, it will not verify the state of any of those arguments on an existing instance. Stateful properties of an instance should be configured using their own individual state (i.e., cloud.tagged, cloud.untagged, etc).
name   The name of the instance to create
cloud_provider The name of the cloud provider to use
opts   Any extra opts that need to be used
salt.states.cloud.profile(name, profile, onlyif=None, unless=None, opts=None, **kwargs) Create a single instance on a cloud provider, using a salt-cloud profile.
Note that while profiles used this function do take any configuration argument that would normally be used to create an instance using a profile, this state will not verify the state of any of those arguments on an existing instance. Stateful properties of an instance should be configured using their own individual state (i.e., cloud.tagged, cloud.untagged, etc).
profile The name of the cloud profile to use
kwargs Any profile override or addition
salt.states.cloud.volume_absent(name, provider=None, **kwargs) Check that a block volume exists.
salt.states.cloud.volume_attached(name, server_name, provider=None, **kwargs) Check if a block volume is attached.
salt.states.cloud.volume_detached(name, server_name=None, provider=None, **kwargs) Check if a block volume is attached.
Returns True if server or Volume do not exist.
salt.states.cloud.volume_present(name, provider=None, **kwargs) Check that a block volume exists.
salt.states.cmd Execution of arbitrary commands The cmd state module manages the enforcement of executed commands, this state can tell a command to run under certain circumstances.
A simple example to execute a command:
# Store the current date in a file 'date > /tmp/salt-run': cmd.run
Only run if another execution failed, in this case truncate syslog if there is no disk space:
'> /var/log/messages/': cmd.run: - unless: echo 'foo' > /tmp/.test && rm -f /tmp/.test
Only run if the file specified by creates does not exist, in this case touch /tmp/foo if it does not exist:
touch /tmp/foo: cmd.run: - creates: /tmp/foo
"echo 'foo' | tee /tmp/bar > /tmp/baz": cmd.run: - creates: - /tmp/bar - /tmp/baz
NOTE: The creates option was added to the cmd state in version 2014.7.0, and made a global requisite in 3001.
Sometimes when running a command that starts up a daemon, the init script doesn't return properly which causes Salt to wait indefinitely for a response.  In situations like this try the following:
run_installer: cmd.run: - name: /tmp/installer.bin > /dev/null 2>&1
Salt determines whether the cmd state is successfully enforced based on the exit code returned by the command. If the command returns a zero exit code, then salt determines that the state was successfully enforced. If the script returns a non-zero exit code, then salt determines that it failed to successfully enforce the state.  If a command returns a non-zero exit code but you wish to treat this as a success, then you must place the command in a script and explicitly set the exit code of the script to zero.
Please note that the success or failure of the state is not affected by whether a state change occurred nor the stateful argument.
When executing a command or script, the state (i.e., changed or not) of the command is unknown to Salt's state system. Therefore, by default, the cmd state assumes that any command execution results in a changed state.
This means that if a cmd state is watched by another state then the state that's watching will always be executed due to the changed state in the cmd state.
Using the Stateful Argument Many state functions in this module now also accept a stateful argument. If stateful is specified to be true then it is assumed that the command or script will determine its own state and communicate it back by following a simple protocol described below:
1. If there's nothing in the stdout of the command, then assume no changes. Otherwise, the stdout must be either in JSON or its last non-empty line must be a string of key=value pairs delimited by spaces (no spaces on either side of =).
2. If it's JSON then it must be a JSON object (e.g., {}). If it's key=value pairs then quoting may be used to include spaces.  (Python's shlex module is used to parse the key=value string)
Two special keys or attributes are recognized in the output:
changed: bool (i.e., 'yes', 'no', 'true', 'false', case-insensitive) comment: str  (i.e., any string)
So, only if changed is True then assume the command execution has changed the state, and any other key values or attributes in the output will be set as part of the changes.
3. If there's a comment then it will be used as the comment of the state.
Here's an example of how one might write a shell script for use with a stateful command:
#!/bin/bash # echo "Working hard..."
# writing the state line echo  # an empty line here so the next line will be the last. echo "changed=yes comment='something has changed' whatever=123"
And an example SLS file using this module:
Run myscript: cmd.run: - name: /path/to/myscript - cwd: / - stateful: True
Run only if myscript changed something: cmd.run: - name: echo hello - cwd: / - onchanges: - cmd: Run myscript
Note that if the second cmd.run state also specifies stateful: True it can then be watched by some other states as well.
4. The stateful argument can optionally include a test_name parameter.
This is used to specify a command to run in test mode.  This command should return stateful data for changes that would be made by the command in the name parameter.
Run myscript: cmd.run: - name: /path/to/myscript - cwd: / - stateful: - test_name: /path/to/myscript test
Run masterscript: cmd.script: - name: masterscript - source: salt://path/to/masterscript - cwd: / - stateful: - test_name: masterscript test
Should I use cmd.run or cmd.wait? NOTE: Use cmd.run together with onchanges instead of cmd.wait.
These two states are often confused. The important thing to remember about them is that cmd.run states are run each time the SLS file that contains them is applied. If it is more desirable to have a command that only runs after some other state changes, then cmd.wait does just that. cmd.wait is designed to watch other states, and is executed when the state it is watching changes. Example:
/usr/local/bin/postinstall.sh: cmd.wait: - watch: - pkg: mycustompkg file.managed: - source: salt://utils/scripts/postinstall.sh
mycustompkg: pkg.installed: - require: - file: /usr/local/bin/postinstall.sh
cmd.wait itself do not do anything; all functionality is inside its mod_watch function, which is called by watch on changes.
The preferred format is using the onchanges Requisite, which works on cmd.run as well as on any other state. The example would then look as follows:
/usr/local/bin/postinstall.sh: cmd.run: - onchanges: - pkg: mycustompkg file.managed: - source: salt://utils/scripts/postinstall.sh
How do I create an environment from a pillar map? The map that comes from a pillar can be directly consumed by the env option!  To use it, one may pass it like this. Example:
printenv: cmd.run: - env: {{ salt['pillar.get']('example:key', {}) }}
salt.states.cmd.call(name, func, args=(), kws=None, output_loglevel='debug', hide_output=False, use_vt=False, **kwargs) Invoke a pre-defined Python function with arguments specified in the state declaration. This function is mainly used by the salt.renderers.pydsl renderer.
In addition, the stateful argument has no effects here.
The return value of the invoked function will be interpreted as follows.
If it's a dictionary then it will be passed through to the state system, which expects it to have the usual structure returned by any salt state function.
Otherwise, the return value (denoted as result in the code below) is expected to be a JSON serializable object, and this dictionary is returned:
{ 'name': name 'changes': {'retval': result}, 'result': True if result is None else bool(result), 'comment': result if isinstance(result, str) else '' }
salt.states.cmd.mod_watch(name, **kwargs) Execute a cmd function based on a watch call
salt.states.cmd.run(name, cwd=None, root=None, runas=None, shell=None, env=None, prepend_path=None, stateful=False, umask=None, output_loglevel='debug', hide_output=False, timeout=None, ignore_timeout=False, use_vt=False, success_retcodes=None, success_stdout=None, success_stderr=None, **kwargs) Run a command if certain circumstances are met.  Use cmd.wait if you want to use the watch requisite.
NOTE: The **kwargs of cmd.run are passed down to one of the following exec modules:
• cmdmod.run_all: If used with default runas
• cmdmod.run_chroot: If used with non-root value for runas
For more information on what args are available for either of these, refer to the cmdmod documentation.
name   The command to execute, remember that the command will execute with the path and permissions of the salt-minion.
cwd    The current working directory to execute the command in, defaults to /root
root   Path to the root of the jail to use. If this parameter is set, the command will run inside a chroot
runas  The user name (or uid) to run the command as
shell  The shell to use for execution, defaults to the shell grain
env    A list of environment variables to be set prior to execution.  Example:
script-foo: cmd.run: - env: - BATCH: 'yes'
Variables as values are not evaluated. So $PATH in the following example is a literal '$PATH':
script-bar: cmd.run: - env: "PATH=/some/path:$PATH"
One can still use the existing $PATH by using a bit of Jinja:
{% set current_path = salt['environ.get']('PATH', '/bin:/usr/bin') %}
mycommand: cmd.run: - name: ls -l / - env: - PATH: {{ [current_path, '/my/special/bin']|join(':') }}
NOTE: When using environment variables on Windows, case-sensitivity matters, i.e. Windows uses Path as opposed to PATH for other systems.
prepend_path $PATH segment to prepend (trailing ':' not necessary) to $PATH. This is an easier alternative to the Jinja workaround.
stateful The command being executed is expected to return data about executing a state. For more information, see the Using the "Stateful" Argument section.
umask  The umask (in octal) to use when running the command.
output_loglevel debug Control the loglevel at which the output from the command is logged to the minion log.
hide_output False Suppress stdout and stderr in the state's results.
timeout If the command has not terminated after timeout seconds, send the subprocess sigterm, and if sigterm is ignored, follow up with sigkill
ignore_timeout Ignore the timeout of commands, which is useful for running nohup processes.
creates Only run if the file specified by creates do not exist. If you specify a list of files then this state will only run if any of the files do not exist.
use_vt False Use VT utils (saltstack) to stream the command output more interactively to the console and the logs.  This is experimental.
bg     False If True, run command in background and do not await or deliver its results.
success_retcodes: This parameter will allow a list of non-zero return codes that should be considered a success.  If the return code returned from the run matches any in the provided list, the return code will be overridden with zero.
success_stdout: This parameter will allow a list of strings that when found in standard out should be considered a success.  If stdout returned from the run matches any in the provided list, the return code will be overridden with zero.
success_stderr: This parameter will allow a list of strings that when found in standard error should be considered a success.  If stderr returned from the run matches any in the provided list, the return code will be overridden with zero.
NOTE: cmd.run supports the usage of reload_modules. This functionality allows you to force Salt to reload all modules. You should only use reload_modules if your cmd.run does some sort of installation (such as pip), if you do not reload the modules future items in your state which rely on the software being installed will fail.
getpip: cmd.run: - name: /usr/bin/python /usr/local/sbin/get-pip.py - unless: which pip - require: - pkg: python - file: /usr/local/sbin/get-pip.py - reload_modules: True
salt.states.cmd.script(name, source=None, template=None, cwd=None, runas=None, password=None, shell=None, env=None, stateful=False, umask=None, timeout=None, use_vt=False, output_loglevel='debug', hide_output=False, defaults=None, context=None, success_retcodes=None, success_stdout=None, success_stderr=None, **kwargs) Download a script and execute it with specified arguments.
source The location of the script to download. If the file is located on the master in the directory named spam, and is called eggs, the source string is salt://spam/eggs
template If this setting is applied then the named templating engine will be used to render the downloaded file. Currently jinja, mako, and wempy are supported
name   Either "cmd arg1 arg2 arg3..." (cmd is not used) or a source "salt://...".
runas  Specify an alternate user to run the command. The default behavior is to run as the user under which Salt is running. If running on a Windows minion you must also use the password argument, and the target user account must be in the Administrators group.
NOTE: For Windows users, specifically Server users, it may be necessary to specify your runas user using the User Logon Name instead of the legacy logon name. Traditionally, logons would be in the following format. Domain/user
New in version 3000: Windows only. Required when specifying runas. This parameter will be ignored on non-Windows platforms.
shell  The shell to use for execution. The default is set in grains['shell']
salt://scripts/foo.sh: cmd.script: - env: - BATCH: 'yes'
salt://scripts/bar.sh: cmd.script: - env: "PATH=/some/path:$PATH"
saltenv base The Salt environment to use
args   String of command line args to pass to the script.  Only used if no args are specified as part of the name argument. To pass a string containing spaces in YAML, you will need to doubly-quote it:  "arg1 'arg two' arg3"
use_vt Use VT utils (saltstack) to stream the command output more interactively to the console and the logs.  This is experimental.
context New in version 2016.3.0.
Overrides default context variables passed to the template.
defaults New in version 2016.3.0.
Default context passed to the template.
salt.states.cmd.wait(name, cwd=None, root=None, runas=None, shell=None, env=(), stateful=False, umask=None, output_loglevel='debug', hide_output=False, use_vt=False, success_retcodes=None, success_stdout=None, success_stderr=None, **kwargs) Run the given command only if the watch statement calls it.
NOTE: Use cmd.run together with onchanges instead of cmd.wait.
runas  The user name to run the command as
shell  The shell to use for execution, defaults to /bin/sh
script-foo: cmd.wait: - env: - BATCH: 'yes'
script-bar: cmd.wait: - env: "PATH=/some/path:$PATH"
salt.states.cmd.wait_call(name, func, args=(), kws=None, stateful=False, use_vt=False, output_loglevel='debug', hide_output=False, **kwargs)
salt.states.cmd.wait_script(name, source=None, template=None, cwd=None, runas=None, shell=None, env=None, stateful=False, umask=None, use_vt=False, output_loglevel='debug', hide_output=False, success_retcodes=None, success_stdout=None, success_stderr=None, **kwargs) Download a script from a remote source and execute it only if a watch statement calls it.
source The source script being downloaded to the minion, this source script is hosted on the salt master server.  If the file is located on the master in the directory named spam, and is called eggs, the source string is salt://spam/eggs
template If this setting is applied then the named templating engine will be used to render the downloaded file, currently jinja, mako, and wempy are supported
salt://scripts/foo.sh: cmd.wait_script: - env: - BATCH: 'yes'
salt://scripts/bar.sh: cmd.wait_script: - env: "PATH=/some/path:$PATH"
salt.states.cmd.watch(name, cwd=None, root=None, runas=None, shell=None, env=(), stateful=False, umask=None, output_loglevel='debug', hide_output=False, use_vt=False, success_retcodes=None, success_stdout=None, success_stderr=None, **kwargs) This function is an alias of wait. Run the given command only if the watch statement calls it.
salt.states.composer Installation of Composer Packages These states manage the installed packages for composer for PHP. Note that either composer is installed and accessible via a bin directory or you can pass the location of composer in the state.
get-composer: cmd.run: - name: 'CURL=`which curl`; $CURL -sS https://getcomposer.org/installer | php' - unless: test -f /usr/local/bin/composer - cwd: /root/
install-composer: cmd.wait: - name: mv /root/composer.phar /usr/local/bin/composer - cwd: /root/ - watch: - cmd: get-composer
/path/to/project: composer.installed: - no_dev: true - require: - cmd: install-composer
# Without composer installed in your PATH # Note: composer.phar must be executable for state to work properly /path/to/project: composer.installed: - composer: /path/to/composer.phar - php: /usr/local/bin/php - no_dev: true
salt.states.composer.installed(name, composer=None, php=None, user=None, prefer_source=None, prefer_dist=None, no_scripts=None, no_plugins=None, optimize=None, no_dev=None, quiet=False, composer_home='/root', always_check=True, env=None) Verify that the correct versions of composer dependencies are present.
name   Directory location of the composer.json file.
composer Location of the composer.phar file. If not set composer will just execute composer as if it is installed globally. (i.e. /path/to/composer.phar)
user   Which system user to run composer as.
always_check If True, always run composer install in the directory. This is the default behavior.  If False, only run composer install if there is no vendor directory present.
salt.states.composer.update(name, composer=None, php=None, user=None, prefer_source=None, prefer_dist=None, no_scripts=None, no_plugins=None, optimize=None, no_dev=None, quiet=False, composer_home='/root', env=None) Composer update the directory to ensure we have the latest versions of all project dependencies.
salt.states.cron Management of cron, the Unix command scheduler Cron declarations require a number of parameters. The following are the parameters used by Salt to define the various timing values for a cron job:
• minute
• hour
• daymonth
• month
• dayweek (0 to 6 are Sunday through Saturday, 7 can also be used for Sunday)
WARNING: Any timing arguments not specified take a value of *. This means that setting hour to 5, while not defining the minute param, will result in Salt adding a job that will execute every minute between 5 and 6 A.M.!
Additionally, the default user for these states is root. Therefore, if the cron job is for another user, it is necessary to specify that user with the user parameter.
A long time ago (before 2014.2), when making changes to an existing cron job, the name declaration is the parameter used to uniquely identify the job, so if an existing cron that looks like this:
date > /tmp/crontest: cron.present: - user: root - minute: 5
Is changed to this:
date > /tmp/crontest: cron.present: - user: root - minute: 7 - hour: 2
Then the existing cron will be updated, but if the cron command is changed, then a new cron job will be added to the user's crontab.
The current behavior is still relying on that mechanism, but you can also specify an identifier to identify your crontabs:
date > /tmp/crontest: cron.present: - identifier: SUPERCRON - user: root - minute: 7 - hour: 2
New in version 2014.1.2.
And, some months later, you modify it:
superscript > /tmp/crontest: cron.present: - identifier: SUPERCRON - user: root - minute: 3 - hour: 4
The old date > /tmp/crontest will be replaced by superscript > /tmp/crontest.
Additionally, Salt also supports running a cron every x minutes very similarly to the Unix convention of using */5 to have a job run every five minutes. In Salt, this looks like:
date > /tmp/crontest: cron.present: - user: root - minute: '*/5'
The job will now run every 5 minutes.
Additionally, the temporal parameters (minute, hour, etc.) can be randomized by using random instead of using a specific value. For example, by using the random keyword in the minute parameter of a cron state, the same cron job can be pushed to hundreds or thousands of hosts, and they would each use a randomly-generated minute. This can be helpful when the cron job accesses a network resource, and it is not desirable for all hosts to run the job concurrently.
/path/to/cron/script: cron.present: - user: root - minute: random - hour: 2
Since Salt assumes a value of * for unspecified temporal parameters, adding a parameter to the state and setting it to random will change that value from * to a randomized numeric value. However, if that field in the cron entry on the minion already contains a numeric value, then using the random keyword will not modify it.
Added the opportunity to set a job with a special keyword like '@reboot' or '@hourly'. Quotes must be used, otherwise PyYAML will strip the '@' sign.
/path/to/cron/script: cron.present: - user: root - special: '@hourly'
The script will be executed every reboot if cron daemon support this option.
/path/to/cron/otherscript: cron.absent: - user: root - special: '@daily'
This counter part definition will ensure than a job with a special keyword is not set.
salt.states.cron.absent(name, user='root', identifier=False, special=None, **kwargs) Verifies that the specified cron job is absent for the specified user; only the name is matched when removing a cron job.
name   The command that should be absent in the user crontab.
user   The name of the user whose crontab needs to be modified, defaults to the root user
identifier Custom-defined identifier for tracking the cron line for future crontab edits. This defaults to the state name
special The special keyword used in the job (eg. @reboot, @hourly...).  Quotes must be used, otherwise PyYAML will strip the '@' sign.
salt.states.cron.env_absent(name, user='root') Verifies that the specified environment variable is absent from the crontab for the specified user
name   The name of the environment variable to remove from the user crontab
salt.states.cron.env_present(name, value=None, user='root') Verifies that the specified environment variable is present in the crontab for the specified user.
name   The name of the environment variable to set in the user crontab
value  The value to set for the given environment variable
salt.states.cron.file(name, source_hash='', source_hash_name=None, user='root', template=None, context=None, replace=True, defaults=None, backup='', **kwargs) Provides file.managed-like functionality (templating, etc.) for a pre-made crontab file, to be assigned to a given user.
name   The source file to be used as the crontab. This source file can be hosted on either the salt master server, or on an HTTP or FTP server.  For files hosted on the salt file server, if the file is located on the master in the directory named spam, and is called eggs, the source string is salt://spam/eggs
If the file is hosted on a HTTP or FTP server then the source_hash argument is also required
source_hash This can be either a file which contains a source hash string for the source, or a source hash string. The source hash string is the hash algorithm followed by the hash of the file: md5=e138491e9d5b97023cea823fe17bac22
source_hash_name When source_hash refers to a hash file, Salt will try to find the correct hash by matching the filename/URI associated with that hash. By default, Salt will look for the filename being managed. When managing a file at path /tmp/foo.txt, then the following line in a hash file would match:
acbd18db4cc2f85cedef654fccc4a4d8    foo.txt
foo_crontab: cron.file: - name: https://mydomain.tld/dir2/foo.txt - source_hash: https://mydomain.tld/hashes - source_hash_name: ./dir2/foo.txt
user   The user to whom the crontab should be assigned. This defaults to root.
template If this setting is applied then the named templating engine will be used to render the downloaded file. Currently, jinja and mako are supported.
replace If the crontab should be replaced, if False then this command will be ignored if a crontab exists for the specified user. Default is True.
backup Overrides the default backup mode for the user's crontab.
salt.states.cron.present(name, user='root', minute='*', hour='*', daymonth='*', month='*', dayweek='*', comment=None, commented=False, identifier=False, special=None) Verifies that the specified cron job is present for the specified user.  It is recommended to use identifier. Otherwise the cron job is installed twice if you change the name.  For more advanced information about what exactly can be set in the cron timing parameters, check your cron system's documentation. Most Unix-like systems' cron documentation can be found via the crontab man page: man 5 crontab.
name   The command that should be executed by the cron job.
minute The information to be set into the minute section, this can be any string supported by your cron system's the minute field. Default is *
hour   The information to be set in the hour section. Default is *
daymonth The information to be set in the day of month section. Default is *
month  The information to be set in the month section. Default is *
dayweek The information to be set in the day of week section. Default is *
comment User comment to be added on line previous the cron job
commented The cron job is set commented (prefixed with #DISABLED#). Defaults to False.
special A special keyword to specify periodicity (eg. @reboot, @hourly...).  Quotes must be used, otherwise PyYAML will strip the '@' sign.
salt.states.cryptdev Opening of Encrypted Devices Ensure that an encrypted device is mapped with the mapped function:
mappedname: cryptdev.mapped: - device: /dev/sdb1 - keyfile: /etc/keyfile.key - opts: - size=256
swap: crypted.mapped: - device: /dev/sdx4 - keyfile: /dev/urandom - opts: swap,cipher=aes-cbc-essiv:sha256,size=256
mappedbyuuid: crypted.mapped: - device: UUID=066e0200-2867-4ebe-b9e6-f30026ca2314 - keyfile: /etc/keyfile.key - config: /etc/alternate-crypttab
salt.states.cryptdev.mapped(name, device, keyfile=None, opts=None, config='/etc/crypttab', persist=True, immediate=False, match_on='name') Verify that a device is mapped
name   The name under which the device is to be mapped
device The device name, typically the device node, such as /dev/sdb1 or UUID=066e0200-2867-4ebe-b9e6-f30026ca2314.
keyfile Either None if the password is to be entered manually on boot, or an absolute path to a keyfile. If the password is to be asked interactively, the mapping cannot be performed with immediate=True.
opts   A list object of options or a comma delimited list
config Set an alternative location for the crypttab, if the map is persistent, Default is /etc/crypttab
persist Set if the map should be saved in the crypttab, Default is True
immediate Set if the device mapping should be executed immediately. Requires that the keyfile not be None, because the password cannot be asked interactively. Note that options are not passed through on the initial mapping.  Default is False.
match_on A name or list of crypttab properties on which this state should be applied.  Default is name, meaning that the line is matched only by the name parameter. If the desired configuration requires two devices mapped to the same name, supply a list of parameters to match on.
salt.states.cryptdev.unmapped(name, config='/etc/crypttab', persist=True, immediate=False) Ensure that a device is unmapped
name   The name to ensure is not mapped
persist Set if the map should be removed from the crypttab. Default is True
immediate Set if the device should be unmapped immediately. Default is False.
salt.states.csf CSF Ip tables management depends
• csf utility
configuration See http://download.configserver.com/csf/install.txt for setup instructions.
Simply allow/deny rules: csf.rule_present: ip: 1.2.3.4 method: allow
salt.states.csf.nics_skip(name, nics, ipv6) Alias for csf.nics_skipped
salt.states.csf.nics_skipped(name, nics, ipv6=False)
name   Meaningless arg, but required for state.
nics   A list of nics to skip.
ipv6   Boolean. Set to true if you want to skip the ipv6 interface. Default false (ipv4).
salt.states.csf.option_present(name, value, reload=False) Ensure the state of a particular option/setting in csf.
name   The option name in csf.conf
value  The value it should be set to.
reload Boolean. If set to true, csf will be reloaded after.
salt.states.csf.ports_open(name, ports, proto='tcp', direction='in') Ensure ports are open for a protocol, in a direction.  e.g. - proto='tcp', direction='in' would set the values for TCP_IN in the csf.conf file.
ports  A list of ports that should be open.
proto  The protocol. May be one of 'tcp', 'udp', 'tcp6', or 'udp6'.
direction Choose 'in', 'out', or both to indicate the port should be opened for inbound traffic, outbound traffic, or both.
salt.states.csf.rule_absent(name, method, port=None, proto='tcp', direction='in', port_origin='d', ip_origin='s', ttl=None, reload=False) Ensure iptable is not present.
name   The ip address or CIDR for the rule.
method The type of rule.  Either 'allow' or 'deny'.
port   Optional port to be open or closed for the iptables rule.
proto  The protocol. Either 'tcp', 'udp'.  Only applicable if port is specified.
direction The diretion of traffic to apply the rule to.  Either 'in', or 'out'. Only applicable if port is specified.
port_origin Specifies either the source or destination port is relevant for this rule. Only applicable if port is specified. Either 's', or 'd'.
ip_origin Specifies whether the ip in this rule refers to the source or destination ip. Either 's', or 'd'. Only applicable if port is specified.
ttl    How long the rule should exist. If supplied, csf.tempallow() or csf.tempdeny()` are used.
reload Reload the csf service after applying this rule.  Default false.
salt.states.csf.rule_present(name, method, port=None, proto='tcp', direction='in', port_origin='d', ip_origin='s', ttl=None, comment='', reload=False) Ensure iptable rule exists.
proto  The protocol. Either 'tcp', or 'udp'.  Only applicable if port is specified.
comment An optional comment to appear after the rule as a #comment .
salt.states.csf.testing_off(name, reload=False) Ensure testing mode is enabled in csf.
reload Reload CSF after changing the testing status.  Default false.
salt.states.csf.testing_on(name, reload=False) Ensure testing mode is enabled in csf.
salt.states.cyg Installation of Cygwin packages.
A state module to manage cygwin packages. Packages can be installed or removed.
dos2unix: cyg.installed
class salt.states.cyg.DictDiffer(current_dict, past_dict) Calculate the difference between two dictionaries.
1. items added
2. items removed
3. keys same in both but changed values
4. keys same in both and unchanged values
added() Return a set of additions to past_dict.
changed() Return a set of the keys with changed values.
removed() Return a set of things removed from past_dict.
same() True if the two dicts are the same.
unchanged() Return a set of the keys with unchanged values.