One way to update NoMAD

Now that I have a few people "in the wild" (nomads, if you will…) using NoMAD in our environment, I needed to find a way to install updates that played nicely with the app as its running. If you install and have NoMAD create its LaunchAgent in the user Library (as opposed to the system Library) the LaunchAgent needs to be unloaded prior to running the installer for the new version. Part of the fun of this, especially if managing with an MDM like Jamf, is that Jamf runs as root while the LaunchAgent is in the user's Library. You have to tell Jamf to run launchctl in the correct user context for action to happen in the user's environment.

Fortunately for me, this is something I've been coming across quite a bit recently and have learned a few handy tricks from other Mac admins out there. I knew based on my manual updates/testing that the order of operations needed to be something like this:

1. Unload ~/Library/LaunchAgents/com.trusourcelabs.NoMAD.plist
2. Run installer.
3. Load ~/Library/LaunchAgents/com.trusourcelabs.NoMAD.plist

I figured that this would be best accomplished running one script, with the script itself calling a second policy in the JSS on a custom trigger that contains the installer .pkg. 

A 10000 ft view of the workflow goes something like this:

1. update_NoMAD.sh runs on policy1, scoped to computers with NoMAD installed.
2. update_NoMAD.sh triggers policies using update_nomad, this policy2 contains the installer pkg.
3. update_NoMAD.sh finishes running and at the end NoMAD has quietly closed the old version, updated, and launches the new version.

On the policy page, they look a little something like this:

In terms of the update_NoMAD.sh script, this is what I am using:

To break down the script a bit:

• Lines 27–30 get the current user, user ID, and OS information. This is required for the commands needed to run launchctl correctly in the user context based on what OS the user's machine is running.
• Lines 33–42 unload the LaunchAgent using either bsexec or asuser based on what is the correct method for the target OS.
• Lines 45–46 are what call policy2 in the JSS on the custom trigger
• Lines 49–58 load the LaunchAgent after the installer finishes running (from policy2)

The end result should be* a rather quiet and seamless update to NoMAD in the background. If this happens run in the exact moment that someone is using the menubar it may quick unexpectedly on them, so if you are really training folks to use NoMAD an email heads-up that it's being updated might be a good idea. This also works well via Self Service.

As always, ymmv, and test thoroughly before deploying in your production environment.

Did you find this post useful? Leave me a tip!
💖