Professional Training and Support for Munki

munkiOne of the objections some organizations have against using open source tools like Munki is that they want to pay for professional training and support.

Amsys has professional training for Munki:

http://www.amsys.co.uk/amsys-training-courses/coursebooker/munki-101/

If you can’t get to London, check out other professional support and training organizations around the world:

Munki Professional Support

Professional Training and Support for Munki

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.

Revisiting receipts for OS X installs via Munki

Packaging Lab at MacTech Conference 2015

If you are planning on participating in the Packaging Lab this week at the MacTech Conference, you may want to download some materials in advance when you aren’t competing with all the other people for limited conference Wi-Fi bandwidth. Note — don’t install these items — just download their installers and keep them handy for the lab.

ExifTool pkg:
http://www.sno.phy.queensu.ca/~phil/exiftool/ExifTool-10.03.dmg

Adobe Reader 11 pkg:
http://ardownload.adobe.com/pub/adobe/reader/mac/11.x/11.0.10/en_US/AdbeRdr11010_en_US.dmg

Google Earth pkg:
http://dl.google.com/earth/client/advanced/current/GoogleEarthMacNoUpdate-Intel.dmg

Firefox dmg:
http://ftp.mozilla.org/pub/firefox/releases/latest/mac/en-US/Firefox%2042.0.dmg

Google Chrome dmg:
https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg

Some optional things:

Packages:
http://s.sudre.free.fr/Software/files/Packages.dmg

Suspicious Package:
http://www.mothersruin.com/software/SuspiciousPackage/download.html

Pacifist:
https://www.charlessoft.com

Packaging Lab at MacTech Conference 2015

Pseudo-“Payload-free” pkgs with pkgbuild

“Payload-free” packages — that is, Apple installer packages that do not have a file payload, but only run scripts, are a nice tool for OS X admins to have. They provide a convenient way to deliver and execute scripts as root. If you have a way to install packages on your managed machines, you can also run scripts as root by wrapping them in a “payload-free” package.

Rich Trouton has written up the basic procedure using the built-in `pkgbuild` tool: https://derflounder.wordpress.com/2012/08/15/creating-payload-free-packages-with-pkgbuild/

But payload-free packages built this way have a “feature” that can sometimes prove problematic. Flat packages built with pkgbuild using the --nopayload option do not leave receipts in the pkgutil database. This means it can be difficult to determine if a given payload-free package has already been installed on a given machine.

This is especially annoying with Munki: by default, when installing a package, Munki uses the package’s receipt(s) to determine whether or not the package has been installed. Without that receipt, and with no other information, Munki can’t tell if the package has been installed.

Fortunately, it’s trivial to make a pseudo-payload-free package that leaves a receipt. All we need to do is specify an empty payload!

Here’s how we make a “true” payload-free package (that does not leave a receipt):

pkgbuild --nopayload --scripts /path/to/scripts_dir --identifier org.example.payloadfree --version 1.0 MyGreatPayloadFree.pkg

and here’s a “pseudo” payload-free package that does leave a receipt:

mkdir empty
pkgbuild --root empty --scripts /path/to/scripts_dir --identifier org.example.payloadfree --version 1.0 MyGreatPayloadFree.pkg

That’s it! Instead of using the --nopayload option, we create an empty directory and point the --root option at it. The package is built with the empty payload, and when installed, the package leaves a receipt.

Pseudo-“Payload-free” pkgs with pkgbuild