Add support for Monitoring Client version detection

[YesThatAllen]

The MonitoringClient will auto-update by default, so installing any version 5.2 or better should suffice.

When the workflow calls for disabling auto-update, this feed can be watched to know when it's time to re-download and deploy

https://www.watchmanmonitoring.com/category/client-release-notes/feed/

NB: Auto update can be disabled with this command: /usr/bin/defaults write /Library/MonitoringClient/ClientSettings Update_Enabled -bool false

[YesThatAllen]

More detail:

The goal is to follow that RSS feed, and on any change download the latest flat, signed installer pkg defined here

that package is ready for inclusion in deploystudio as a post-restore action, no processing of the pkg is required.

[arubdesu]

Hey Allen, maybe the coffee isn't working, but I don't see an actionable question here. I hope I don't sound too negative, as more folks 'in the pool' is always great. That being said, 😅, here's a tangent related to the linked recipe: it's built contrary to the unwritten, informal convention of splitting recipes into separate download-pkg(if needed)-patchMgmtSystem steps. The namespacing is therefore weird/unnecessary, one would make a watchman.download.recipe, then a watchman.pkg.recipe(since munki can suck in dmg's without issue), then a watchman.ds/munki/jss recipe as needed. Mr. Daly(@portalpie) also is weirdly forking the entire core autopkg/recipes repo, instead of just making a new one for the new product he wants to share with the world. He's correct autopkg's version doesn't relate to watchman(line 22), and should probably credit @jazzace for figuring out this method(I can tell he's using Anthony's weird XML formatting 😜). Perhaps I'm editorializing and sounding harsh/overtly critical about things this issue wasn't meant to address, but I do honestly hope this helps(and I hope I'm not talking out of my butt). (Insert butt emoji)

[YesThatAllen]

Hey Allister! Good to hear from you!

I think the subject line is as close to an actionable item as we're going to see here. We're looking to document the importing of a the latest package version. (Lastest being: the version posted at the time our RSS feed is updated.)

As for the history of this fork - I didn't see any reason why this recipie shouldn't end up as one of A bunch of AutoPkg recipes! , and so why not prepare to create a pull request to the sauce.

Odds are quite good I picked the wrong basic recipie to start from, is there one that's better suited for the task of: Check an RSS feed, if it's updated, grab a flat, signed pkg from a given URL and copy it into place for post-restore installation in ds/munki/jss?

We do post the signed .pkg in a .dmg wrapper, perhaps that would be a better target? (the resulting installation would be the same).

Thanks!

[arubdesu]

Hey Allen, if you have an appcast/RSS feed URL, that sounds like all you need as far as autopkg is concerned, wether you pass around a DMG or a PKG seems dependent on the system you'll distribute it with, munki can skip a step is all I'm saying. I'd consider it 'nicest' to all of the folks that might use the recipe if you have each step modular and clearly named for it's granular function, but just like the JSS processor needs a pkg (and who knows what systems like AbsMan or future ones might require), more options to build off of are generally speaking better(if maintainable).

I just checked with @gregneagle, and it's been stated previously that products that the core devs don't use wouldn't get pulled in via PR. If you'd like your standalone repo to be under the autopkg organization, you can create an issue asking to be forked back with your one(or many) products, at which point folks could search for your product from the autopkg search verb. And I misspoke that recipe namespacing and modular 'steps' were undocumented, they're actually here.

[jazzace]

The wiki also points to how recipes are to be shared: https://github.com/autopkg/autopkg/wiki/Sharing-Recipes I do not require credit (especially with all the help I got from @timsutton and @arubdesu), but since .ds is just a convention of mine, I am going to now submit my recipes as described on the linked page to make it more official. You will also note that I follow the patterns that @arubdesu described, separating downloads from ds or pkg. The fact that others did that before me made my work so much easier to bring DeployStudio functionality to the project.

[morgsdaly]

Hello Allister & Jazzace,

I am very much a newbie to all aspects of this so happy to be schooled. Will be sure to take on board what you guys have pointed out.

Thanks Morgs

[YesThatAllen]

The pointers for recipe publication are welcome. Seems to me that the release notes rss endpoint isn't enough either.

The Watchman Monitoring server will soon support for a raw status request page which returns the active version and build number for any given subscriber.

this recipe will be moved to its own repo https://github.com/watchmanmonitoring/watchmanmonitoring-recipies

for future consideration by the AutoPkg team.