Munki 2.7.0 released

https://github.com/munki/munki/releases/tag/v2.7.0

Head on over to GitHub for the details.

Advertisement

Revisiting receipts for OS X installs via Munki

Background

When using Munki to upgrade OS X with a package created using createOSXinstallPkg (https://github.com/munki/createOSXinstallPkg), the recommendation has been to change the auto-generated receipts array:

https://github.com/munki/munki/wiki/Installing%20OS%20X#receipts

The intention here was to provide something that would satisfy Munki’s check to see if an item needs to be installed: if the recommended receipt is present, Munki won’t attempt to (re-)install the package that installs OS X.

A problem

However, I recently discovered an issue with this approach. For some machines here, an “InstallYosemite” item was added to their manifest’s managed_installs some time ago to force an upgrade to Yosemite. Once that upgrade was complete, the normal installcheck mechanism found a receipt for “com.apple.pkg.BaseSystemBinaries” of version “10.10.0.1.1.1412852630” or higher, and did not offer to reinstall Yosemite, even though the item remained in “managed_installs” in that machine’s manifest.

Later we added “InstallElCapitan” as an optional_install for all users (in an included_manifest). If a user with a machine manifest like the one described above then chose to self-upgrade to El Capitan, as part of the El Capitan install, the “com.apple.pkg.BaseSystemBinaries” receipt is removed. (Note that at https://github.com/munki/munki/wiki/Installing-OS-X/17e17bfdc80727bbd83595359eec6db2741fe88c, the previous recommended receipt to check for El Capitan is “com.apple.pkg.Essentials” since the “com.apple.pkg.BaseSystemBinaries” is not present in an El Capitan install.)

Once the El Capitan upgrade is complete, when Munki later checks for updates, it encounters “InstallYosemite” in the managed_installs. Since the “com.apple.pkg.BaseSystemBinaries” receipt is no longer present, it decides it needs to install Yosemite once again. This of course, fails, since the package itself has an installcheck, which errors with:


Cannot install on volume / because it is disabled.
-------------------------------------------------------------------------
installer: Cannot install on volume / because it is disabled.
installer: You can’t upgrade this version of OS X because a newer version
is installed.
-------------------------------------------------------------------------


If your InstallElCapitan package also includes the Munki bootstrap flag (to ensure all other needed updates for El Capitan are performed), this can lead to a loop where Munki attempts to install Yosemite, fails, tries again, etc.

A fix

The obvious fix is to remove “InstallYosemite” from all manifests once you are offering “InstallElCapitan”. But I think I have a way to avoid this situation in the future. I will recommend a different installation check item for createOSXinstallPkg-type items.

Instead of modifying the auto-generated receipts array, I will now recommend adding an installs array. Here’s one for El Capitan:


<key>installs</key>
<array>
  <dict>
    <key>ProductVersion</key>
    <string>10.11.4</string>
    <key>path</key>
    <string>/System/Library/CoreServices/SystemVersion.plist</string>
    <key>type</key>
    <string>plist</string>
    <key>version_comparison_key</key>
    <string>ProductVersion</string>
  </dict>
</array>


This directs Munki to look at the ProductVersion key in /System/Library/CoreServices/SystemVersion.plist, and compare it with 10.11.4. (you could even just make it “10.11” to prevent Munki offering this as an upgrade to 10.11.[0-3] machines.)

/System/Library/CoreServices/SystemVersion.plist exists in all versions of OS X, so it’s a better comparison than package receipts that may or may not exist in future versions of OS X. And it’s easier to revise in the future since the ProductVersion maps to the OS X version you are installing.

PSU Mac Admins 2015 “What’s New with Munki” session slides

…are available here.

“Building” 2015 Macs

We’ve recently gotten a few of the new 2015 Macs, specifically the new MacBook Airs and 13″ MacBook Pros. These models have new builds of 10.10.2, and won’t boot from our current NetBoot/DeployStudio Server.

While there are ways of capturing the hardware-specific OS so you can use it with AutoDMG and to create NetBoot sets, usually what we do with new hardware like this is employ a “no-imaging” process: we boot the new machine in Target Disk Mode, attach it to another Mac, and install some “bootstrapping” packages on the new Mac. For us, that’s four packages:

• A package to create a local admin account
• A package to disable the Setup Assistant
• The Munki tools package
• A package to put Munki in “bootstrap mode” on first boot.

Once these packages are installed on the new machine, we shut it down, connect it to the network, and start it up. Munki takes over and installs everything else we need.

This approach has worked well for us in the past with new hardware, and allowed us to deploy new hardware to users much faster than if we had to build hardware-specific NetBoot and AutoDMG images.

But these new 2015 Macs were throwing us a curve ball. After using Target Disk Mode to install the packages, upon reboot the Macs were refusing to boot, or booting very slowly. A check with Disk Utility claimed the startup volume had unrepairable filesystem corruption, and advised us to back up any user data, format, and re-install.

We saw this behavior on multiple new 2015 machines. Two things that stood out to me:

• The new machines all ship with an unencrypted CoreStorage volume as their main system volume, and
• We were connecting these machines (in Target Disk Mode) to a Mac running Mavericks (10.9.5).

My theory was that there is a bug causing the Installer on Mavericks to do something “wrong” when installing to a Yosemite CoreStorage volume that led to file system corruption.

I did not have the time (or desire) to get to the bottom of this issue; I needed to find a successful procedure for getting these new 2015 Macs to build. I found two.

First one: after starting the new Mac in Target Disk Mode, connect to another Mac running OS X Yosemite 10.10.2, and install the bootstrapping packages.

Second one: Boot the new Mac into the Recovery partition. Connect a USB drive (a flash stick will do) containing the bootstrapping packages. Open the Terminal from the Utilities menu and use the command-line installer to install the bootstrapping packages onto the main partition.

With either method, things proceeded normally and there was no filesystem corruption.

UPDATE: after seeing some reactions to this post on Twitter, until we understand more about this issue, I’d recommend using the second approach (via Recovery partition) — it’s possible this is more about Thunderbolt/Target Disk Mode than it is about 10.9 vs 10.10.

I hope this saves others some time and headaches.

Gatekeeper Configuration Data and XProtectPlistConfigData and Munki and Reposado, oh my!

If you haven’t read this already, please do:

http://macops.ca/os-x-admins-your-clients-are-not-getting-background-security-updates/

I’ll wait.

Done? OK. Concerned? No? Then you can skip the rest of this post.

If you are concerned, and would like to make sure your managed machines have these security updates, I have a solution for you — if it affects you (and you use Munki and Reposado; so what, about six people?)