cocoaDialog fix for 10.9, 10.10
22/05/15 10:27
This has been a problem for a looooong time. As of 10.9, Apple made changes to how applications are allowed to present UI outside of a logged in session.
Due to this change a stalwart of the MacAdmin tool belt, cocoaDialog (which has be unfortunately stagnant for some time), found itself unable to display a dialog during a logout. This affected a fair few people, myself included.
Today I have some good news. I somehow have managed via excessive Googling, kludging and fumbling my way around a bunch of obj-C I really didn't understand, seem to have managed to chop in some changes that allows it to work on the logout hook.
There is a discussion on jamfnation.
And my fork is here with a binary you can download. USE AT YOUR OWN RISK and feel free to fix whatever mistakes I've made.
I am not going to actively undo some of the ridiculous workarounds in Patchoo as I have some pretty massive code and workflow changes slated for Patchoo2.
cocoaDialog_3.0.999.zip
For the unbelievererers here's proof on a 10.10.3 client
Nothing up my sleeve
Due to this change a stalwart of the MacAdmin tool belt, cocoaDialog (which has be unfortunately stagnant for some time), found itself unable to display a dialog during a logout. This affected a fair few people, myself included.
Today I have some good news. I somehow have managed via excessive Googling, kludging and fumbling my way around a bunch of obj-C I really didn't understand, seem to have managed to chop in some changes that allows it to work on the logout hook.
There is a discussion on jamfnation.
And my fork is here with a binary you can download. USE AT YOUR OWN RISK and feel free to fix whatever mistakes I've made.
I am not going to actively undo some of the ridiculous workarounds in Patchoo as I have some pretty massive code and workflow changes slated for Patchoo2.
Download
cocoaDialog_3.0.999.zip
For the unbelievererers here's proof on a 10.10.3 client
#!/bin/bash
/Applications/cocoaDialog.app/Contents/MacOS/cocoaDialog msgbox \
--text "I am displaying on a logout hook on $(sw_vers | grep ProductVersion | awk '{ print $2 }')" \
--button1 "Alright, alright, all right..."
exit
Nothing up my sleeve
sudo defaults read com.apple.loginwindow LogoutHook
{
LogoutHook = "/Library/Scripts/logouthook.sh";
}
Comments
Where have I been?
22/05/15 09:01
It's been a long time between posts. I've changed jobs and have been swamped trying to bring singlehandedly some order a completely unmanaged OSX and iOS fleet into order across 18 sites and entire country. It's also a complete change as I am now in edu. Apologies for lack of work on Patchoo!, but I hope to have some more time to work on v2 soon!
I am planning on writing up my battles with VPP / DEP / GroundControl / Casper and iOS shared carts soon as most information out there is not current, and I've built a pretty good workflow within the constraints of the MDM frameworks.
More to follow!
I am planning on writing up my battles with VPP / DEP / GroundControl / Casper and iOS shared carts soon as most information out there is not current, and I've built a pretty good workflow within the constraints of the MDM frameworks.
More to follow!
Introducing Patchoo Deploy
19/09/14 13:08
Patchoo Deploy provides a framework for deployment and provisioning of new or re-imaged Macs.
As Casper admins are moving from an "image" based deployment workflows to policy based "thin provisioning" over the top of a factory Apple build, or a vanilla AutoDMGed Mac, PD aims to provide the following:
• GUI for prompting for provisioning info
• JSS api read/write of provisioning info
• GUI / loginwindow lock during deployment
• allow Macs to be re-deployed / imaged, and base builds on persistent JSS data, rather than fake pkg receipts.
It supports a number of workflows
1. Mac OOTB
2. Setup Assistant
3. QuickAdd enroled via user or admin
4. User or admin can be prompted for the following provisioning information:
◦ ComputerName
◦ Custom Patchoo "Build" extension attribute (this can be used to scope, and fires a custom deploy-xxx trigger)
◦ Department
◦ Building
5. The JSS has provision details written.
6. A launchagent and bootstraphelper is written to drive the "bootstrap" process.
7. The Mac restarts
8. Bootstrap starts a loginwindow, the screen is locked.
9. Mac pulls provision information from the JSS.
10. Bootstraphelper fires -trigger deploy
11. All policies scoped to this trigger are run (scope geographic or department specific in this way).
12. Bootstraphelper fires -trigger deploy-xxxx (xxx being your build intentifier stored in the JSS ext attrib) - scope build specific policies.
13. Deploy process is finished.
14. Mac restarts and starts update loop.
15. A patchoo update session loops until Mac is fully patched.
16. Loginwindow unlocks.
You can leverage, all some or none of the provisioning details. You can support admin or enduser enrolment and provisioning. Macs that are imaged via Casper Imaging or don't have provisioning information set go in to a "holdingpattern" and notify administrators.
On enrollment complete trigger.
Prompted to confirm and set computername
If you change the computer name, the JSS is checked for an existing computername.
The Patchoo Build EA is read and prompted for.
If no API user with write access is provided within the script, an tech or deployment admin can enter their credentials update the computer record in the JSS.
The Mac restarts. Provisioning looks like this. The loginwindow is locked, and information from the jamf.log is displayed on the lockscreen.
If a Mac is enroled via a non-interactive method (Casper Imaging / Recon network scans) or prompt for info is disabled... the Mac may have no provisioning info. The holdingpattern is displayed, and the JSS is queried every 2 minutes for data. Set a smart group to catch these macs, and email notify your JSS admins to enter provisioning info.
This is beta and the documentation is rough to say the least, but I do encourage you to play with it and provide feedback. We are using it now with great results!
Jump on here - https://github.com/patchoo/patchoo/
Log issues or jump on the jamfnation thread. https://jamfnation.jamfsoftware.com/discussion.html?id=11849
As Casper admins are moving from an "image" based deployment workflows to policy based "thin provisioning" over the top of a factory Apple build, or a vanilla AutoDMGed Mac, PD aims to provide the following:
• GUI for prompting for provisioning info
• JSS api read/write of provisioning info
• GUI / loginwindow lock during deployment
• allow Macs to be re-deployed / imaged, and base builds on persistent JSS data, rather than fake pkg receipts.
It supports a number of workflows
1. Mac OOTB
2. Setup Assistant
3. QuickAdd enroled via user or admin
4. User or admin can be prompted for the following provisioning information:
◦ ComputerName
◦ Custom Patchoo "Build" extension attribute (this can be used to scope, and fires a custom deploy-xxx trigger)
◦ Department
◦ Building
5. The JSS has provision details written.
6. A launchagent and bootstraphelper is written to drive the "bootstrap" process.
7. The Mac restarts
8. Bootstrap starts a loginwindow, the screen is locked.
9. Mac pulls provision information from the JSS.
10. Bootstraphelper fires -trigger deploy
11. All policies scoped to this trigger are run (scope geographic or department specific in this way).
12. Bootstraphelper fires -trigger deploy-xxxx (xxx being your build intentifier stored in the JSS ext attrib) - scope build specific policies.
13. Deploy process is finished.
14. Mac restarts and starts update loop.
15. A patchoo update session loops until Mac is fully patched.
16. Loginwindow unlocks.
You can leverage, all some or none of the provisioning details. You can support admin or enduser enrolment and provisioning. Macs that are imaged via Casper Imaging or don't have provisioning information set go in to a "holdingpattern" and notify administrators.
On enrollment complete trigger.
Prompted to confirm and set computername
If you change the computer name, the JSS is checked for an existing computername.
The Patchoo Build EA is read and prompted for.
If no API user with write access is provided within the script, an tech or deployment admin can enter their credentials update the computer record in the JSS.
The Mac restarts. Provisioning looks like this. The loginwindow is locked, and information from the jamf.log is displayed on the lockscreen.
If a Mac is enroled via a non-interactive method (Casper Imaging / Recon network scans) or prompt for info is disabled... the Mac may have no provisioning info. The holdingpattern is displayed, and the JSS is queried every 2 minutes for data. Set a smart group to catch these macs, and email notify your JSS admins to enter provisioning info.
This is beta and the documentation is rough to say the least, but I do encourage you to play with it and provide feedback. We are using it now with great results!
Jump on here - https://github.com/patchoo/patchoo/
Log issues or jump on the jamfnation thread. https://jamfnation.jamfsoftware.com/discussion.html?id=11849
0.9941 - Autopkg + JSS + Patchoo! & No more Mr. Nice Admin
25/07/14 10:11
AutoPKG + JSS-autopkg-addon + Patchoo
The holy grail of Casper software deployment?
If you don't know how cool AutoPKG is, you best get acquainted. In a nutshell, it will follow a recipe - check, download and repackage software for you, and with the very recent addition of a GUI it will do it at the touch of a button!
I am yet to get my hands dirty with the way it all works myself, but Allister Banks has built a processor for AutoPKG that every JAMF admin should be very excited about.
JSS-autopkg-addon effectively takes freshly built pkgs from autopkg, loads them onto your CDP and then creates the necessary smart groups and policies required for distribution. Cool beans! There has been a bit of talk on JAMF Nation and various channels about some of the shortcomings of Casper software deployment, that it's far too admin heavy. Automating a lot of the tedium around policy and smart group creation will go along way to solving this until JAMF revamps it's software deployment tools.
Calum Hunter has modified the policy and smart group template that JSS-autopkg-addon uses, and it can now dump these freshly created flat pkgs into your patchoo-dev track 100% ready for testing and deployment!
- AutoPKG recipe runs.
- Go to your dev/testing Mac client and start a Patchoo run click "Check for Updates" in Self Service.
- Test deployment and app function.
- Move update to beta.
- Move update to production.
A huge thanks to all the AutoPKG gang, all the Patchoo users and the entire Mac Admin community. We are all doing and ever more importantly, sharing some awesome work! We are the pirates taking over enterprise IT!
Nasty Mode
No more Mr. Nice Admin!
Until now, Patchoo has pseudo forced installations once the defer counter expired. There was only one button, but by design I didn't want a timeout to logout and install if a Mac was unattended.
Unfortunately, in this day and age of modern client management, those tricky users will find a loophole and do their darndest to not install software patches. We have a few users that are deliberately ignoring the all installations prompts. Catching them in the PatchooDeferCount10+ group and sending reminder emails from the JSS worked, sometimes, but at some sites I had to engage support technicians to physically walk to desks and talk with users. That's not a great use of anyone's time.
But in the end, it's too much admin work and there will always be people that don't have the 5 minutes a month it takes to patch their systems. Well, no more....
nastymode=true
When enabled (default), if the final forced update prompt is ignored, users are forcibly logged out and patches are installed. Users ARE allowed to save work and will be prompted. Stuck apps will pause the logout process, but it's persistent and will keep quitting apps until users are logged out.
If you are in the same situation, addressing the issue as a security and compliance matter is the best way to allay complaints. We are a public US company and must comply with SOX, even if it sometimes can be slightly inconvenient for our staff.
Get the latest commit
Licensing
You'll also notice a long overdue license file in the repo as well. Patchoo is released under Apache 2.0.
I'm no fancy big city lawyer, but this pretty much means you can use it how you want. I've had some great interest and been surprised at some of the really cool companies that are using it (most I can't mention unfortunately). Hopefully this means a few more with more stringent legal requirements can use it too!
If you'd like to contribute please feel free to reach out, or get on Github and submit pull requests!