Hello junki! Casper patching done right!

[loceee]

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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

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

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

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

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

[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

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

[loceee]

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

[loceee]

and should be fixed on latest commit.

[charliwest]

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

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