Author: Greg Althaus
Level: Intro
Time: 5 minutes
As a technical operations leader, you’re developing your latest system audit script. You need to run it on all your systems. Of course, security says weekly. If only you could deploy that script into your automation tool and run that at a daily interval. Take that security team! This will keep security off your back and give you a good bill of health on compliance. If only triggering work orders to audit systems was something we could do to run that script.
RackN Digital Rebar Triggers
Well, that is where the humble Digital Rebar Trigger comes in. In the simplest terms, the trigger takes an input (an event, a json blob, a timer firing, or one of many other integration points), plucks data from that item and itself, to generate the execution of a set of tasks on a runner.
A pretty nebulous description. Let’s pull it apart with some examples, a timer-based trigger, an event-based trigger, and a ux based trigger.
Using a timer to trigger work orders
In the default content provided by the task-library content pack, there is a trigger called utility-endpoint-systems-check. This funny sounding trigger runs a timer that fires at 4:30a and 4:30p every day.
The trigger when fired will run a blueprint (a helper object that defines a bunch of tasks) that checks to see if the password has been changed from the default, builds an inventory update on the drp endpoint, and checks to see if disk space is running low.
These tests generate alerts for the administrator to be notified that something is not right. This trigger creates a work order for the DRP endpoint to run. The rest of the system handles the magic to do the work and report the results.
This sounds like a great way to run that audit script we need to schedule against all our machines daily. A few quick additions from the example above and our audit script is generating alerts on failing machines.
Using a trigger after a content pack update
Another example trigger watches DRP’s own event stream to trigger a work order. In the drp-community-content content pack, there is a trigger that watches events for updates to that very same content pack.
This trigger fires a work order that runs a blueprint that will cause the system to rerun the DRP endpoint bootstrap process. This is used to automatically update things like sledgehammer and other components that might need to be updated because the content pack changed. This is an example of an admin helper trigger that facilitates DRP readiness.
Let’s jump back to our audit script, the script should be in a repository so we can track changes and make sure we have the latest scripts deployed at the best version. When you make changes to that script, you could have your change control system generate an event (check out the gitlab integration that is already there) that pulls in the code, builds it into a content pack, and deploys that to the DRP endpoint.
Really advanced use cases would use Multi-site manager and version sets to roll the change out to the whole DRP fabric. (Another fun topic for discussion). IaC built in so that you can show security what you are running.
User-triggered triggers
The last example of a trigger is a user-triggered trigger. In the dev-library content pack, the dev-ux-button trigger provides an example of how to extend the UX generate a work order to whatever work you need done. This could be starting a process for auditing machines, testing event or timer triggers that are hard to generate, or consolidating a set of actions into a single start point.
This works for your audit script too! Snap audits or emergency threat assessments could be triggered by these user-defined triggers to generate an immediate audit or a subset audit to meet a surprise issue.
Make it reusable
In a future port, we’ll talk about where and how these tasks get run, but this was to mostly focus on the trigger as the starting point. More information can be found at:
DRP Lab on automating triggers
Go checkout triggers and remember, Make It Reusable.
