neulab/tldr huggingface dataset:
Select config files through grains|pillar|opts matching You can also opt for a much more flexible configuration: PillarStack allows one to select the config files for the current minion based on matching values from either grains, or pillar, or opts objects.
ext_pillar: - stack: pillar:environment: dev: /path/to/dev/stack.cfg prod: /path/to/prod/stack.cfg grains:custom:grain: value: - /path/to/stack1.cfg - /path/to/stack2.cfg opts:custom:opt: value: /path/to/stack0.cfg
PillarStack configuration files The config files that are referenced in the above ext_pillar configuration are jinja2 templates which must render as a simple ordered list of yaml files that will then be merged to build pillar data.
The path of these yaml files must be relative to the directory of the PillarStack config file. These paths support unix style pathname pattern expansion through the Python glob module <https://docs.python.org/2/library/glob.html>.
The following variables are available in jinja2 templating of PillarStack configuration files:
So you can use all the power of jinja2 to build your list of yaml files that will be merged in pillar data.
For example, you could have a PillarStack config file which looks like:
$ cat /path/to/stack/config.cfg core.yml common/*.yml osarchs/{{ __grains__['osarch'] }}.yml oscodenames/{{ __grains__['oscodename'] }}.yml {%- for role in pillar.get('roles', []) %} roles/{{ role }}.yml {%- endfor %} minions/{{ minion_id }}.yml
$ tree /path/to/stack/ /path/to/stack/ ├── config.cfg ├── core.yml ├── common/ │   ├── xxx.yml │   └── yyy.yml ├── osarchs/ │   ├── amd64.yml │   └── armhf.yml ├── oscodenames/ │   ├── wheezy.yml │   └── jessie.yml ├── roles/ │   ├── web.yml │   └── db.yml └── minions/ ├── test-1-dev.yml └── test-2-dev.yml
Overall process In the above PillarStack configuration, given that test-1-dev minion is an amd64 platform running Debian Jessie, and which pillar roles is ["db"], the following yaml files would be merged in order:
• common/xxx.yml
• common/yyy.yml
Before merging, every files above will be preprocessed as Jinja2 templates.  The following variables are available in Jinja2 templating of yaml files:
• stack: the PillarStack pillar data object that has currently been merged (data from previous yaml files in PillarStack configuration)
So you can use all the power of jinja2 to build your pillar data, and even use other pillar values that has already been merged by PillarStack (from previous yaml files in PillarStack configuration) through the stack variable.
Once a yaml file has been preprocessed by Jinja2, we obtain a Python dict - let's call it yml_data - then, PillarStack will merge this yml_data dict in the main stack dict (which contains already merged PillarStack pillar data).  By default, PillarStack will deeply merge yml_data in stack (similarly to the recurse salt pillar_source_merging_strategy), but 3 merging strategies are currently available for you to choose (see next section).
Once every yaml files have been processed, the stack dict will contain your whole own pillar data, merged in order by PillarStack.  So PillarStack ext_pillar returns the stack dict, the contents of which Salt takes care to merge in with all of the other pillars and finally return the whole pillar to the minion.
salt.pillar.stack.ext_pillar(minion_id, pillar, *args, **kwargs)
salt.pillar.svn_pillar Clone a remote SVN repository and use the filesystem as a Pillar source
This external Pillar source can be configured in the master config file like so:
ext_pillar: - svn: trunk svn://svnserver/repo root=subdirectory
The root= parameter is optional and used to set the subdirectory from where to look for Pillar files (such as top.sls).
Changed in version 2014.7.0: The optional root parameter will be added.
Note that this is not the same thing as configuring pillar data using the pillar_roots parameter. The branch referenced in the ext_pillar entry above (master), would evaluate to the base environment, so this branch needs to contain a top.sls with a base section in it, like this:
To use other environments from the same SVN repo as svn_pillar sources, just add additional lines, like so:
ext_pillar: - svn: trunk svn://svnserver/repo - svn: dev svn://svnserver/repo
In this case, the dev branch would need its own top.sls with a dev section in it, like this:
dev: '*': - bar
class salt.pillar.svn_pillar.SvnPillar(branch, repo_location, root, opts) Deal with the remote SVN repository for Pillar
pillar_dir() Returns the directory of the pillars (repo cache + branch + root)
salt.pillar.svn_pillar.ext_pillar(minion_id, pillar, repo_string) Execute a command and read the output as YAML
salt.pillar.varstack_pillar Use Varstack data as a Pillar source
Configuring Varstack Using varstack in Salt is fairly simple. Just put the following into the config file of your master:
ext_pillar: - varstack: /etc/varstack.yaml
Varstack will then use /etc/varstack.yaml to determine which configuration data to return as pillar information. From there you can take a look at the README of varstack on how this file is evaluated.
salt.pillar.varstack_pillar.ext_pillar(minion_id, pillar, conf) Parse varstack data and return the result
salt.pillar.vault Vault Pillar Module
This module allows pillar data to be stored in Hashicorp Vault.
Base configuration instructions are documented in the execution module docs.  Below are noted extra configuration required for the pillar module, but the base configuration must also be completed.
After the base Vault configuration is created, add the configuration below to the ext_pillar section in the Salt master configuration.
ext_pillar: - vault: path=secret/salt
Each key needs to have all the key-value pairs with the names you require. Avoid naming every key 'password' as you they will collide:
If you want to nest results under a nesting_key name use the following format:
vault: conf: path=secret/salt nesting_key: vault_key_name
$ vault write secret/salt auth=my_password master=127.0.0.1
The above will result in two pillars being available, auth and master.
You can then use normal pillar requests to get each key pair directly from pillar root. Example:
$ salt-ssh '*' pillar.get auth
Multiple Vault sources may also be used:
ext_pillar: - vault: path=secret/salt - vault: path=secret/root - vault: path=secret/minions/{minion}/pass
You can also use nesting here as well.  Identical nesting keys will get merged.
ext_pillar: - vault: conf: path=secret/salt nesting_key: keyname1 - vault: conf: path=secret/root nesting_key: keyname1 - vault: conf: path=secret/minions/{minion}/pass nesting_key: keyname2
The difference between the return with and without the nesting key is shown below.  This example takes the key value pairs returned from vault as follows:
path=secret/salt
Key             Value ---             ----- salt-passwd     badpasswd1
path=secret/root
Key             Value ---             ----- root-passwd rootbadpasswd1
path=secret/minions/{minion}/pass
Key             Value ---             ----- minion-passwd minionbadpasswd1
#Nesting Key not defined
local: ---------- salt-passwd: badpasswd1 root-passwd: rootbadpasswd1 minion-passwd: minionbadpasswd1
#Nesting Key defined
local: ---------- keyname1: ---------- salt-passwd: badpasswd1 root-passwd: rootbadpasswd1 keyname2: ---------- minion-passwd: minionbadpasswd1
salt.pillar.vault.ext_pillar(minion_id, pillar, conf, nesting_key=None) Get pillar data from Vault for the configuration conf.
salt.pillar.venafi Venafi Pillar Certificates
This module will only return pillar data if the venafi runner module has already been used to create certificates.
To configure this module, set venafi to True in the ext_pillar section of your master configuration file:
ext_pillar: - venafi: True
salt.pillar.venafi.ext_pillar(minion_id, pillar, conf) Return an existing set of certificates
salt.pillar.virtkey Accept a key from a hypervisor if the virt runner has already submitted an authorization request
salt.pillar.virtkey.ext_pillar(hyper_id, pillar, name, key) Accept the key for the VM on the hyper, if authorized.
salt.pillar.vmware_pillar Pillar data from vCenter or an ESXi host
• pyVmomi
This external pillar can pull attributes from objects in vCenter or an ESXi host and provide those attributes as pillar data to minions.  This can allow for pillar based targeting of minions on ESXi host, Datastore, VM configuration, etc.  This setup requires only the salt master have access to the vCenter server/ESXi hosts.
The pillar will return an empty dict if the 'os' or 'virtual' grain are not 'VMWare', 'ESXi', or 'VMWare ESXi'.
Defaults • The external pillar will search for Virtual Machines with the VM name matching the minion id.
• Data will be returned into the 'vmware' pillar key.
• The external pillar has a default set of properties to return for both VirtualMachine and HostSystem types.
Configuring the VMWare pillar The required minimal configuration in the salt master ext_pillar setup:
ext_pillar: - vmware: host: <vcenter/esx host> username: <user to connect with> password: <password>
Optionally, the following keyword arguments can be passed to the ext_pillar for customized configuration:
pillar_key Optionally set the pillar key to return the data into.  Default is vmware.
property_name Property name to match the minion id against.  Defaults to name.
property_types Optionally specify a list of pyVmomi vim types to search for the minion id in 'property_name'.  Default is ['VirtualMachine'].
For example, to search both vim.VirtualMachine and vim.HostSystem object types:
ext_pillar: - vmware: host: myesx username: root password: complex_password property_types: - VirtualMachine - HostSystem
Additionally, the list of property types can be dicts, the item of the dict being a list specifying the attribute to return for that vim object type.
The pillar will attempt to recurse the attribute and return all child attributes.
To explicitly specify deeper attributes without attempting to recurse an attribute, convert the list item to a dict with the item of the dict being the child attributes to return.  Follow this pattern to return attributes as deep within the object as necessary.
NOTE: Be careful when specifying custom attributes!  Many attributes have objects as attributes which have the parent object as an attribute and which will cause the pillar to fail due to the attempt to convert all sub-objects recursively (i.e. infinite attribute loops).  Specifying only the sub-attributes you would like returned will keep the infinite recursion from occurring.
A maximum recursion exception will occur in this case and the pillar will not return as desired.
ext_pillar: - vmware: host: myvcenter username: my_user password: my_pass replace_default_attributes: True property_types: - VirtualMachine: - config: - bootOptions: - bootDelay - bootRetryDelay - HostSystem: - datastore: - name
The above ext_pillar example would return a pillar like the following for a VirtualMachine object that's name matched the minion id:
vmware: config: bootOptions: bootDelay: 1000 bootRetryDelay: 1000
If you were to retrieve these virtual machine attributes via pyVmomi directly, this would be the same as
vmObject.config.bootOptions.bootDelay vmObject.config.bootOptionis.bootRetryDelay
The above ext_pillar example would return a pillar like the following for a HostySystem object that's name matched the minion id:
vmware: datastore: - name: Datastore1 - name: Datastore2
The 'datastore' property of a HostSystem object is a list of datastores, thus a list is returned.
replace_default_attributes If custom attributes are specified by the property_types parameter, replace_default_attributes determines if those will be added to default attributes (False) or replace the default attributes completely (True).  The default setting is 'False'.
NOTE: vCenter "Custom Attributes" (i.e. Annotations) will always be returned if it exists on the object as part of the pillar regardless of this setting.
salt.pillar.vmware_pillar.ext_pillar(minion_id, pillar, **kwargs) Check vmware/vcenter for all data
salt.proxy.arista_pyeapi Arista pyeapi New in version 2019.2.0.
Proxy module for managing Arista switches via the eAPI using the pyeapi library.
Dependencies The pyeapi Proxy module requires pyeapi to be installed: pip install pyeapi.
Pillar The pyeapi proxy configuration requires the following parameters in order to connect to the network device:
All the arguments may be optional, depending on your setup.
Proxy Pillar Example proxy: proxytype: pyeapi host: router1.example.com username: example password: example
salt.proxy.arista_pyeapi.call(method, *args, **kwargs) Calls an arbitrary pyeapi method.
salt.proxy.arista_pyeapi.conn() Return the connection object.
salt.proxy.arista_pyeapi.init(opts) Open the connection to the Arista switch over the eAPI.
salt.proxy.arista_pyeapi.initialized() Connection finished initializing?
salt.proxy.arista_pyeapi.ping() Connection open successfully?
salt.proxy.arista_pyeapi.shutdown(opts) Closes connection with the device.
salt.proxy.chronos Chronos Proxy minion for managing a Chronos cluster.
Dependencies • chronos execution module (salt.modules.chronos)
Pillar The chronos proxy configuration requires a 'base_url' property that points to the chronos endpoint:
proxy: proxytype: chronos base_url: http://my-chronos-master.mydomain.com:4400
salt.proxy.chronos.init(opts) Perform any needed setup.
salt.proxy.chronos.ping() Is the chronos api responding?
salt.proxy.chronos.shutdown(opts) For this proxy shutdown is a no-op
salt.proxy.cimc Proxy Minion interface module for managing Cisco Integrated Management Controller devices New in version 2018.3.0.
This proxy minion enables Cisco Integrated Management Controller devices (hereafter referred to as simply 'cimc' devices to be treated individually like a Salt Minion.
The cimc proxy leverages the XML API functionality on the Cisco Integrated Management Controller.  The Salt proxy must have access to the cimc on HTTPS (tcp/443).
Configuration To use this integration proxy module, please configure the following:
Pillar Proxy minions get their configuration from Salt's Pillar. Every proxy must have a stanza in Pillar and a reference in the Pillar top-file that matches the ID.
proxy: proxytype: cimc host: <ip or dns name of cimc host> username: <cimc username> password: <cimc password> verify_ssl: True
proxytype The proxytype key and value pair is critical, as it tells Salt which interface to load from the proxy directory in Salt's install hierarchy, or from /srv/salt/_proxy on the Salt Master (if you have created your own proxy module, for example). To use this cimc Proxy Module, set this to cimc.
host The location, or ip/dns, of the cimc host. Required.
username The username used to login to the cimc host. Required.
password The password used to login to the cimc host. Required.
salt.proxy.cimc.get_config_resolver_class(cid=None, hierarchical=False) The configResolveClass method returns requested managed object in a given class.
salt.proxy.cimc.grains() Get the grains from the proxied device
salt.proxy.cimc.grains_refresh() Refresh the grains from the proxied device
salt.proxy.cimc.init(opts) This function gets called when the proxy starts up.
salt.proxy.cimc.initialized() Since grains are loaded in many different places and some of those places occur before the proxy can be initialized, return whether our init() function has been called
salt.proxy.cimc.logon() Logs into the cimc device and returns the session cookie.
salt.proxy.cimc.logout(cookie=None) Closes the session with the device.
salt.proxy.cimc.ping() Returns true if the device is reachable, else false.
salt.proxy.cimc.prepare_return(x) Converts the etree to dict
salt.proxy.cimc.set_config_modify(dn=None, inconfig=None, hierarchical=False) The configConfMo method configures the specified managed object in a single subtree (for example, DN).
salt.proxy.cimc.shutdown() Shutdown the connection to the proxy device. For this proxy, shutdown is a no-op.
salt.proxy.cisconso Proxy Minion interface module for managing (practically) any network device with Cisco Network Services Orchestrator (Cisco NSO). Cisco NSO uses a series of remote polling agents, APIs and SSH commands to fetch network configuration and represent it in a data model.  PyNSO, the Python module used by this proxy minion does the task of converting native Python dictionaries into NETCONF/YANG syntax that the REST API for Cisco NSO can then use to set the configuration of the target network device.
Supported devices:
• A10 AX Series
• Arista 7150 Series
• Ciena 3000, 5000, ESM
• H3c S5800 Series
• Overture 1400, 2200, 5000, 5100, 6000
• Accedian MetroNID
• Avaya ERS 4000, SR8000, VSP 9000
Cisco: APIC-DC, ASA, IOS, IOS XE, IOS XR, er, ME-4600, NX OS, Prime Network Registrar, Quantum, StarOS, UCS ManagWSA
• Huawei: NE40E, quidway series, Enterprise Network Simulation Framework
• PaloAlto PA-2000, PA-3000, Virtualized Firewalls
• Adtran 900 Series
• Brocade ADX, MLX, Netiron, Vyatta
• Dell Force 10 Networking S-Series
• Infinera DTN-X Multi-Terabit Packet Optical Network Platform
• Pulsecom SuperG
• Adva 150CC Series
• CableLabs Converged Cable Access Platform
• Ericsson EFN324 Series, SE family
• Juniper: Contrail, EX, M, MX, QFX, SRX, Virtual SRX
• Quagga Routing Software
• Affirmed Networks
• Citrix Netscaler
• F5 BIG-IP
• NEC iPasolink
• Riverbed Steelhead Series
• Alcatel-Lucent 7XXX, SAM
• Clavister
• Fortinet
• Nominum DCS
• Sonus SBC 5000 Series
• Allied Telesys
• Open vSwitch
codeauthor Anthony Shaw <anthony.shaw@dimensiondata.com>
This proxy minion enables a consistent interface to fetch, control and maintain the configuration of network devices via a NETCONF-compliant control plane.  Cisco Network Services Orchestrator.
Dependencies • pynso Python module
PyNSO PyNSO can be installed via pip:
pip install pynso
Pillar Proxy minions get their configuration from Salt's Pillar. Every proxy must have a stanza in Pillar and a reference in the Pillar top-file that matches the ID. At a minimum for communication with the NSO host, the pillar should look like this:
proxy: proxytype: cisconso host: <ip or dns name of host> port: 8080 use_ssl: false username: <username> password: password
proxytype The proxytype key and value pair is critical, as it tells Salt which interface to load from the proxy directory in Salt's install hierarchy, or from /srv/salt/_proxy on the Salt Master (if you have created your own proxy module, for example). To use this Cisco NSO Proxy Module, set this to cisconso.
host The location, or IP/dns, of the Cisco NSO API host. Required.
username The username used to login to the Cisco NSO host, such as admin. Required.
passwords The password for the given user. Required.
use_ssl Whether to use HTTPS messaging to speak to the API.
port The port that the Cisco NSO API is running on, 8080 by default
Salt Proxy After your pillar is in place, you can test the proxy. The proxy can run on any machine that has network connectivity to your Salt Master and to the Cisco NSO host in question. SaltStack recommends that the machine running the salt-proxy process also run a regular minion, though it is not strictly necessary.
On the machine that will run the proxy, make sure there is an /etc/salt/proxy file with at least the following in it:
master: <ip or hostname of salt-master>
You can then start the salt-proxy process with:
salt-proxy --proxyid <id you want to give the host>
You may want to add -l debug to run the above in the foreground in debug mode just to make sure everything is OK.
Next, accept the key for the proxy on your salt-master, just like you would for a regular minion:
salt-key -a <id you gave the cisconso host>
You can confirm that the pillar data is in place for the proxy:
salt <id> pillar.items
And now you should be able to ping the Cisco NSO host to make sure it is responding:
salt <id> test.ping
salt.proxy.cisconso.apply_rollback(datastore, name) Apply a system rollback
salt.proxy.cisconso.get_data(datastore, path) Get the configuration of the device tree at the given path
• path (list of str OR tuple) -- The device path, a list of element names in order, comma separated
salt cisco-nso cisconso.get_data devices
salt.proxy.cisconso.get_rollback(name) Get the backup of stored a configuration rollback
salt.proxy.cisconso.get_rollbacks() Get a list of stored configuration rollbacks
salt.proxy.cisconso.grains() Get the grains from the proxy device.
salt.proxy.cisconso.init(opts)
salt.proxy.cisconso.ping() Check to see if the host is responding. Returns False if the host didn't respond, True otherwise.
salt cisco-nso test.ping
salt.proxy.cisconso.set_data_value(datastore, path, data) Get a data entry in a datastore
• path (list of str OR tuple) -- The device path to set the value at, a list of element names in order, comma separated
salt.proxy.cisconso.shutdown() Shutdown the connection to the proxy device. For this proxy, shutdown is a no-op.
salt.proxy.deltaproxy This is the "master" deltaproxy minion, known better as the control proxy because it controls all the deltaproxies underneath it.
salt.proxy.deltaproxy.grains() Make up some grains
salt.proxy.deltaproxy.grains_refresh() Refresh the grains
salt.proxy.deltaproxy.init(opts)
salt.proxy.deltaproxy.initialized() Since grains are loaded in many different places and some of those ws places occur before the proxy can be initialized, return whether our init() function has been called
salt.proxy.deltaproxy.ping() Degenerate ping
salt.proxy.deltaproxy.shutdown(opts) For this proxy shutdown is a no-op
salt.proxy.docker Docker Proxy Minion
depends docker
This proxy minion is just a shim to the docker executor, which will use the docker.call for everything except state runs.
To configure the proxy minion:
proxy: proxytype: docker name: festive_leakey
It is also possible to just name the proxy minion the same name as the container, and use grains to configure the proxy minion:
proxy: proxytype: docker name: {{grains['id']}}
name Name of the docker container
salt.proxy.docker.init(opts) Always initialize
salt.proxy.docker.initialized() This should always be initialized
salt.proxy.docker.module_executors() List of module executors to use for this Proxy Minion
salt.proxy.docker.shutdown(opts) Nothing needs to be done to shutdown
salt.proxy.dummy This is the a dummy proxy-minion designed for testing the proxy minion subsystem.
salt.proxy.dummy.fns() Method called by grains module.
salt.proxy.dummy.grains() Make up some grains
salt.proxy.dummy.grains_refresh() Refresh the grains
salt.proxy.dummy.init(opts) Required.  Can be used to initialize the server connection.
salt.proxy.dummy.initialized() Since grains are loaded in many different places and some of those places occur before the proxy can be initialized, return whether our init() function has been called
salt.proxy.dummy.package_install(name, **kwargs) Install a "package" on the REST server
salt.proxy.dummy.package_list() List "packages" installed on the REST server
salt.proxy.dummy.package_remove(name) Remove a "package" on the REST server
salt.proxy.dummy.package_status(name) Check the installation status of a package on the REST server
salt.proxy.dummy.ping() Degenerate ping
salt.proxy.dummy.service_list() List "services" on the REST server
salt.proxy.dummy.service_restart(name) Restart a "service" on the REST server
salt.proxy.dummy.service_start(name) Start a "service" on the dummy server
salt.proxy.dummy.service_status(name) Check if a service is running on the REST server
salt.proxy.dummy.service_stop(name) Stop a "service" on the dummy server
salt.proxy.dummy.shutdown(opts) For this proxy shutdown is a no-op
salt.proxy.dummy.test_from_state() Test function so we have something to call from a state :return:
salt.proxy.dummy.upgrade() "Upgrade" packages
salt.proxy.dummy.uptodate() Call the REST endpoint to see if the packages on the "server" are up to date.
salt.proxy.esxcluster Proxy Minion interface module for managing VMWare ESXi clusters.
Dependencies • pyVmomi
• jsonschema
Pillar Proxy minions get their configuration from Salt's Pillar. This can now happen from the proxy's configuration file.
Example pillars:
userpass mechanism:
proxy: proxytype: esxcluster cluster: <cluster name> datacenter: <datacenter name> vcenter: <ip or dns name of parent vcenter> mechanism: userpass username: <vCenter username> passwords: (required if userpass is used) - first_password - second_password - third_password
sspi mechanism:
proxy: proxytype: esxcluster cluster: <cluster name> datacenter: <datacenter name> vcenter: <ip or dns name of parent vcenter> mechanism: sspi domain: <user domain> principal: <host kerberos principal>
proxytype To use this Proxy Module, set this to esxdatacenter.
cluster Name of the managed cluster. Required.
datacenter Name of the datacenter the managed cluster is in. Required.
vcenter The location of the VMware vCenter server (host of ip) where the datacenter should be managed. Required.
mechanism The mechanism used to connect to the vCenter server. Supported values are userpass and sspi. Required.
NOTE: Connections are attempted using all (username, password) combinations on proxy startup.
username The username used to login to the host, such as root. Required if mechanism is userpass.
passwords A list of passwords to be used to try and login to the vCenter server. At least one password in this list is required if mechanism is userpass. When the proxy comes up, it will try the passwords listed in order.
domain User domain. Required if mechanism is sspi.
principal Kerberos principal. Rquired if mechanism is sspi.
protocol If the ESXi host is not using the default protocol, set this value to an alternate protocol. Default is https.
Salt Proxy After your pillar is in place, you can test the proxy. The proxy can run on any machine that has network connectivity to your Salt Master and to the vCenter server in the pillar. SaltStack recommends that the machine running the salt-proxy process also run a regular minion, though it is not strictly necessary.
To start a proxy minion one needs to establish its identity <id>:
salt-proxy --proxyid <proxy_id>
On the machine that will run the proxy, make sure there is a configuration file present. By default this is /etc/salt/proxy. If in a different location, the <configuration_folder> has to be specified when running the proxy: file with at least the following in it:
salt-proxy --proxyid <proxy_id> -c <configuration_folder>
Commands Once the proxy is running it will connect back to the specified master and individual commands can be runs against it:
# Master - minion communication salt <cluster_name> test.ping
# Test vcenter connection salt <cluster_name> vsphere.test_vcenter_connection
States Associated states are documented in salt.states.esxcluster.  Look there to find an example structure for Pillar as well as an example .sls file for configuring an ESX cluster from scratch.
salt.proxy.esxcluster.find_credentials() Cycle through all the possible credentials and return the first one that works.
salt.proxy.esxcluster.get_details() Function that returns the cached details
salt.proxy.esxcluster.init(opts) This function gets called when the proxy starts up. For login the protocol and port are cached.
salt.proxy.esxcluster.ping() Returns True.
salt esx-cluster test.ping
salt.proxy.esxcluster.shutdown() Shutdown the connection to the proxy device. For this proxy, shutdown is a no-op.
salt.proxy.esxdatacenter Proxy Minion interface module for managing VMWare ESXi clusters.
proxy: proxytype: esxdatacenter datacenter: <datacenter name> vcenter: <ip or dns name of parent vcenter> mechanism: userpass username: <vCenter username> passwords: (required if userpass is used) - first_password - second_password - third_password
proxy: proxytype: esxdatacenter datacenter: <datacenter name> vcenter: <ip or dns name of parent vcenter> mechanism: sspi domain: <user domain> principal: <host kerberos principal>
datacenter Name of the managed datacenter. Required.
# Master - minion communication salt <datacenter_name> test.ping
# Test vcenter connection salt <datacenter_name> vsphere.test_vcenter_connection
States Associated states are documented in salt.states.esxdatacenter.  Look there to find an example structure for Pillar as well as an example .sls file for configuring an ESX datacenter from scratch.
salt.proxy.esxdatacenter.find_credentials() Cycle through all the possible credentials and return the first one that works.
salt.proxy.esxdatacenter.get_details() Function that returns the cached details
salt.proxy.esxdatacenter.init(opts) This function gets called when the proxy starts up.  All login details are cached.
salt.proxy.esxdatacenter.ping() Returns True.
salt dc_id test.ping
salt.proxy.esxdatacenter.shutdown() Shutdown the connection to the proxy device. For this proxy, shutdown is a no-op.
salt.proxy.esxi Proxy Minion interface module for managing VMware ESXi hosts.
Special Note: SaltStack thanks Adobe Corporation for their support in creating this Proxy Minion integration.
This proxy minion enables VMware ESXi (hereafter referred to as simply 'ESXi') hosts to be treated individually like a Salt Minion.
Since the ESXi host may not necessarily run on an OS capable of hosting a Python stack, the ESXi host can't run a Salt Minion directly. Salt's "Proxy Minion" functionality enables you to designate another machine to host a minion process that "proxies" communication from the Salt Master. The master does not know nor care that the target is not a "real" Salt Minion.
The 5.5.0.2014.1.1 is a known stable version that this original ESXi State Module was developed against.
Pillar Proxy minions get their configuration from Salt's Pillar. Every proxy must have a stanza in Pillar and a reference in the Pillar top-file that matches the ID. At a minimum for communication with the ESXi host, the pillar should look like this:
proxy: proxytype: esxi host: <ip or dns name of esxi host> username: <ESXi username> passwords: - first_password - second_password - third_password credstore: <path to credential store>
This also allows you to use any number of potential fallback passwords.
This scenario is especially true, and even slower, when the proxy minion first starts. If the correct password is not the first password on the list, it may take up to a minute for test.ping to respond with a True result. Once the initial authorization is complete, the responses for commands will be a little faster.
credstore If the ESXi host is using an untrusted SSL certificate, set this value to the file path where the credential store is located. This file is passed to esxcli. Default is <HOME>/.vmware/credstore/vicredentials.xml on Linux and <APPDATA>/VMware/credstore/vicredentials.xml on Windows.
NOTE: HOME variable is sometimes not set for processes running as system services. If you want to rely on the default credential store location, make sure HOME is set for the proxy process.
Salt Proxy After your pillar is in place, you can test the proxy. The proxy can run on any machine that has network connectivity to your Salt Master and to the ESXi host in question. SaltStack recommends that the machine running the salt-proxy process also run a regular minion, though it is not strictly necessary.
salt-key -a <id you gave the esxi host>
And now you should be able to ping the ESXi host to make sure it is responding:
At this point you can execute one-off commands against the host. For example, you can get the ESXi host's system information:
salt <id> esxi.cmd system_info
Note that you don't need to provide credentials or an ip/hostname. Salt knows to use the credentials you stored in Pillar.
It's important to understand how this particular proxy works. Salt.modules.vsphere is a standard Salt execution module. If you pull up the docs for it you'll see that almost every function in the module takes credentials and a target host. When credentials and a host aren't passed, Salt runs commands through pyVmomi against the local machine. If you wanted, you could run functions from this module on any host where an appropriate version of pyVmomi is installed, and that host would reach out over the network and communicate with the ESXi host.
esxi.cmd acts as a "shim" between the execution module and the proxy. Its first parameter is always the function from salt.modules.vsphere. If the function takes more positional or keyword arguments you can append them to the call. It's this shim that speaks to the ESXi host through the proxy, arranging for the credentials and hostname to be pulled from the Pillar section for this Proxy Minion.
States Associated states are thoroughly documented in salt.states.esxi. Look there to find an example structure for Pillar as well as an example .sls file for standing up an ESXi host from scratch.
salt.proxy.esxi.ch_config(cmd, *args, **kwargs) This function is called by the salt.modules.esxi.cmd shim.  It then calls whatever is passed in cmd inside the salt.modules.vsphere module.  Passes the return through from the vsphere module.
cmd    The command to call inside salt.modules.vsphere
args   Arguments that need to be passed to that command.
kwargs Keyword arguments that need to be passed to that command.
salt.proxy.esxi.find_credentials(host) Cycle through all the possible credentials and return the first one that works.
salt.proxy.esxi.get_details() Return the proxy details
salt.proxy.esxi.grains() Get the grains from the proxy device.
salt.proxy.esxi.grains_refresh() Refresh the grains from the proxy device.
salt.proxy.esxi.init(opts) This function gets called when the proxy starts up. For ESXi devices, the host, login credentials, and, if configured, the protocol and port are cached.
salt.proxy.esxi.is_connected_via_vcenter()
salt.proxy.esxi.ping() Returns True if connection is to be done via a vCenter (no connection is attempted).  Check to see if the host is responding when connecting directly via an ESXi host.
salt esxi-host test.ping
salt.proxy.esxi.shutdown() Shutdown the connection to the proxy device. For this proxy, shutdown is a no-op.
salt.proxy.esxvm Proxy Minion interface module for managing VMWare ESXi virtual machines.
proxy: proxytype: esxvm datacenter: <datacenter name> vcenter: <ip or dns name of parent vcenter> mechanism: userpass username: <vCenter username> passwords: (required if userpass is used) - first_password - second_password - third_password
proxy: proxytype: esxvm datacenter: <datacenter name> vcenter: <ip or dns name of parent vcenter> mechanism: sspi domain: <user domain> principal: <host kerberos principal>
proxytype To use this Proxy Module, set this to esxvm.
datacenter Name of the datacenter where the virtual machine should be deployed. Required.
vcenter The location of the VMware vCenter server (host of ip) where the virtual machine should be managed. Required.
domain User realm domain. Required if mechanism is sspi.
# Master - minion communication salt <proxy_id> test.ping
# Test vcenter connection salt <proxy_id> vsphere.test_vcenter_connection
States Associated states are documented in salt.states.esxvm.  Look there to find an example structure for Pillar as well as an example .sls file for configuring an ESX virtual machine from scratch.
salt.proxy.esxvm.find_credentials() Cycle through all the possible credentials and return the first one that works.
salt.proxy.esxvm.get_details() Function that returns the cached details
salt.proxy.esxvm.init(opts) This function gets called when the proxy starts up. For login the protocol and port are cached.
salt.proxy.esxvm.ping() Returns True.
salt esx-vm test.ping
salt.proxy.esxvm.shutdown() Shutdown the connection to the proxy device. For this proxy, shutdown is a no-op.
salt.proxy.fx2 Dell FX2 chassis New in version 2015.8.2.
Proxy minion interface module for managing Dell FX2 chassis (Dell Chassis Management Controller version 1.2 and above, iDRAC8 version 2.00 and above)
Dependencies • iDRAC Remote execution module (salt.modules.dracr)
• Chassis command shim (salt.modules.chassis)
• Dell Chassis States (salt.states.dellchassis)
• Dell's racadm command line interface to CMC and iDRAC devices.
Special Note: SaltStack thanks Adobe Corporation for their support in creating this proxy minion integration.
This proxy minion enables Dell FX2 and FX2s (hereafter referred to as simply "chassis", "CMC", or "FX2") chassis to be treated individually like a salt-minion.
Since the CMC embedded in the chassis does not run an OS capable of hosting a Python stack, the chassis can't run a minion directly.  Salt's "Proxy Minion" functionality enables you to designate another machine to host a minion process that "proxies" communication from the salt-master. The master does not know nor care that the target is not a real minion.
To configure this integration, follow these steps:
Pillar Proxy minions get their configuration from Salt's Pillar.  Every proxy must have a stanza in Pillar, and a reference in the Pillar topfile that matches the ID.  At a minimum for communication with the chassis the pillar should look like this:
proxy: host: <ip or dns name of chassis controller> admin_username: <iDRAC username for the CMC, usually 'root'> fallback_admin_username: <username to try if the first fails> passwords: - first_password - second_password - third-password proxytype: fx2
The proxytype line above is critical, it tells Salt which interface to load from the proxy directory in Salt's install hierarchy, or from /srv/salt/_proxy on the salt-master (if you have created your own proxy module, for example).
The proxy integration will try the passwords listed in order.  It is configured this way so you can have a regular password, a potential fallback password, and the third password can be the one you intend to change the chassis to use.  This way, after it is changed, you should not need to restart the proxy minion--it should just pick up the third password in the list.  You can then change pillar at will to move that password to the front and retire the unused ones.
Beware, many Dell CMC and iDRAC units are configured to lockout IP addresses or users after too many failed password attempts.  This can generate user panic in the form of "I no longer know what the password is!!!".  To mitigate panic try the web interface from a different IP, or setup a emergency administrator user in the CMC before doing a wholesale password rotation.
The automatic lockout can be disabled via Salt with the following:
salt <cmc> chassis.cmd set_general cfgRacTuning cfgRacTuneIpBlkEnable 0
and then verified with
salt <cmc> chassis.cmd get_general cfgRacTuning cfgRacTuneIpBlkEnable
salt-proxy After your pillar is in place, you can test the proxy.  The proxy can run on any machine that has network connectivity to your salt-master and to the chassis in question.  SaltStack recommends that this machine also run a regular minion, though it is not strictly necessary.
You can start the proxy with
salt-proxy --proxyid <id you want to give the chassis>
salt-key -a <id you want to give the chassis>
And now you should be able to ping the chassis to make sure it is responding:
At this point you can execute one-off commands against the chassis.  For example, you can get the chassis inventory:
salt <id> chassis.cmd inventory
Note that you don't need to provide credentials or an ip/hostname.  Salt knows to use the credentials you stored in Pillar.
It's important to understand how this particular proxy works. Salt.modules.dracr is a standard Salt execution module.  If you pull up the docs for it you'll see that almost every function in the module takes credentials and a target host.  When credentials and a host aren't passed, Salt runs racadm against the local machine.  If you wanted you could run functions from this module on any host where an appropriate version of racadm is installed, and that host would reach out over the network and communicate with the chassis.
Chassis.cmd acts as a "shim" between the execution module and the proxy. Its first parameter is always the function from salt.modules.dracr to execute.  If the function takes more positional or keyword arguments you can append them to the call.  It's this shim that speaks to the chassis through the proxy, arranging for the credentials and hostname to be pulled from the pillar section for this proxy minion.
Because of the presence of the shim, to lookup documentation for what functions you can use to interface with the chassis, you'll want to look in salt.modules.dracr instead of salt.modules.chassis.
States Associated states are thoroughly documented in salt.states.dellchassis. Look there to find an example structure for pillar as well as an example .sls file for standing up a Dell Chassis from scratch.
salt.proxy.fx2.admin_password() Return the admin_password in the DETAILS dictionary, or 'calvin' (the Dell default) if there is none present
salt.proxy.fx2.admin_username() Return the admin_username in the DETAILS dictionary, or root if there is none present
salt.proxy.fx2.chconfig(cmd, *args, **kwargs) This function is called by the salt.modules.chassis.cmd shim.  It then calls whatever is passed in cmd inside the salt.modules.dracr module.
• cmd -- The command to call inside salt.modules.dracr
• args -- Arguments that need to be passed to that command
• kwargs -- Keyword arguments that need to be passed to that command
Returns Passthrough the return from the dracr module.
salt.proxy.fx2.find_credentials() Cycle through all the possible credentials and return the first one that works
salt.proxy.fx2.grains() Get the grains from the proxied device
salt.proxy.fx2.grains_refresh() Refresh the grains from the proxied device
salt.proxy.fx2.host()
salt.proxy.fx2.init(opts) This function gets called when the proxy starts up.  We check opts to see if a fallback user and password are supplied.  If they are present, and the primary credentials don't work, then we try the backup before failing.
Whichever set of credentials works is placed in the persistent DETAILS dictionary and will be used for further communication with the chassis.
salt.proxy.fx2.ping() Is the chassis responding?
Returns Returns False if the chassis didn't respond, True otherwise.
salt.proxy.fx2.shutdown(opts) Shutdown the connection to the proxied device.  For this proxy shutdown is a no-op.
salt.proxy.junos Interface with a Junos device via proxy-minion. To connect to a junos device via junos proxy, specify the host information in the pillar in '/srv/pillar/details.sls'
proxy: proxytype: junos host: <ip or dns name of host> username: <username> port: 830 password: <secret>
In '/srv/pillar/top.sls' map the device details with the proxy name.
base: 'vmx': - details
After storing the device information in the pillar, configure the proxy in '/etc/salt/proxy'
Run the salt proxy via the following command:
salt-proxy --proxyid=vmx
class salt.proxy.junos.RebootActive(**kwargs) Class to get static variable, to indicate when a reboot/shutdown is being processed and the keep_alive should not probe the connection since it interferes with the shutdown process.
reboot_shutdown = False
salt.proxy.junos.alive(opts) Validate and return the connection status with the remote device.
salt.proxy.junos.conn()
salt.proxy.junos.get_reboot_active()
salt.proxy.junos.get_serialized_facts()
salt.proxy.junos.init(opts) Open the connection to the Junos device, login, and bind to the Resource class
salt.proxy.junos.initialized()
salt.proxy.junos.ping() Ping?  Pong!
salt.proxy.junos.proxytype() Returns the name of this proxy
salt.proxy.junos.reboot_active()
salt.proxy.junos.reboot_clear()
salt.proxy.junos.shutdown(opts) This is called when the proxy-minion is exiting to make sure the connection to the device is closed cleanly.
salt.proxy.marathon Marathon Proxy minion for managing a Marathon cluster.
Dependencies • marathon execution module (salt.modules.marathon)
Pillar The marathon proxy configuration requires a 'base_url' property that points to the marathon endpoint:
proxy: proxytype: marathon base_url: http://my-marathon-master.mydomain.com:8080
salt.proxy.marathon.init(opts) Perform any needed setup.
salt.proxy.marathon.ping() Is the marathon api responding?
salt.proxy.marathon.shutdown(opts) For this proxy shutdown is a no-op
salt.proxy.napalm NAPALM: Network Automation and Programmability Abstraction Layer with Multivendor support New in version 2016.11.0.
Proxy minion for managing network devices via NAPALM library.
Dependencies The napalm proxy module requires NAPALM library to be installed:  pip install napalm Please check Installation for complete details.
NOTE: Beginning with Salt release 2017.7.3, it is recommended to use napalm >= 2.0.0. The library has been unified into a monolithic package, as in opposite to separate packages per driver. For more details you can check this document.  While it will still work with the old packages, bear in mind that the NAPALM core team will maintain only the main napalm package.
Moreover, for additional capabilities, the users can always define a library that extends NAPALM's base capabilities and configure the provider option (see below).
Pillar The napalm proxy configuration requires the following parameters in order to connect to the network device:
driver Specifies the network device operating system.  For a complete list of the supported operating systems please refer to the NAPALM Read the Docs page.
host   The IP Address or FQDN to use when connecting to the device. Alternatively, the following field names can be used instead: hostname, fqdn, ip.
username The username to be used when connecting to the device.
passwd The password needed to establish the connection.
NOTE: This field may not be mandatory when working with SSH-based drivers, and the username has a SSH key properly configured on the device targeted to be managed.
optional_args Dictionary with the optional arguments.  Check the complete list of supported optional arguments.
always_alive: True In certain less dynamic environments, maintaining the remote connection permanently open with the network device is not always beneficial. In that case, the user can select to initialize the connection only when needed, by specifying this field to false. Default: true (maintains the connection with the remote network device).
provider: napalm_base The library that provides the get_network_device function.  This option is useful when the user has more specific needs and requires to extend the NAPALM capabilities using a private library implementation.  The only constraint is that the alternative library needs to have the get_network_device function available.
New in version 2017.7.1.
multiprocessing: False Overrides the multiprocessing option, per proxy minion.  The multiprocessing option must be turned off for SSH-based proxies. However, some NAPALM drivers (e.g. Arista, NX-OS) are not SSH-based.  As multiple proxy minions may share the same configuration file, this option permits the configuration of the multiprocessing option more specifically, for some proxy minions.
New in version 2017.7.2.
Proxy pillar file example:
proxy: proxytype: napalm driver: junos host: core05.nrt02 username: my_username passwd: my_password optional_args: port: 12201
Example using a user-specific library, extending NAPALM's capabilities, e.g. custom_napalm_base:
proxy: proxytype: napalm driver: ios fqdn: cr1.th2.par.as1234.net username: salt password: '' provider: custom_napalm_base
• NAPALM grains: select network devices based on their characteristics
• NET module: network basic features
• Network config state: Manage the configuration using arbitrary templates
• NAPALM YANG state: Manage the configuration according to the YANG models (OpenConfig/IETF)
• Network ACL module: Generate and load ACL (firewall) configuration
• Network ACL state: Manage the firewall configuration
• NTP operational and configuration management module
• BGP operational and configuration management module
• Routes details
• SNMP configuration module
• Users configuration management
NOTE: Beginning with release codename 2019.2.0, any NAPALM command executed when running under a NAPALM Proxy Minion supports the force_reconnect magic argument.
Proxy Minions generally establish a connection with the remote network device at the time of the Minion startup and that connection is going to be used forever.