Part 3:


The next steps on my journey with VMware vRealize SaltStack Config as a Windows Server Admin will be beacons and reactors. Working with Jobs helped me understand how to make changes Ad-Hoc. I have a Job to quickly stop the Print Spooler but what if I always want the state of the Print Spooler Service to be stopped. How do I NOT allow a Server Admin to login into the server and manually start the service?

This is where beacons and reactors work with minion configurations that you want to make permanent. This is the configuration Management Part of Salt Stack. To always make sure a Windows Service is stopped I created a beacon.conf file. On a Windows Server the Beacon.conf needs to be in the ‘C:\salt\conf\minion.d' folder. Anytime a beacon.conf file is added to a minion or modified the salt-minion service needs restarted. I have a salt Job to restart the salt-minion service.

Beacons:

Beacon File: Sends events to the event bus on the salt master from a minion

This beacon.conf example is for service state changes. The Beacon sends an event to the salt master if a Windows Service is started/stopped.

beacons:
  service:
    - services:
       Spooler:
         onchangeonly: true

This is what the event will look like in the events if you are monitoring.

salt/beacon/DBH-211/service/Spooler     {
    "Spooler": {
        "running": true
    },
    "_stamp": "2021-08-06T11:53:57.212810",
    "id": "DBH-211",
    "service_name": "Spooler"
}

Reactors:

Reactor File: Monitors the event bus for events specified. IE: salt/beacon/*/service/Spooler

reactor:
  - 'salt/auth':                              # React to a new minion
    - salt://reactor/accept-key.sls           # Run this state to auto accept new minion
  - 'salt/beacon/*/service/Spooler':          # React to Spooler Service Change
    - salt://vCROCS/spooler_auto_stop.sls     # Run this state

How the beacons and reactors work together:
# What this line is doing in the reactor is watching for an beacon event from any minion
# The * means all minions. You could specify a minion name.
# Looking for service events.  
# The service event that is specified is the Spooler event.

  - 'salt/beacon/*/service/Spooler'


# This is the event sent from the beacon to the event bus

salt/beacon/DBH-211/service/Spooler

# What the reactor is looking for and what the beacon sent matches.
# The state specified in the reactor will now run
# This is the state specified in my example

    - salt://vCROCS/spooler_auto_stop.sls

State File:

State File: Stops the Spooler Service if it was started

{% if data['Spooler']['running'] == true %}
stop_service:
  local.service.stop:
    - tgt: {{ data['id'] }}
    - arg:
      - Spooler
{% endif %}

State File: Starts the Spooler Service if it was stopped

{% if data['Spooler']['running'] == False %}
start_service:
  local.service.start:
    - tgt: {{ data['id'] }}
    - arg:
      - Spooler
{% endif %}

Beacons:

To copy the beacon file to the minions I created a Job that I can manually run.

Job to copy a file to a minion:

Click Here to see Larger Image of Screen Shot

After the beacon file is copied to the minion you MUST restart the minion service.

Job to restart minion service:

Click Here to see Larger Image of Screen Shot

Lessons Learned:
  • Beacons are a good way to make sure the configuration you want is not altered.
  • Beacons can monitor more than just services that I am showing in this blog post. I will cover more use cases in future blog posts.


When I write about vRealize Automation (“vRA”) I always say there are many ways to accomplish the same task. SaltStack Config is the same way. I am showing what I felt was important to see but every organization/environment will be different. There is no right or wrong way to use Salt. This is a GREAT Tool that is included with your vRealize Suite Advanced/Enterprise license. If you own the vRealize Suite, you own SaltStack Config.

Last Update: 08/27/2021