Skip to main content

Wondering if anyone else has looked to use Yo to do their own version of Patch Management notifications to alert users an app needs quit in order to update.

The upper management at our University isn't a fan of the time warning and then force quit (without a second warning) that is offered in Jamf's Patch Management so I'm trying to use Yo to notify the user the app needs to quit.

I can get Yo to quit the app based on the action button or allow them to defer, but not sure how to have Yo also trigger the installation if they choose to quit. To get Yo to notify the current user, the script needs to run as the logged in user (who doesn't have sudo). This works for the notification and to quit the app, but sudo is then needed to use sudo jamf policy -event installCustomTrigger. I haven't played with customizing the actual app with Xcode, I only deployed the Yo pkg to a test machine and am calling on it with yo_scheduler.

When yo_scheduler is called, it doesn't wait for your response in the script. It moves on, therefor not allowing the script to react to the user's choice. Using jamfhelper is obviously an option to address this is an easy script but the clean look of a Notification Center Alert is really enticing.

Anyone have any ideas or ways they have accomplished something like this? Hopefully I'm missing an obvious way to make it work.

#!/bin/sh

currentUser=`ls -la /dev/console | cut -d " " -f 4`

sudo -u $currentUser yo_scheduler -t "Adobe Acrobat Reader DC" -s "Please quit Acrobat Reader" -n "so it can be updated." -b "Quit App" -o "Later" --bash-action "killall AdobeReader"

Once figured out, the plan would be to use script parameters to make it more universal for all apps to use this process.

@kendalljjohnson - I'd take a look at jamJAR it's basically notifications on Patch Management via Munki, written by @bentoms

Couldn't you append a custom policy command to the end of the line like this:

sudo -u $currentUser yo_scheduler -t "Adobe Acrobat Reader DC" -s "Please quit Acrobat Reader" -n "so it can be updated." -b "Quit App" -o "Later" --bash-action "killall AdobeReader;jamf policy -event AdobeReaderUpdate-policy-name-here"

@howardgmac Tried that with and without sudo and nothing happens in the jamf.log. It accepts 2 commands: I used killall AdobeReader;killall Google Chrome and it quit both apps. My hunch is it is something with the necessary permissions when running as a non-admin user.

For example, if I try killall AdobeReader;rm -f /Users/Shared/test.txt it won't delete the test.txt file because the user the command is being run by does not have necessary permissions.

I use Yo here as well (customized and rebranded), but not specifically for Patch Management. We're not yet on a Jamf Pro release that has Patch Management fully baked in.

The only way I can see to do what you're looking for would be to deploy out a LaunchDaemon to your managed Macs that would use a WatchPath file for instructions. Your Yo script could write info into that file, triggering the LaunchDaemon to kick in and run whatever is in the file with root privileges. Or, the LaunchDaemon could run a separate script that would scan the file contents for info, like a policy ID or custom trigger for example, and then execute those if found.
I'm looking at using our custom Yo deployment for some system level patch management stuff, so I may explore this route. Once I get something working I will try to remember to post back here with results and any scripts I can share.

@mm2270 Yeah, I had thought about the LaunchDaemon method, à la Self Heal, but was hoping there might be a way directly within the script.

The method I was trying didn't directly use Jamf's Patch Management. Rather using smart groups for computer's not having the desired version and policies scoped to those groups with an on-going check-in and a recon at the end to move it out of the group if the install went through. So the policy would have this Yo script to check if it's running and launch Yo to offer quitting the app if it is open.

If Patch Management opens up the ability to do custom scripts or more versatility in the deployment, then this becomes a mute point. But there are already numerous FR's for that.

If you do get around to playing with it, would love any findings you have. Thanks for chiming in!

@kendalljjohnson I was able to get this to work using what I outlined above - a LaunchDaemon watching a file for changes in content, and having the Yo "action button" write the relevant info into that file. The LaunchDaemon then runs a script that checks the file, quits the process you pass to it, and then runs any manual trigger or policy ID it gets. Lastly, it empties the file contents, as a precaution against it being run again.

It's all a bit convoluted to say the least. I also wish there was some way to do this right from the action button contents, but I honestly don't see a way to do it. As you already figured out and mentioned, Yo executes the notification and exits immediately, so there's no way i can see in the script to capture if the user clicked that action button or just the Close button. It doesn't send back a result to the shell so you can't really capture user selection, other than writing that user selection out to a local file. And since Yo has to be run as the logged in user to display anything at all, you can't run the command in a root context. I suppose you could use an osascript command to run the command and prompt the user for their credentials (assuming they are even admins), but that's a poor user experience to say the least, and they could just as easily exit out of it.

Anyway, I have to go over what I have together and, if necessary, sanitize the script and I will post it here in case you'd like to use it.

If Patch Management opens up the ability to do custom scripts or more versatility in the deployment, then this becomes a mute point. But there are already numerous FR's for that.

Agreed! If Jamf allows script running in Patch Management policies, this opens up HUGE possibilities. I sure hope they do it.

@kendalljjohnson I just realized there IS another way you can get this done without needing to use the aforementioned methods. But it would involve setting up all these patch policies as Self Service policies.
If you're using an up to date version of Jamf Pro, you can now have Self Service "links" that open Self Service and go straight to a policy to run. You might be able to use that by sending an open command with a URL to the policy and when the user clicks the button, it launches Self Service and goes right to the policy to run. I forget if this only opens it up and the user still must click the button in SS, or if it will start running the policy right away. In the past, it used to run it immediately, which actually could be useful. I don't know if it still works this way though.

Maybe an avenue to explore though, assuming you're ok with putting all of those policies in Self Service.

For those interested, I did a write up with what I have been testing out using Alerter instead of Yo.

Custom Patch Management Workflow

@howardgmac my mind just exploded, so we can just use a --bash-action to run all updates right, macOSX updates etc. I can also use it just to display a prompt like please reboot your machine, it has been 2 weeks since your last reboot or something like that. What else do you use yo.app for besides software, osx upgrades?

Terms & ConditionsCookie settings