Tech Musings

Software Patching – Jamf and Installomator with a Twist

Sean Noble's photo
Sean Noble
·

4 min read

In an effort to begin patching some of the more common software applications, I have been searching for options that will help automate this task. During JNUC 2021, I came across an incredible session that introduced me to Installomator. In a nutshell, Installomator is a script that runs on a local machine that patches commonly used software. It has 340 software titles in its library as of this writing, with more being added frequently.

The Problem and Goal

The age-old problem of keeping software up to date was always burning in the back of my head, but a recent addition to our security team forced it toward the forefront of my attention.

Our goal seemed simple. At a high level:

  1. Notify users if they have out of date software.

  2. Give users an opportunity to install the update themselves.

  3. Force the update to install after a specific period of time.

Now…the nitty gritty requirements:

  1. Notify users if they have out of date software, but only if it is currently open/running. If the software title is closed, don’t notify the user at all, just patch it!

  2. Give users an opportunity to install the update themselves, but allow them to save their work before installing the update, because the application would reboot.

  3. Force the update to install after a specific period of time.

Out of the box, Installomator meets the high-level requirements, but we started to get inundated with software update prompts as we were testing Firefox’s patch management cycle. They release a lot of updates! We decided we only wanted to notify the user if the application was open. Well… that’s great, except the user notification (and subsequent deferral options) are tied to the Jamf policy and not Installomator. So, I had to get creative. In today’s example, we’re going to patch Firefox.

Policy/Script #1 – Patch Management – Firefox (Notify)

First, I needed to create a script that executes Installomator with different arguments than the defaults. I named this script ExecuteInstallomator.sh. I didn’t want to maintain two different Installomator scripts on the JSS, so this one just downloads the latest version from GitHub and passes the arguments that way.

#!/bin/zsh

wget -P /Library/Application\ Support/JAMF/tmp https://github.com/Installomator/Installomator/blob/dev/Installomator.sh --no-check-certificate
chmod +x Installomator.sh
/Library/Application\ Support/JAMF/tmp/Installomator.sh $appName NOTIFY=success BLOCKING_PROCESS_ACTION=prompt_user_then_kill REOPEN="yes"

Then, I created a Jamf policy that I called Patch Management - Notifications.

  • Display Name: Patch Management – Notify

  • Trigger: Custom > patchmanagement_notify

  • Execution Frequency: Ongoing

  • Script: ExecuteInstallomator.sh

  • Maintenance: Update Inventory

  • Scope: All computers

Policy/Script #2 – Installomator

First, I needed to make some modifications to the Installomator script, because I wanted Installomator to do different things if the application is open or closed. I used the silent_fail action as a trigger to a Jamf policy created above.

  1. Line 26: DEBUG=0

  2. Line 29: NOTIFY=silent

  3. Line 37: BLOCKING_PROCESS_ACTION=silent_fail

  4. Line 99: REOPEN="no"

  5. On line 481, which is where Installomator gets told what to do if an app is open in the silent_fail section, I modified the line that says
    cleanupAndExit 12 "blocking process '$x' found, aborting"

    to say

    cleanupAndExit 12 "blocking process '$x' found, starting Patch Management - Notify Jamf policy."

  6. I added a line above line 481 that says /usr/local/bin/jamf policy -event patchmanagement_notify

  7. Line 3741 (below the # create temporary working directory line): : scriptDir=$(dirname "$0")

Then, I created a Jamf policy that I called Patch Management - Firefox.

  • Display Name: Patch Management – Firefox

  • Trigger: Recurring Check-in

  • Execution Frequency: Ongoing

  • Script: Installomator (with variable 4 set as firefox)

  • Maintenance: Update Inventory

  • Scope: Member of Patch Management – Firefox – Out of date (this scope choice is outlined here in the Policy section)

The End Result

Once this is all configured, we tested machines running various old, outdated versions of Firefox (from 63 to 94), knowing that 94.0.1 was the latest build.

If a managed application appears out of date, and the application is not presently open, the application will update in the background without user intervention or notification.

If a managed application appears out of date, and the application is currently open, a dialog box will appear notifying you that an update is available. You can install the update now, or you can defer it until a later time for a maximum of 5 days.

If you choose to install the update, you will be reminded that the application needs to quit. Choose Quit and Update to continue.

Once the update is complete, you’ll see a notification and the application will reopen automatically.

jamfmacOSpatchmanagement