Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Hello junki! Casper patching done right!

Finally! munki for jamf, a.k.a. junki... borrowing a bunch of ideas from munki, and implementing them Casper.

http://www.rehrehreh.com/files/298bd40665ab46319574bafecd411d30-0.html

Take a look at the overview video here ...https://www.youtube.com/watch?v=aeOOPHH3-NY

Get on board and help make it better!

http://munkiforjamf.github.io/junki/

Like Comment
Order by:
SOLVED Posted: by Russell.kenny

Nice work Lachy, Looks awesome!

Like
SOLVED Posted: by hcodfrie

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

Like
SOLVED Posted: by davidhiggs

looks interesting, will check it out. good work!

Like
SOLVED Posted: by loceee

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.

Like
SOLVED Posted: by alex030cc

Great \- Thanks.

Like
SOLVED Posted: by donmontalvo

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

Like
SOLVED Posted: by nimoyjohnson

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

Like
SOLVED Posted: by btaitt

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

Like
SOLVED Posted: by jwojda

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.

Like
SOLVED Posted: by loceee

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.

Like
SOLVED Posted: by loceee

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.

Like
SOLVED Posted: by loceee

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

Like
SOLVED Posted: by jwojda

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

Like
SOLVED Posted: by dpertschi
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...

Like
SOLVED Posted: by scottb

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.

Like
SOLVED Posted: by jwojda

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?

Like
SOLVED Posted: by loceee

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

Like
SOLVED Posted: by loceee

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

Like
SOLVED Posted: by jaharmi

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.

Like
SOLVED Posted: by loceee

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.

external image link

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 .......... :)

Like
SOLVED Posted: by loceee

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.

Like
SOLVED Posted: by jwojda

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

Like
SOLVED Posted: by ahambidge

@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!

Like
SOLVED Posted: by donmontalvo

+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

Like
SOLVED Posted: by loceee

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*

Like
SOLVED Posted: by Kumarasinghe

what about having JNUC in Australia? :)
An idea .......

Like
SOLVED Posted: by bentoms

@loceee, if you don't ask.. You don't get.

So give it a go! Personally I'll be flying in from the UK as do quite a few non-US.

Maybe one of the AUS frequenting JAMFS can help? @kitzy

Like
SOLVED Posted: by jwojda

so, is patchoo kind of back on hold while some of these changes get worked through? I haven't really been able to get a proof of concept going thus far \- which is kind of disappointing.

I've found the patchooStartup policy logged the following:

Executing Policy zzz-patchooStartup... Running script 0patchoo.sh... Script exit code: 1 Script result: patchoo 0.982 --startup \- Wed May 21 07:17:51

SetSoftwareUpdateServer policy did set the server

Triggers installed on my test machines

PatchooPromptandInstallAtLogout

Executing Policy zzz-patchooPromptAndInstallAtLogout... Running script 0patchoo.sh... Script exit code: 1 Script result: 2014-05-21 07:15:36.452 defaults[8892:507] The domain/default pair of (/Library/Application Support/patchoo/com.github.patchoo, InstallsAvail) does not exist 2014-05-21 07:15:36.464 defaults[8894:507] The domain/default pair of (/Library/Application Support/patchoo/com.github.patchoo, DeferThreshold) does not exist 2014-05-21 07:15:36.480 defaults[8896:507] The domain/default pair of (/Library/Application Support/patchoo/com.github.patchoo, DeferCount) does not exist 2014-05-21 07:15:36.493 defaults[8898:507] The domain/default pair of (/Library/Application Support/patchoo/com.github.patchoo, BlockingAppThreshold) does not exist 2014-05-21 07:15:36.509 defaults[8900:507] The domain/default pair of (/Library/Application Support/patchoo/com.github.patchoo, BlockingAppCount) does not exist patchoo 0.982 --logout \- Wed May 21 07:15:36 patchoo: no software to install, nuffin' to do.

I think part of it is from the bug that's now fixed with creating the Library/Application Support/Patchoo folder and contents. I think in my troubleshooting I manually created them which caused permissions/owners to be different. I removed them and rebooted. The folders were recreated as expected, though its still showing "No" in patchoo installs.

Like
SOLVED Posted: by loceee

Hey @jwojda, thanks heaps for trying it out and getting your hands dirty!

Most of this stuff is expected (needs to be cleaned up though \- thanks for flagging) I've added an issue and fixed some of it on the dev branch. https://github.com/patchoo/patchoo/issues/11 .I will bounce over these fixes and the improved --cache mechanism to the testing branch as soon as I've documented how it works. https://github.com/patchoo/patchoo/issues/4

As for your issues, patchoo only can install pkgs that it knows about. It's not terribly sophisticated in that regard (munki is).

What you are seeing would be expected on first runs and if there is NO metadata in the /Library/Application Support/patchoo/pkgdata folder. Pop in and take a look in there and take a look.

What happens if you run manually call the update trigger?

If you've configured the check apple software update policy, that should check and download any outstanding updates on the the mac (and write metadata to pkdata folder), then the prompttoinstall policy should fire and present a dialog.

If you choose to defer, a recon will be run and the mac will fall into/out of the the correct smart groups.

Like
SOLVED Posted: by loceee

If you are super brave you can switch the dev branch, which is somewhat complete to 0.99. But the docs aren't quite there. The script parameters have changed .. docs not completely updated to reflect these changes... but we can now eliminate passing the pkg name and pkg description.

NOW just cache your pkg, and run 0patchoo.sh --cache AFTER. junki will pull the info metadata direct from the JSS. Cool! Also I have a fudged progress bar for JAMF installs.. double cool!

https://github.com/patchoo/patchoo/tree/dev

I hope to finish updating the docs tomorrow and pull the dev changes into the testing branch for the almost as brave.

Like
SOLVED Posted: by jwojda

ah ha!

I think I found the issue.

When I ran it with the reset SWU Server pointing to our internal server I got the following:

$ sudo jamf policy -trigger update Checking for policies triggered by "update"... Executing Policy 001-PatchooCheckASU... Running script 0patchoo.sh... Script exit code: 1 Script result: patchoo 0.982 --checkasu \- Thu May 22 07:29:42 patchoo: setting asu CatalogURL to http://<server>/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1_prod.sucatalog patchoo: checking for apple software updates... Can't load data from the Software Update server (<server>). patchoo: no updates found. Submitting log to https://<JSSServer>:8443/ Executing Policy zzz-patchooPromptToInstall... Running script 0patchoo.sh... Script exit code: 1 Script result: patchoo 0.982 --promptinstall \- Thu May 22 07:29:42 patchoo: nothing to install Submitting log to https://<JSSServer>:8443/

when I did a jamf removeSWUSettings and reran it...

$ sudo jamf policy -trigger update Checking for policies triggered by "update"... Executing Policy 001-PatchooCheckASU... Running script 0patchoo.sh... Script exit code: 1 Script result: patchoo 0.982 --checkasu \- Thu May 22 07:32:46 2014-05-22 07:32:46.745 defaults[5829:507] The domain/default pair of (/Library/Preferences/com.apple.SoftwareUpdate, CatalogURL) does not exist patchoo: no asu server set, using apple's... patchoo: checking for apple software updates... patchoo: softwareupdate is downloading Safari7.0.4Mavericks-7.0.4 Software Update Tool Copyright 2002-2012 Apple Inc. Finding available software Downloading Safari Downloaded Safari Done. patchoo: USERNOTIFY:: Downloaded, Safari 7.0.4 patchoo: softwareupdate is downloading OSXUpd10.9.3-10.9.3 Software Update Tool Copyright 2002-2012 Apple Inc. Finding available software Downloaded OS X Update Done. May 22 07:33:30 ushofml00990f softwareupdate CLI[5904] <Error>: /usr/sbin/softwareupdate: XPC error in __60-[SUCommandLineTool _runSessionWithUpdates:skippingInstall:]_block_invoke (Error Domain=NSCocoaErrorDomain Code=4099 "Couldn’t communicate with a helper application." (The connection was invalidated from this process.) UserInfo=0x7fc48ba001f0 {NSDebugDescription=The connection was invalidated from this process.}) patchoo: USERNOTIFY:: Downloaded, OS X Update 10.9.3 Submitting log to https://srshofmacdply01.kih.kmart.com:8443/ Executing Policy zzz-patchooPromptToInstall... Running script 0patchoo.sh...
Like
SOLVED Posted: by jwojda

it seems to be okay with the dev branch (patchoo.sh and updated trigger) as well. However, I had it running all week on the previous branch (minor tweaks aside) and it never did anything until I manually ran a trigger on my box \- and none of my other dev boxes have done anything... In my head I've been meaning to ask that question, how does it get initially launched as everything seems to be tied to a trigger, there's no policy setup to call it to start the checks. The triggers in System/Library/LaunchDeamons don't seem to be responding...

Okay, now the every120 trigger just kicked off ;)

Like
SOLVED Posted: by donmontalvo

FWIW, valid criticism from our beloved @gregneagle over at the IRC channel. I agree with him, I'd like to see patchoo pick up steam and fill in that gap:

http://osx.michaellynn.org/freenode-osx-server/freenode-osx-server_2014-05-22.html

external image link

Direct link to the above image:

http://donmontalvo.com/jamf/jamfnation/IRC/valid-constructive-criticism.png

And the URL @gregneagle is referring to:

https://jamfnation.jamfsoftware.com/discussion.html?id=10705

Like
SOLVED Posted: by mm2270

I think its almost a unanimous agreement that software patching is a serious weak area for Casper and we would all like to see this kind of process built into the product. This really should be coming from JAMF. Building some adjunct tools is fine and reasonable. but having to develop an entire workflow to get around this limitation is not IMHO.

I don't have any specific criticisms of junki/patchoo, etc, but my primary concern with it is the same reason I have some sleepless nights about processes that Ive also developed where I work. It relies on cocoaDialog, and as anyone that has paid attention to it will know, that product has seen 0 development in the last 2 years now, with no indication in sight on whether it will ever be further developed. Hardly anyone out there loves cocoaDialog more than me, but I seriously worry that the "next" OS release will break it completely and that will be that. And we'll all be crying into our soup. I'm very hesitant to throw all my eggs in a basket that relies so heavily on cD as its primary method of interaction for this reason. There's no support on cD and the developer has essentially fallen off the grid as far as keeping it up to date.

None of what I've said above negates the amount of work and effort that Lachlan has put into this though. Its outstanding work. I just pray that it isn't brought to its knees by a future OS X release. :(

Like
SOLVED Posted: by donmontalvo

@mm2270 A couple years ago JAMF Software had a session with some of their bigger clients, where input was requested on what features/enhancements should be considered for v9. Our biggest concerns were (1) exclusions and (2) segregation...we got both.

Today, I think @gregneagle's concern is shared across the JAMF Nation community. I hope there will be a similar session at JNUC2014, so this kind of functionality is burned in to the next version of JSS.

Like
SOLVED Posted: by loceee

@jwojda \- to answer your question on how the update sessions are triggered, they should be fired by the periodic trigger which runs daily at 12:00.

The PreUpdate/patchooStart (in dev branch) is responsible for then firing the necessary triggers based on group membership eg. Beta groups... fires update-beta... and policies that cache the beta software. (this check isn't run unless utilising patchooSWReleaseMode)

Then the start policy triggers "update" this is the main trigger that runs the rest of the update process.

BUT if the patchoo trigger isn't running at midday that will be your problem.

The every120 trigger will fire the reminder bubbles, and if a prompt is missed (timeout, screensaver etc) it will bring up a full prompt again. But it should only present a full prompt once per day.

https://github.com/patchoo/patchoo/blob/master/docs/overview.md

From your logs,

Script result: patchoo 0.982 --checkasu - Thu May 22 07:29:42
patchoo: setting asu CatalogURL to http://<server>/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1_prod.sucatalog

patchoo has re-written your catalogURL to point at axxxxx_prod URL. Unless you have a branch named this in NetSUS / Reposado it won't hit it.

If you aren't using reposado branches, or are using an Apple Software Update server, you need to set ```
patchooasureleasemode=false
```

https://github.com/patchoo/patchoo/blob/master/docs/setup_patchooasureleasemode.md

By using https://github.com/patchoo/patchoo/blob/master/extras/asucatalogset.sh you can replicate the old Casper 8 functionality around setting ASU server based on the network segment data in the JSS. Again, you can set this to write reposado full client URLs, or Apple Software update server URLs that can re-write on based on client OS info.

Like
SOLVED Posted: by loceee

I agree with @gregneagle 100%.

From a workflow point of view I feel that software deployment and delivery shouldn't be handled by policies and smart groups. There needs to be a specific software deployment section. The patchoo methodology extends and improves existing workflow, but I would like to see it completely shaken up.

munki could be leveraged, and the way I think it should be handled is by extending and exposing the "Computer Configurations" via the API. If we had access to the configurations via the api, some parallels to munki's manifests could be hacked together. Computer configurations, in the same way that manifests let you nest infinitely need to be extended. Perhaps make something called a "pkg group" and have it separate from a computer configuration.

But... deploying a package update should require nothing more than ingesting a pkg into your repo (hopefully automatically) and then dragging it into a group / configuration, jamf installer on the client (as munki does) should be responsible for checking receipts, dependancies, checking for running apps and prompting the user, etc. Lots of scope here... but I think one thing for sure...

...software installation and deployment via policy and scoped smart groups is the wrong approach moving forward.

Like
SOLVED Posted: by donmontalvo

@loceee +1

...software installation and deployment via policy and scoped smart groups is the wrong approach moving forward.

@gregneagle's 2014 schedule is booked...but wouldn't it be great if he could make it to JNUC2014 to present his perspective on patch management?

Wouldn't it be great if JAMF could break the mold and make JSS 10 what it deserves to be? ;)

Don

Like
SOLVED Posted: by loceee

@mm2270 \- I don't think the reliance on cocoadialog is THAT much of a concern. It wouldn't be unpossible to switch most GUI over to built-in applescript and/or jamfHelper. I do agree that Casper patching needs to be improved massively OOTB though! I consider patchoo a good stopgap, and a potential workflow. Although if you read my post above, I agree that the current workflow is way too admin heavy!

THIS! https://jamfnation.jamfsoftware.com/featureRequest.html?id=2261

Like
SOLVED Posted: by Kumarasinghe
Wouldn't it be great if JAMF could break the mold and make JSS 10 what it deserves to be? ;)

I think JSS 10 is too far away. I would like to see this happen on 9.6 or something.

Like
SOLVED Posted: by davidhiggs

Yes the approach needs to be different and It should start with a top level software section. Casper's implementation of software management never bothered me until I started to try and make it work for BYOD.

Recently i've been given an large environment of Macs which belong to users that don't want to be managed, but want they want our support and services. Essentially these are university owned BYOD machines. I'm running a trial of Casper and will try to facilitate this task using Self Service, building an enterprise portal acting as an app store. The user is in full control of what software is installed and patched on their machine, we simply present them with options with opt in automation.

I'm trying to create an experience that is better than Apple's own App Store and will work on any machine out of the box. Provide access to MAS, VPP, Enterprise/Site licensed and Freely available software. Have sections for installing, reinstalling, updating, uninstalling. The amount of smart groups and policies needed to do this is huge, so maintaining is a much bigger job. And it's all disjointed! Casper really needs it's own structured software section.

My particular use case is different to most of you, but we all want to achieve the same thing essentially. JAMF can do this, the backend it good enough to achieve it.

Like
SOLVED Posted: by jwojda

@loceee][/url \- thank you! I thought I caught all the changes I was making to the script, I missed that one. I went back in the logs and saw it was trying to launch. I just made the change now, so I will wait and see what it shows at noon.

I made the changes in the ASU script and the main patchoo script to reflect =false, rebooted the test boxes, waited till noon-ish and they still failed. Assuming I need to remove the CatalogURL and let it try again from scratch?
Is there a simple way to kick off that noon thing manually so I don't need to wait till tomorrow?

Like
SOLVED Posted: by loceee

If the asucatalogset.sh fires, it should update your CatalogURL to point at your local Apple Software Update server (http://server.domain:8088/index.sucatalog) -- verify softwareupdate can reach it by:

sudo softwareupdate -l

The easiest way to trigger an update session just call the trigger.

jamf policy -trigger patchoo

If you want to test the logout policy without logging out (so perhaps you can tail the logs easily)

jamf policy -trigger logout

you can check every120 in the same way. ```
jamf policy -trigger every120

```
touch /tmp/.patchoo-install

sets the install at logout flag, so it will automatically install when the logout policy runs.

I might add these testing procedures during the setup process in the docs? Would help people verify things are behaving.

Like
SOLVED Posted: by btaniyama

I think patchoo is a great step towards automated that which should be automated. I've been testing the combination of autoPKG with @Banks][/url][/url jssimporter script and patchoo, and although I haven't seen it in production, my tests have been pretty positive. Essentially what I'm trying to accomplish is autoPKG handles the fetching of updates, the importer brings over the package, creates a smart group and policy which I've edited to feed right into patchoo, which then handles deployment. I love the option of having it in self service as well, but my users don't necessarily understand that they can do software updates on their own, so the ability to have patchoo push them out, while still giving them the option to temporarily defer is pretty big.

Like
SOLVED Posted: by loceee

@btaniyama \- this almost completely eliminates the tedium of patch deployment in Casper. Exciting stuff!

In other news... Patchoo v0.99 elimates a bunch of annoyance around creating patchoo deployment policies too, with a great new --cache mode. Put some Info in the field when uploading your pkg, run patcho --cache AFTER in you pkg caching policy and it handles the rest!

http://www.rehrehreh.com/files/patchoo-v99.html

Seems we might have a sandboxing issue on 10.9 which I haven't run into, but others are https://github.com/patchoo/patchoo/issues/16

Feel free to test and lend a hand!

Like
SOLVED Posted: by loceee

As for the cocoaDialog dependancy... hmm... definitely an issue on the logouthook. Anyone got any input on the issue? https://github.com/patchoo/patchoo/issues/16 Something to do with the new security and sandboxing in Mavericks?

Like
SOLVED Posted: by mm2270

@loceee \- yeah, definitely something to do with the more strict sandboxing introduced in Mavericks. I've been attempting off and on to figure out a way to make it work and have come up dry. Mavericks is a hard ass. It just refuses to cooperate, even when using otherwise legal methods of getting it show over the loginwindow.

It funny, but I was actually going to ask how you were getting around the issue. I saw the videos you put together showing the progress bar over the loginwindow and thought you'd overcome the problem. But I'm guessing now those were taken while on 10.8?

Like
SOLVED Posted: by UESCDurandal

Yeah, I'm curious how JAMF was able to keep the logout hook status screen (Checking for Policies...) to remain on the loginwindow with Mavericks.

Like
SOLVED Posted: by loceee

Yup. You are right, on <10.9 it works great. Trying to launch it via launchagent LimitLoadToSessionType to loginwindow, no avail.

munki and https://github.com/MagerValp/LoginLog LoginLog are doing it. Hmmmmmmmmmmmm...

Like
SOLVED Posted: by jwojda

@loceee][/url \- had another question, I don't think it's a bug, which is why I'm not posting on git. I noticed that it's not doing a recon when stuff is installing. Do I just add a recon checkbox to the policy? I just don't want it to notice that application xyz is not there according to recon and then cache it and try to install it again.

Edit: Thought of another question.
Since the progress bar at logout isn't working on 10.9.x. Can we just disable that policy w/o breaking anything?

Like
SOLVED Posted: by gregneagle
munki and https://github.com/MagerValp/LoginLog LoginLog are doing it.

https://code.google.com/p/munki/source/browse/code/Managed%20Software%20Update/MSUStatusWindowController.py#136
https://github.com/MagerValp/LoginLog/blob/master/LoginLog/LLLogWindowController.py#L61

The window-displaying code in the application must explicitly do the right thing at the loginwindow in order to become visible.

Like
SOLVED Posted: by mm2270

I recall reading some of the threads on the munki Google discussion board about what needed to be done to get their apps working over the login window when Mavericks came out. I ran across them when searching for a way to get cocoaDialog to do the same.
So although its certainly possible based on the code examples above from Greg, it seems only a code rework of cocoaDialog will make it happen, at least in any reliable way. Which goes back to my concern over relying on it for this. The code hasn't been touched in 2+ years now, and was last tested fully on 10.6.
Not being a developer myself I would have no clue on how to integrate the python code into cocoaDialog. It almost makes me want to dive in and learn some development so I can actually help make improvements to it and keep this thing alive a bit longer. If my other personal commitments weren't what they are, I would seriously do that.

One of the developers for cocoaDialog (Mark Carver) is actually responsive to questions posted on the github page. You may want to post a question about it there. When I asked something about an issue I was seeing he actually responded in a matter of minutes. Though no work is being done on it anymore, they are paying attention to questions on the product. Worth a shot to see if they have any input.

Like
SOLVED Posted: by bentoms

Thanks @mm2270.

I've tried to re-compile (to code sign & sandbox) it on 10.9, but there is a lot of deprecated Objective-C code that needs to be replaced & I have no idea what to replace it with.

Like
SOLVED Posted: by loceee

@jwojda \- Patchoo follows a couple of rules to minimise recons. Casper OOTB bugs me since most times you install something, you've have to run a recon on every policy to make sure your smart groups are up to date. Lots of installs, lots of recons (and too much time)

The rules are:

Cache Pkg... User prompted? Defer ---> Recon ---> Exit Install Install req restart? No --- > Recon ----> Exit Flag for Recon Restart patchoo Startup ---> Recon --- Exit

All of these workflows means we can minimise recons and ensure computers land in the correct smart groups. If there are new changes to pkg cache, and users just dismiss a prompt, we skip a recon.

The reason we recon on startup is in case of an Apple update that requires a restart. It is not a good idea to recon after we install a point update and haven't restarted yet.

StartupPolicy is overkill, but I figure it might do something else later down the line.

As for limiting your 10.9 clients whilst we resolve the cocoadialog at logout issue. Setup your core policies like in docs
https://github.com/patchoo/patchoo/blob/master/docs/setup_core_policies.md

and use the smart group patchooAllCleints to limit
https://github.com/patchoo/patchoo/blob/master/docs/setup_core_smart_groups.md

That way the core patchoo trigger won't fire the update chain, and the logout and every120 won't fire reminders on these Macs.

Like
SOLVED Posted: by loceee

Thanks @gregneagle ! This is awesome info.

Perhaps we need to compile on 10.6 on an older version of Xcode. This is getting over my head. There is a newer fork here, and perhaps we need to make some changes within the appcontroller around here... https://github.com/cooljeanius/cocoadialog/blob/master/Source/AppController.m#L217

Like
SOLVED Posted: by loceee

I've committed a workaround for this problem to the dev branch. Please test it out if you can.
https://github.com/patchoo/patchoo/tree/dev

Using a "fauxLogout" \- quit all apps, unload finder and dock, then perform installations. This means cocoaDialog can run on 10.9/10.10 as it's running in a user session still ... (also updated catalogURL handling for patchoo.sh and asucatalogst.sh).

Like
SOLVED Posted: by gregneagle

In your "fauxLogout" mode, what happens if your code (or JAMF's) crashes? If your code isn't running any longer to reload the Finder or Dock or do a "real" logout or restart, how does the user get a working machine back? Hard power cycle?

Like
SOLVED Posted: by jwojda

I don't know that it was meant to be a full on fix so much as a stop-gap to get things functional. But you do bring up a valid point.

Like
SOLVED Posted: by mm2270

Greg does make a valid point. I know its meant as a workaround, but it seems a little risky to me. Its only my opinion, but it might be better to leave out that functionality, or code it so it skips it for 10.9+ until a more solid fix can be worked in.
(That said, it is in the dev branch, so its not like its being promoted as "the way" forward)

And as a sort of counter argument, regular logouts/reboots can also hang on occasion, so there's always a risk of a system getting "stuck" during updates like this and requiring a hard power cycle.

Like
SOLVED Posted: by loceee

I agree entirely. It's urgly... I don't have a better solution to solving it immediately since it's reliance on cocoaDialog.

It certainly could fire a helper process that handles the unload, waits for install, then reload and subsequent logout. Shouldn't be much extra work.

Thoughts?

Like
SOLVED Posted: by mm2270

I was actually giving this some thought and experimentation this afternoon. @loceee][/url \- shoot me an email offline at mm2270 at me dot com. I put something together that you may be able to use which, while still far from perfect, doesn't involve unloading the Dock and/or Finder, yet removes the ability for the logged in user to interact with anything while the installs are taking place and cocoaDialog is up on screen. I would guess this is pretty much the end goal, right? I can explain what I have together further and send you the code to see what you think.

Like
SOLVED Posted: by loceee

We've cooked up another method.. Using ARD LockScreen (thanks @mm2270 !) ..

... but again should anything fall over, it leaves the Mac in a borked state.

Hmmm, to address that concern really the only thing I've got is spawning a watch process that ensures a logout once that installprocess completes (successfully or otherwise).

Like
SOLVED Posted: by loceee

About to commit to dev... fauxLogout is spawned, waits for install process to finish, then it reloads finder and dock and logs out.

If we end up with something going wrong during installation, this should mean we get back to normal and log the use out to address that concern.

Testing it more... but this workaround solves the issue on 10.9/10.10

In all honesty there is major gaps around error handling all thoughout patchoo, but I will focus on that once I've got functionality nailed.

Like
SOLVED Posted: by loceee

0.9931 incorporates this slightly ugly but functional workaround! thanks @mm2270 !

We now have 10.9 (& 10.10) functionality restored. http://www.rehrehreh.com/files/patchoo-v9931.html

Like
SOLVED Posted: by UESCDurandal

@loceee Ever since updating to 0.9931 I've been seeing this message during zzz-patchooLogout with our 10.9.3 Macs.

Script result: patchoo 0.9931 --logout \- Thu Jun 26 18:05:28 /Library/Application Support/JAMF/tmp/0patchoo.sh: line 1065: displayatlogout: command not found patchoo: jamf is running a recon...

Any thoughts?

Like
SOLVED Posted: by loceee

Tracked it here ... https://github.com/patchoo/patchoo/issues/30, investigating.

Like
SOLVED Posted: by loceee

and should be fixed on latest commit.

Like
SOLVED Posted: by charliwest

Sorry if this is a really stupid question, but will patchoo be able to work with dmg's?

Like
SOLVED Posted: by FritzsCorner
Sorry if this is a really stupid question, but will patchoo be able to work with dmg's?

@dwest Patchoo works great with dmg's from my experience.

Like