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

@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

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.

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.

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.

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

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 ;)

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

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

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

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

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.

@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

@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

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.

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.

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

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.

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.

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

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?

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

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.

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

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