Posted 2015 July 10
I hope many of you have heard of a nice little tool from Joseph Chilcote (@chilcote on Twitter) called outset. Instead of having to write LaunchAgents and LaunchDaemons on your own, particularly for one-off tasks, you can just drop scripts or packages into an appropriately-named folder and let outset do the work for you. I've just started exploring it, but it looks like it will have great potential for us.
When OS X 10.10.4 came out, I started pushing it out to my Lab Macs using Apple Remote Desktop (no Munki or Casper yet). So all is well until I get to the 5 computers where a professor is doing batch processing in Photoshop. These runs can take days sometimes, as he is routinely dealing with hundreds of 1 GB images in a batch. But 10.10.4 is a pretty important update for security reasons, so I want to push it out as soon as possible. So what about having outset do it?
You need to understand, in the words of Joseph Chilcote, this was "another usage that would have never crossed my mind." In other words, who knows if it is going to work! I figured if I could copy the 1 GB update to the Macs in questions in the background, a manually-triggered restart should do the installation for me. So I tried tested this on one the Macs that had not yet been upgraded using ARD and, once I put the 10.10.4 update package in /usr/local/outset/firstboot-packages, I had ARD restart the Macs.
The first attempt was a bust. Even though Apple's installer package was happy to run in the GUI with 644 permissions (execute not set), outset insists on root:wheel ownership and 755 permissions (execute set). So I copied it again (since outset dutifully deleted it afterwards), changed the permissions (using ARD), and rebooted.
This was much more successful, although it did not appear so initially. Because of the way our Labs are setup, we have a restricted user account login automatically after (re)boot. I had expected to see the OS updater to take over the display, but instead, it appeared to login to the user account without any significant delay. By the time I checked the logs (/var/logs/outset.log in this case), it said the install had completed. Yet ARD was still reporting that the Mac was at 10.10.3. I remoted in to the Mac and About This Mac claimed it was 10.10.4. Remembering that the installer, when run manually, triggered its own reboot, I decided to ask ARD to reboot the Mac again. Success! Now both the OS and ARD were reporting 10.10.4.
This was now an instruction that I could give to this prof that he could understand: when you're done your run, Restart, wait 10 minutes, Restart, then you're good to go. (Admittedly, I beat him to it, since it is difficult to predict how long these batch processes will take. The prof usually tries to setup jobs that take a couple of days to run.)
When I floated this out on Twitter, the esteemed Mr. Chilcote suggested I try running softwareupdate in a firstboot script. I had not updated my spare iMac yet, so I gave that a go. I wrote a one-line shell script to invoke softwareupdate from the command line and placed it in outset's firstboot-scripts folder. Different result. The good news: it never did log into a user account; you got the regular boot progress bar as is customary in Yosemite (and later, I presume). The bad news: it got stuck at about 20% progress. I waited 10 minutes, then turned the computer off and tried again. It got to 20% and gave me a much more interesting failure:
Unapproved caller.
Security agent may only be invoked by Apple software.
Ouch. This dialogue box can't be dismissed, despite repeated clicking on the OK button, so it's time to power down again. This time, I start up with the Shift key held down. Lo and behold, a different, fatter, progress bar appears. Now this makes some sense. You see, I decided to write that softwareupdate script so that it grabbed all software updates, not just the 10.10.4 one. This was my spare, so it was entirely possible that some updates had not been pushed to it. What I'm guessing is that softwareupdate thought that the iMac's firmware needed updating. This would have been one of the payload items, so the Security Agent invocation most likely came from the firmware updater.
Once it finished the firmware update, everything seemed to be hunky dory. So my next test is to take a Mac (that I know has current firmware) and test it again. But that will be a while from now, as I indulge my music geekery for a week. I'll update this article when I do so. Of course, you could also do the testing yourself and post the results. Make sure to let me know if you do this and I'll link to your post.
Update - July 21
My test using a Mac mini (Late 2012) pretty much confirmed all of my findings. You see, just as I was getting ready to test, a firmware update for the Late 2012 Mac minis was released. So I ended up testing the Mac mini in the same way as I tested the iMac before it. The result was basically the same: with a firmware update in the softwareupdate payload, the installer stalled (with the progress bar at about 50% in this case) and a manual shutdown was necessary, even after letting the Mac mini sit overnight (~16 hours). Once I manually applied the Firmware update to the Mac mini, I then nuked the boot volume using a DeployStudio workflow that deployed a minimal 10.10.3 image, added outset, and put the softwareupdate script in the firstboot-scripts folder with the proper ownership and (luckily) permissions. When it rebooted, softwareupdate worked properly (even rebooting on its own, if I observed correctly). I may repeat this test again for completeness, but for now, it sure looks like the softwareupdate script method could "just work" so long as there were no complicating updates.
For the record, I used the following script:
#!/bin/sh # make sure we are using Apple SUS because of issues with our own defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL # and now the real reason for this script: softwareupdate --install --all
The defaults command actually failed on the specific image I was using, but it did not stop execution of the softwareupdate command. You could specify which item you wanted to install, but this was more general purpose.
Of course, the random thought in my mind is: could Imagr + outset be a DeployStudio replacement for some based on this? (This assumes your needs are simple and Munki/Casper are not going to be deployed.)
Originally posted on the University of Calgary Integrated Arts Media Labs web site.