This week I added support for macOS Mojave’s new Dark Mode to the GUI apps in Munki: https://github.com/munki/munki/commit/dea412d72e277265bc98dea2b358be5a830739b6
I initially thought adding Dark Mode support would be problematic. Most of the documentation and advice I’d seen seemed to imply that you had to build against the 10.14 SDK to get support for Dark Mode.
Continue reading “Notes on adding support for Dark Mode”
This morning while reviewing new updates on my reposado server I saw this new update:
091-76348 macOS High Sierra 2018-04-10 []
I didn’t think much of it; various “Install macOS High Sierra” updates have appeared in the softwareupdate catalogs since early in the High Sierra beta cycle: the App Store, when installing the “Install macOS High Sierra” application, downloads resources from these catalogs. (See https://managingosx.wordpress.com/2017/09/26/some-stuff-about-install-macos-high-sierra-app/ for more info).
But then I saw this cry for help on the munki-discuss list: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/munki-discuss/I9nA-340mO4/KVQTJMEGCgAJ
Apologies if this has been asked and answered already, but we’re in a desperate time crunch. This morning, on the second day of standardized testing for our district, High Sierra is appearing as a “regular update” instead of an App Store option, so naturally MSC offers it:
It appeared that “macOS High Sierra” was being offered as an Apple software update (which Munki was then offering to install).
It might come as little surprise to find out that I use Munki in my organization to manage software installations on macOS.
Munki is really good at keeping software up-to-date. Every time it runs, it compares the versions it has on the server against the versions installed on the local machine and updates any software at a lower version than it has on the server.
Its default behavior when an item on the local machine has a higher version than that on the server is to leave it alone. This is great when you have users that for whatever reason need to test newer versions (or perhaps they are actually developing the newer version of the software).
I also use AutoPkg to automate finding new software updates and to import them into my Munki repo. For us, AutoPkg checks on approximately 50 items each day, importing anything new into my Munki repo into a testing catalog.
On Tuesday of this week, Mozilla released Firefox 59. AutoPkg found the new release and imported it into Munki as expected. On Wednesday, I noticed that AutoPkg had imported Firefox 60! I looked at the installed application, and its version was actually 60.0b3. Someone at Mozilla had goofed and pointed the “latest firefox release” link at the 60 beta. Later in the day this goof was remedied and the link once again returned Firefox 59.
But my AutoPkg run had occurred while the Mozilla site was offering 60.0b3, and so it was downloaded and added to my Munki’s repo’s testing catalog. 25 Macs in my organization (including my own laptop) now had Firefox 60.0b3 installed.
(Side note: because of the way Munki does version comparisons, when the final release of Firefox 60 comes out, if it is versioned as “60.0”, Munki would not “upgrade” from 60.0b3 to 60.0 – “60.0b3” compares as higher than “60.0”.)
I wanted to configure Munki to downgrade any install of Firefox 60.0b3 to Firefox 59. Since by default Munki leaves higher versions alone, this is not exactly obvious how to do.
Continue reading “Using Munki to revert or downgrade software”
Perhaps you are starting to worry about the future of “imaging” as a deployment/initial configuration method for Macs.
(I’ll define “imaging” as block-copying the contents of a disk image file to a disk volume, and resulting in a bootable, fully-functional machine.)
If you are concerned about the future of imaging, you might want to start investigating macOS installation-based workflows for deployment/initial configuration.
The basic idea is this: a workflow that either installs macOS, or starts with the factory os installation. It then installs additional packages that serve to enroll the Mac in whatever your ongoing management system is (Jamf Pro, Filewave, Munki, etc). It then becomes the management system’s job to finish the initial setup of the machine.
Here are a few things you might want to look at:
Here are some links from my presentation at MacTech Conference 2017, “Imaging is Dead: Now What?”
Der Flounder, “Imaging will be dead soonish”: https://derflounder.wordpress.com/2017/01/10/imaging-will-be-dead-soon-ish/
AutoDMG: https://github.com/MagerValp/AutoDMG
Imagr: https://github.com/grahamgilbert/imagr
DeployStudio: http://www.deploystudio.com
Apple, “Upgrade macOS on a Mac at your institution”: https://support.apple.com/en-us/HT208020
Apple, “APFS and Imaging”: https://help.apple.com/deployment/macos/#/apd545ec8b69
createbootvolfromautonbi.py: https://github.com/munki/macadmin-scripts/blob/master/createbootvolfromautonbi.py
Erik Gomez, Custom DEP series: http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-1-An-Introduction/
http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-2-Creating-a-custom-package-and-deploying-Munki/
http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-3-Best-Practices/
http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-4-The-Future/
http://blog.eriknicolasgomez.com/2017/04/05/Custom-DEP-Part-5-Dynamic-InstallApplication/
http://blog.eriknicolasgomez.com/2017/04/27/Custom-DEP-Part-6-Vendor-Announcement-and-Presentation/
http://blog.eriknicolasgomez.com/2017/07/27/Custom-DEP-Part-7-Getting-started-with-AirWatch-9.1.3/
Victor Vranchan, Munkiing around with DEP: https://groob.io/posts/dep-micromdm-munki/
Now that macOS 10.13 High Sierra is out, it’s time to start taking about High Sierra stuff!
Munki 3 added support for upgrading macOS via the Install macOS.app for Sierra and High Sierra. A Munki admin need only download the installer from the App Store, and do
munkiimport /Applications/Install\ macOS\ High\ Sierra.app
to import the High Sierra installer into their Munki repo.
But there’s a wrinkle. Many people (including yours truly) were sometimes getting an installer application “stub” when downloading the Install macOS High Sierra application from the App Store. This “stub” application did not include the Contents/SharedSupport folder or its (very important) contents. The needed resources were instead downloaded “on-the-fly” when you ran the Install macOS High Sierra application.
This “stub” application is not useful as something to import into your Munki repo, or to use with AutoDMG or autonbi, or similar things. For these you really want the full installer, that is, one that contains all the needed installation resources in Contents/SharedSupport.
Many theories and ideas were put forth as to what caused one to get the stub vs the full installer. While I’m still not 100% sure about this, I think we’ve narrowed in on the cause.
It appears that when the App Store is downloading the installer app, it also uses softwareupdate to get the resources that normally reside in Contents/SharedSupport. If com.apple.SoftwareUpdate has been configured to use a CatalogURL that points to a softwareupdate catalog that does not contain product URLs for the needed Install macOS High Sierra resources, you get the “stub” application instead.
If, however, softwareupdate is using either Apple’s default CatalogURL, or is pointed to an internal CatalogURL that contains the needed products, you get the full installer.
Currently, the needed resources are Product 091-34298, “Install macOS High Sierra”, but this will almost certainly change over time.
TL;DR: to get a full High Sierra installer from the App Store, make sure softwareupdate is pointed at Apple’s softwareupdate servers or an internal server in which you have synced and made available the “Install macOS High Sierra” product.
Thanks to many people on the MacAdmins Slack for chipping in with their observations.
I’m hoping for great wifi, but if you are participating in the Munki workshop next week at MacTech Conference, you might want to download these things in advance:
Current release of the Munki tools: https://github.com/munki/munki/releases/download/v2.8.2/munkitools-2.8.2.2855.pkg
munki-pkg tools: https://github.com/munki/munki-pkg/archive/master.zip
Current release of MunkiAdmin:
https://github.com/hjuutilainen/munkiadmin/releases/download/v1.4.3/MunkiAdmin-1.4.3.dmg
Current Google Chrome installer: https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg
Current Audacity installer: https://www.fosshub.com/Audacity.html/audacity-macosx-ub-2.1.2.dmg
Like many people tasked with managing OS X/macOS machines, I use VMware Fusion to do a lot of testing. Fusion enables me to test in various versions of OS X, and to easily make changes and revert to a prior state. It’s a great tool.
For some of the testing I do, it’s important to be able to quickly and easily build a VM that is configured just like the “real” machines I manage. There are a few way to do that. Since we build our machines by booting into a NetBoot image and using Graham Gilbert’s excellent Imagr (https://github.com/grahamgilbert/imagr) to restore an image, it’s great that we can also boot Fusion VMs from a NetBoot image.
Continue reading “Stupid Tricks with createOSXinstallPkg and VMware Fusion”
One 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:
Managing OS X 