@loceee looking forward to testing this! Are you going to be at JNUC?
I'd be interested in checking this out and compare to Casper's 9.x method.
Does it have a max deferment, meaning you can defer it up to X days before it's forced?
@golbiga - unfortunately I am on the other side of the world and am expecting a new addition to my family any minute. I can't make it... but some of my co-workers will be there. Maybe next time.
@jwojda - Yes, it has a defer count that can be set. Defaults to 10x. If you are running on a daily trigger, that's 10 days. It's just stored in a plist, change it with defaults for specific computers with a policy or edit it in the script.
Here's a sample log out from the jss...
Running script 0junki.sh...
Script exit code: 1
Script result: junki --promptinstall: swupdate pkgs waiting to be installed
junki --promptinstall: -------------------------------------
junki --promptinstall: MacBookProEFIUpdate2.7-2.7
junki --promptinstall: MacBookProSMCUpdate1.7-1.7
junki --promptinstall: RAWCameraUpdate4.09-4.09
junki --promptinstall: ThunderboltFirmwareUpdate1.2-1.2
junki --promptinstall: iTunesXPatch-11.1.0
junki --promptinstall: OSXUpd10.8.5-10.8.5
junki --promptinstall: -------------------------------------
junki --promptinstall: user selected install later
junki --promptinstall: USERNOTIFY:: Installion Defered, You can defer the installation 3 more times
junki --promptinstall: jamf is running a recon...
Retrieving inventory preferences from https://jss.interpublic.com.au:8443/...
Finding extension attributes...
Locating hard drive information...
Locating hardware information (Mac OS X 10.8.4)...
Has anyone been able to run the jamfhelper when no one is logged in?
I'm trying to run software update after imaging and/or when users have logged off for the day, but I want the splash screen to come up to prevent someone from logging in while the updates are in progress.
Just a side note, lots of thanks for the scripts already posted in this thread. They've been really helpful!
@jennifer_unger, its not that easy to do because of security features in the OS, but you can look through this older thread. There are some solutions posted, including a LaunchAgent that calls a script to do a full screen jamfHelper message.
https://jamfnation.jamfsoftware.com/discussion.html?id=24
@ Lachlan is there any place where I can get junki shell script/s?
I really would like to look into this as this is what we are looking for since quite a while.
Thanks,
Maik
Hi @maik.sanftenberg,
I will release in a month or two once I've finalised testing and tidied things up (I am also about to go on paternity leave for a couple of weeks - sorry!). It's almost feature complete now, I only need to add a --priority / --forced mode so that Casper pkgs that need to be prioritised / installed by themselves are handled (ie. OSUpgrade pkgs from Greg Neagle's awesome createOSXinstallPkg) then it's testing and tidy up.
As a teaser I have got the "bootstrap" mode up and running well. In the same way munki bootstraps, the Macs boot, lock the loginwindow, check, then install all updates, reboot as necessary, then loop again until completely patched.
Screenshots... just using jamfhelper -fs to give some UI feedback.
https://interpublic.box.com/s/jg9l7mx3on2kw6sipc74
@loceee Any chance of taking a look at the code as it stands?
@bmwarren][/url - soon I promise!
I just need to make the logout mechanism a little more robust and quash a couple of final bugs.
I've update my presentation to convey a couple of changes - https://interpublic.box.com/s/yj4iudzllxizs3z9r03a
and improved the UI feedback during bootstrap - https://interpublic.box.com/s/jg9l7mx3on2kw6sipc74
Good news is it's now feature complete for a testing release. I will finalise my internal testing and get some docs together. I hope to have something to share by the end of next week.
Here's a shot of the new --osupgrade mode that is designed to handle unattended installers made by Greg Neagle's awesome createOSXInstall.
https://interpublic.box.com/s/4buc4y32o9pxol0hzifr
Thanks for putting this together Lachlan. Looks similar to what we hacked together off Andrew and others' custom scripts (see below), but the overall problem at hand remains one of my biggest frustrations with the Casper suite: minimal OOTB user dialog options. There have been times when all I want to do is present a multiple-choice dialogue to a user and end up spending hours pouring through old scripts to hodgepodge something together that will fit the need. SW updates are something that are such a core element of ensuring a secure endpoint that I really hate rolling the dice with custom anything every time I make change to our workflow. More stuff like this is a good thing.
external image link
That looks pretty neato @clifhirtle][/url][/url !
Part of the junki magic is that Casper deployed software would also appear in the dialog.
Sorry to hijack this thread, but there is a bit of an issue with junki output and Casper 9. If you could all vote this up it would help with usability on the JSS v 9.
https://jamfnation.jamfsoftware.com/featureRequest.html?id=1670
@loceee Yes, no part of JSS v9.x respects line breaks of any type. I'd call it a defect. I had a brief support case and was told
Thanks for contacting us today about line breaks in Self Service. We are currently looking to correct that issue in an upcoming release but I'm not sure when that will occur.
Unfortunate; it breaks functionality and makes things looks messy and unprofessional, for instance Self Service descriptions can only be long run-ons. I definitely up voted your feature request!
Hey @loceee,
I wanted to check out your code but it seems that you box link died. Would your consider hosting on github? or re share the box link?
hello @loceee,
Any updates on your software? Would like to see if it would fit our users needs.
Thanks,
Hello @loceee
Ping you again on any updates to the junki script you had talked about last year. Your method looked like the best method of getting updates to our clients systems. Any info on where this stands would be great. Even if its to just let the JAMF Community know that it may never see the light of day.
Thanks of your time.
Looking back at the preso you have posted above Lachlan, is it correct to assume the junki script prompts for all updates/installs in the same dialog (versus each individual update selectable like Munki's managed software install dialog)?
The way Munki permits individualized installers is really the "special sauce" I would love to see implemented in the Casper suite.
The script I am using currently for SW updates (inspired off great work @acdesigntech and others above have contributed) already allows for integration of 3rd party installers/updates, specifying # of postpones, etc so the really big missing piece just remains the lack of user opt-in/out for specific updates similar to the ASU/Munki UI.
@clifhirtle, would something like this be more what you;re looking for?
external image link
In case you're wondering that's simply cocoaDialog using the checkbox option available in the 3.0 beta releases. The items listed in it weren't hardcoded, but generated dynamically by running a softwareupdate -l command and parsing the output, then dropping it all into an array that cocoaDialog can use.
Although this is only a start, I'm pretty sure I could put something together that would take any checked items and correctly install only those updates and skip the others. I've done some similar things recently, so I can take what I've already scripted and adapt it to this purpose.
If that's something you might be interested in, let me know and I'll see what I can put together.
Sorry all, been crazy with every spare moment taken up outside of work spent on selling, finding, buying a new home + new baby and endless illness going through home! That and one of our guys has gone and left to take a role with JAMF so I've been picking up more overflow support stuff (naughty Rusty) :)
Finally all settling down now, moving next weekend and I might have some more time to nail down the last couple of things. I will also need clearance from legal to release it, so thanks for your patience!
I like the optional installs @mm2270][/url !
As for junki's design, it doesn't allow optional installations as such, it's really ONLY about patching stuff. I didn't want to re-invent the bits of Casper that are already are great.
Here are my thoughts around this is, we have 3 solutions for deploying software with Casper, policies (silently), policies (self service - hence optional installs) and via Casper Imaging.
The workflows we are using (and I will be recommending in my documentation) will be as follows.
- New Mac
- Casper Imaging (thin or erased and install a vanilla OSX unbooted with an overload of apps, and configuration via scripts, MCX, profiles - nothing should be "baked in" any base images).
-- (Casper Imaging and configurations is a supported, and quite easy way to deploy initial software on to a computer. I DO think it should be renamed to "Casper Deploy" as you don't have image with it.)
- Reboot
- Casper Imaging does it firstboot script (which includes junki bootstrap enable script)
- Reboot
- junki bootstrap does a recon, update install, apple software update loop until all updates are applied - this will compensate for any version drift in your computer configurations.
From then on, junki patching is run on a regular schedule (daily if you like) and machines are patched going forward, but allowing optional installs is not part of this workflow. If a user wants Firefox installed, they perform this via Self Service... since junki scopes update patches via smart groups, once Firefox is installed, it falls in the smart group and junki will then perform updates on it... but if it's not present it won't be installed via junki, nor am I planning on making any installations optional (apart from deferring).
A new feature I've added since last chat is an emulation of the munki "mainfests".. so you can scope testing / dev / production patches via JSS groups. eg. you add a few power users to your junkiBeta group, put all your testing Macs into the junkiDev group.
I know some people run a completely separate JSS for dev, which I don't really like when we are talking about patch deployment. It makes sense to test other things in Casper, but moving a patch (policy, pkg and smart group) between environments is cumbersome, (I did see Bryson at JAMF is working on something to make it easier), but I don't think it's the right approach myself. Using this method you have visibility of patches in testing in a single JSS, and even the ability to have a number of "testing levels" eg. dev/alpha/beta/powerusers/itstaff/brave/suckers/production.
on patching runs junki does the following,
queries the JSS to see if the computer is in junkiBeta, junkiDev group.
- if so, it fires an update-dev / update-beta trigger, you can then attach your "beta" version of the patch via this policy. Production machines that aren't in special groups will just fire the "update" trigger.
- it also dynamically re-writes the apple software update catalog if you are using reposado / netsus... so you can also have Macs in the junkiBeta group get pointed to http://yoursoftwareupdateserver.domain:8088/content/catalogs/others/index-$osxversion.merged-1_beta.sucatalog based on JSS group membership!
Super cool, and it works great! You can setup dev / beta / production branches for your Apple Software Updates as well!
Now for release, I plan on releasing the bash version which has somewhat spiralled out of control. It's not pretty, but functionally I think it does all most will need. I am hoping if I open source it smarterer people than I can refine it.
In the longer term, it should all be re-written in Python (which I am learning myself).
Stay tuned.. I promise it is coming! Lach
@mm2270 I'm interested how you are leveraging this option and script to allow the people to choose what update they want.
Is it possible for you to share it? Thanks in advance.
@maik.sanftenberg - stay tuned. I'm hashing something together for this, since I'm guessing it may be of some interest to some here.
What I posted above was an example. Yes, its a script, but it wasn't going any further than that dialog. I plan on making it more functional, more as an experiment or contribution to the community than anything else. We very likely would not use it where I am since all our clients are local admins and can run Mac App Store/Software Update whenever they want.
@chifhirtle I am testing your updates script. Very nice work. I am using it on Mavericks and JAMF 8.73. I am a little confused on the "NonSysCore" functions/variables. Can you explain a little on that? Thanks and sorry for coming in late here.
@dvasquez see @acdesigntech's explanation on the NonSysCore calls here:
https://jamfnation.jamfsoftware.com/discussion.html?id=5404#responseChild33797
and here:
https://jamfnation.jamfsoftware.com/discussion.html?id=5404#responseChild38161
In short, these variables are a way to fire off additional, non-Apple SW update calls to other Casper policies. This could be updates for things like Flash, Java, or whatever. The catch is that you will need to be running HTTP-based distribution point(s) to take advantage of a policy within a policy, since SMB (AFP as well?) policies will already have the DP mounted for your primary SW update policy, thereby generating a "could not mount DP" error when it tries to call the NonSysCore sub-policies. For this reason I actually do not use them, instead simply running my Java/Flash/Office updates through separate policies, scoped to tiered deployment timeframes (from testing to users to directors), and scheduled through a traditional change management process.
Ultimately, I think we are all barking up the same tree here: pushing core security updates on X timeframe, permitting deferment within reason for major reboot updates, and integrating 3rd party security updates through either sub-policies or additional dialoging.
What I like about the pick and choose approach presented by @mm2270 above is that any of these dialogs are really just a veneer that can be tied back into any number of different Casper policies/deployments/actions/etc. This permits a greater freedom in imagining new approaches to user engagement, filling in the grey area between traditional Self Service (opt-in) and push policies (opt-out).
@clifhirtle:
The catch is that you will need to be running HTTP-based distribution point(s) to take advantage of a policy within a policy, since SMB (AFP as well?) policies will already have the DP mounted for your primary SW update policy, thereby generating a "could not mount DP" error when it tries to call the NonSysCore sub-policies.
The workaround is to keep your kick-off/notification script in the end user's system, somewhere like /Library/Management/Scripts, and have your root policy simply invoke that script. No DP mounted, and the script can call your patching policies (like I've said before, I do this with a jamf policy -trigger patchme, and we have a group of policies with that custom trigger).
