Posted on 11-03-2017 06:59 AM
I installed JP10 on our internal test server to play with Patch Management. Added Mozilla Firefox 56.0.2 to Jamf Admin directly from the dmg I downloaded from Mozilla and added it the PM policy and set it to distribute via Self Service. When I ran the update from Self Service on my Mac it ran the update and dropped Firefox and an Applications folder alias at the root of my HD. Self Service is still showing that I need the update since the new FF app isn't in /Applications. I was assuming Patch Management would be smarter and know to just install Firefox and install it in the correct place if I used the dmg from Mozilla. I guess I was assuming that Jamf was seeing that if Firefox 56.0 which resides in /Applications was in need of the update and would know to replace it in the same location. I am assuming I have to repackage FF with Composer and tell it where to install. Guess I need to play with Autopkg to make this easier.
Just wanted to share my experience. Anyone else have anything they can share with their Patch Management testing?
Thx,
Scott
Posted on 11-03-2017 07:12 AM
They also don't make it easy to replace the pkg/dmg that is assigned to a Patch Management title. Looks like I can't just delete the dmg I had originally used and replace it with the pkg I just created with Composer without deleting the entire PM policy and starting over. Ugh.
Posted on 11-03-2017 08:01 AM
Also, what triggers when the Patch Management update will show up in Self Service? I have tried sudo jamf policy, sudo jamf recon, sudo jamf manage, and launching Self Service. None of these seem to force the update to show up in SS.
Thanks,
Scott
Posted on 11-06-2017 12:36 PM
Great thoughts/comments, @scottlep
I can try to give some context to the decision making around the file path stuff.
We wanted to provide a method to take any package and distribute it to any device when deemed necessary for a patch. When we looked at "getting smart about it" and reading for file paths, etc, we found it assumed that every workflow would be the same. Essentially, that admins would universally want that over having a framework that may require some modification (package creation) at the benefit of the extensibility. After some conversations early on, it seemed the consensus was a framework and that the binary shouldn't try to auto-install in the "right" location but that folks would be OK with creating their own packages.
That said, our end state since the beginning has been a tool that can identify, package, upload, and distribute a patch to any device without requiring an admin to intervene. We still have intent to deliver on that over time and multiple iterations. So while there is that work today to create the packages, we certainly don't see that as the ideal utopian world and want to provide methods to make that easier.
Thanks, again, for your comments!