Nice work Lachy, Looks awesome!

This looks very good think i will dig into junki this weekend thx for posting and your effort

looks interesting, will check it out. good work!

It's been brought to my attention that Office updaters are combos now (thanks @davidhiggs !), but for this example let's just pretend they aren't.

Great - Thanks.

Start with a developed/supported solution (Casper Suite), extend its functionality. Nice! :D

Nice work loceee! Made my weekend. Really awesome job.

This looks great, can't wait to dive in! Thanks for your work!

I've spent the last 3 or so hours diving in. good stuff so far. I'm a little lost as i'm not sure what smart group criteria is for "all junki clients" as referenced in the docs - https://github.com/munkiforjamf/junki/blob/master/docs/setup_core_policies.md

Further that page in particular could use some more distinction between what is needed for advanced mode in addition to the basic functionality. The docs in the beginning were good distinguishing Advanced from basic, but as they go on they get less clear. You also show in the screen shot at the bottom a Reset defer counter policy that's disabled... do we need that? I hadn't seen it mentioned thus far in the docs.

Hey @jwojda !

I totally agree, I know the docs got a little iffy as they went on. I really wanted to get the thing out, and my deadline was set or it wasn't ever going to see the light of day. Great feedback so far, I will address these issues.

I think the preupdate trigger / policy as it's currently named will become mandatory. The plan being that all of the scoping is done on this policy. Then we can get rid of the confusion around "all Junki Clients".

Also that "Reset Defer Counter" is a policy that you can use to set the defer counter. It just runs

defaults write /Library/Application Support/junki/com.github.munkiforjamf.junki DeferCount -int x

Uses for this could be that you want to deploy an update (we used it when moving all clients to 10.8) by a certain date. Send an email to all clients advising of the impending update, then set your counter so that users will be forced to deploy by Friday / etc. Works really well, users can deploy earlier if they like.

Thanks heaps for all the kind words! I am glad people like it.

I've had feedback and confusion about munki's involvement in junki (ie. none - https://twitter.com/ChipPearson/status/467331897522012160 ) and I don't want to tread on Greg and co.'s shoes.

As of today, junki (which was always a working title) is becoming....

"Patchoo!" - (the sound that a raygun makes).

I am going to update docs, repos, and URLs to reflect the name change... Will post once it's all on the way.

It's all moved, excuse any references to junki in screenshots, and please advise if there are problems with my frantic search and replace.

http://www.rehrehreh.com/files/junki-is-now-patchoo.html

http://patchoo.github.io/patchoo

Locee - not sure if you want to use JAMF as the forum for issues or if you'd rather someplace else. But in your doc on https://github.com/patchoo/patchoo/blob/master/docs/install_triggers.md - the link to the triggers is not functioning - leads to page not found. Not a critical issue, since they are included in the zip/tarball and we can make our own pkg's

As of today, junki (which was always a working title) is becoming.... "Patchoo!" - (the sound that a raygun makes).

I love it. I suppose then we shouldn't pronounce the letters as a word, but to 'speak it' like a sound effect...

Looks pretty cool! Why not call it "Baconator"? :) Some of you guys amaze me. Perfect timing to as we are discussing options for updating our client's Macs finally.

when I run a recon with the EA's, I just get an n/a as an entry, though I have at least 1 pending update according to the MAS. I think it's because I don't have the prefs path - /Library/Application Support/patchoo/com.github.patchoo
Did I miss a step for creating that or how it gets created?

Hey @jwodja,

https://github.com/patchoo/patchoo/blob/master/0patchoo.sh#L195 creates the application support folder ... BUT you've just pointed out a bug. The preferences are trying to be written BEFORE this folder is created on the first run.

Subsequent runs will fix itself, but I will correct that now and push the change. Thanks! In the mean time, if you trigger another 'update' run, it should write the preferences, then do a recon manually, that should bring it in order and the ext attribute should be sorted.

https://github.com/patchoo/patchoo/issues/5

Please pull or download the latest 0patchoo.sh ... let me know how it goes.

Both this project (which is “use at your own risk!”) and Munki seem to be equally unsupported — or that is to say, community supported. Is the primary technical advantage of this effort, then, that it doesn’t need the standard Web server (HTTP/HTTPS) that would be required by Munki?

In any case, a lot of effort clearly went into this (by LOC, if by no other measure), so thank you for contributing it. I like to see a vibrant field of ideas on how to manage OS X systems, especially where software deployment is concerned.

Hey @jaharmi,

Patchoo utilises existing Casper methodologies and infrastructure (your CDPs, pkgs, computer groups, policies) which should be familiar to existing Casper admins, and all infrastructure should already exist within your install. The packages you use in Casper Imaging to deploy your Macs, will be the same packages you use in your Patchoo update policy.

Originally, junki did start as a project to integrate munki and Casper... but I couldn't find a cohesive way to make the pieces and methodologies fit together... leveraging all the greatness of munki (I am a massive fan) would have made life easier in some ways, but generated more confusion around which tool is responsible for what. Do you drop using Casper Imaging and computer configurations entirely? Not all of our admins are as command line savvy, do we have another management portal on top of JSS? How do you allocate the munki client identifiers, and how would I allocate different catalogs to clients and keep this control within Casper?

I couldn't come up with something that was cohesive enough to bring to my fellow admins. One main consideration was I didn't want to be the only guy that knew how to drive it. :)

Then it dawned on me, Casper already has really great (and supported) components that we've already paid for .. why not just fill in the gaps?

Using Casper Imaging to deploy the software (without an erase and image) made sense, and it was a supported and easy way for people to deploy their software initially. Self Service is a super great way for users to deploy optional software (if we were using munki, would we be presenting optional installs there too?).

BUT... we all knew that Casper's patch and software installations POST deployment (a.k.a. in the wild) could be greatly improved.

So the design considerations around junki became don't re-invent the bits that work well, but rather fill the gaps and integrate nicely with existing frameworks. I tried to wring munki-esque functionality out of Casper's frameworks. Tying software deployment groups dev/beta/production to Casper's existing computer groups, then tying those deployment policies to custom triggers.. and even dynamically writing your CatalogURL based on this to point at at reposado fork, (I think) is a clever way to accomplish something munki users have taken for granted. AND existing Casper peeps can understand the methodology.

I don't re-invent pkg caching, casper does that fine. I did however build a UI and workflow around end-user notification, and installation.. since we all tend to know Casper is lacking there.

eg. By scoping- policy: "Install New Software" - patchoo.sh --installselfservice to smart group: "updatePatchooInstallsWaiting" A nice little icon pops up in Self Service if you have software installations waiting.

What I REALLY hope I have demonstrated is a workable way to accomplish all of this within Casper, and now JAMF can go and make us all a shiny new "cache Appel Sotware Updates" policy and "Install All Cached" policy for Casper 9.5...

JAMF - my PayPal account is .......... :)

Vote on renaming the "preupdate" trigger.

I never really like that name... my feelings are it should be called something else:

startpatchoo
patchoostart
patchoogo
gogopatchoo

or even just

jamf policy -trigger patchoo

then that trigger calls the patchooPolicy, which fires the update-xxx, update triggers to drive the rest of the process?

Thoughts from anyone that's playing with it and reading the docs @jwojda.

Also please feel free to raise issues and enhancements directly on https://github.com/patchoo/patchoo/issues .. it's much better place to track stuff than in a forum thread.

patchoo or startpatchoo is fine.. or patchoopatchoo :) in all seriousness, it doesn't matter to me.

@loceee, this is completely awesome. If nobody else has said it, there should definitely be a round or two of the beverage of your choice provided to you at the next social gathering at JNUC. :)

Amazing work!

+1...thanks for the effort, 1st/2nd beer at JNUC2014 on me!!!

That's right, we're going to get you smashed! :D

Word of the day:

Luddite
http://www.merriam-webster.com/dictionary/luddite

If I can convince my employer to spot flights to JNUC I be happy take you all up on that.

But alas, it's probably not going to happen when I am on the other side of the world. *sad panda*