saltstack/salt
1
0
Fork 0
mirror of https://github.com/saltstack/salt.git synced 2025-04-17 10:10:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2
salt/doc/topics/releases/includes/proxy-2015.8.0.rst
Jacob Hammons 701f47a658 Added rst source for salt-proxy man page, added build and copy lines for this man page to doc/conf.py and setup.py 
Added salt-proxy release notes topic
Added note to pip state for Refs #21845
Regenerated and versioned man pages
2015-09-01 17:09:35 -06:00

3.1 KiB
Raw Blame History

Proxy Minion Enhancements

Proxy Minions have undergone a significant overhaul in 2015.8.

  • Proxies are now more of a first-class citizen in the Salt universe
  • Proxies are no longer started by a "parent minion", they are started on the command line with the new salt-proxy command
  • The default configuration file for proxies is now /etc/salt/proxy.
  • The default logfile for proxies is now /var/log/salt/proxy.
  • salt-proxy takes a --proxyid switch. This becomes the id of the proxy minion, and thus the pillar key under which the configuration for the proxy is looked up.
  • Proxies have been lightly tested with the new TCP transport. They still do not work with the RAET transport.
  • The pillar structure is therefore different than in previous releases. In earlier releases you might have something that looked like this:

/srv/pillar/top.sls:

base:
  minioncontroller:
    - dumbdevice1
    - dumbdevice2

/srv/pillar/dumbdevice1.sls:

dumbdevice1:
  proxy:
    proxytype: networkswitch
    host: 172.23.23.5
    username: root
    passwd: letmein

/srv/pillar/dumbdevice2.sls:

dumbdevice2:
  proxy:
    proxytype: networkswitch
    host: 172.23.23.6
    username: root
    passwd: letmein

This would cause the minion with id minioncontroller to fork off two processes and rename their minion id's to dumbdevice1 and dumbdevice2. These processes would initiate a new connection to the master.

For proxy minion controllers this made it quite difficult to tell which process was doing what. Also, if the controlling minion died for any reason, it would take all the proxies with it. The new pillar structure does away with the id's in the lower level pillar files and brings proxy configuration to the same level with all other minions.

/srv/pillar/top.sls:

base:
  dumbdevice1:
    - dumbdevice1
  dumbdevice2:
    - dumbdevice2

/srv/pillar/dumbdevice1.sls:

proxy:

proxytype: networkswitch host: 172.23.23.5 username: root passwd: letmein

/srv/pillar/dumbdevice2.sls:

proxy:

proxytype: networkswitch host: 172.23.23.6 username: root passwd: letmein

Proxies can be better tracked via system process utilities:

..code-block:: bash

root@raring64:/var/log/salt# ps guax | grep p8 root 15215 pts/3 S+ 10:57 0:00 python salt-proxy -l debug --proxyid=p8000 root 15275 pts/5 S+ 10:57 0:00 python salt-proxy -l debug --proxyid=p8002

Proxies still gather a significant number of grains from the host. This is useful for targeting, but does not obviate the need for custom grains to better support your controlled devices. See the proxy documentation for writing grains modules for your proxy.

Future enhancements of proxy minions could include execution modules and states for easier proxy process management.

See Proxy Minion Documentation <proxy-minion>.