munkitools packages and the future

Skip to first unread message

Greg Neagle

May 4, 2022, 12:48:44 PM5/4/22
to munki-dev, 'Gregory Neagle' via munki-discuss
TL;DR: we need a better way for Munki admins to customize the initial Munki install.

Once upon a time, for each official release of Munki there was a single installer package. This made it pretty clear what to download and use.

When people decided they wanted to be able to have Munki update itself without always requiring a restart, more complex things were done with that package ( But still the starting point was that same single release package.

As DEP/ADE-based deployment workflows became more popular, and people started using their MDM to install the Munki tools, those same people wanted Munki to be functional without requiring a reboot. Erik Gomez (and others) worked on an alternate package building script that created a munkitools package that could start up all the needed launchd jobs without requiring a restart. This script was eventually merged with the “main” `` script, and admins could choose to build a “regular” munkitools pkg, or a “DEP-style” munkitools pkg that did not require a restart.

(Why couldn’t the DEP-style munkitools package just replace the “regular” package, you might wonder. The reason is simple: if Munki itself is installing a new munkitools package, and scripts in the package load/unload/reload the launchd jobs Munki itself is running from, a Munki run would be killed while it was trying to upgrade itself. In this scenario, it’s safer to just require a reboot, and do that shortly after the install is complete.)

(Also: the only time a reboot would be needed in the above scenario would be when installing a different version of the component package that contains the main launchd files. This package version has been stable for _years_. Still, it’s possible it could change in the future.)

It’s always been a but problematic for admins to build their own munkitools packages. There are many not-well-understood requirements. Not all versions of Xcode can build all versions of the Munki tools. Building the Python framework, especially a Universal build, can be derailled by other things installed on the build machine (like Homebrew). So in an effort to make things easier for many admins, new Munki releases began to have two packages: a “regular” package, and a “DEP-style” package. This eliminated the need for some admins to build a custom package. Of course this added the risk that admins would use the wrong package for the install sceanrio.

The munkitools 5.7 beta has a big change in the package: this package should be usable in both “normal” and “DEP” install scenarios:
    1) If there is no current install of the munkitools_launchd package (com.googlecode.munki.launchd), a postinstall script will start up the needed launchd jobs without requiring a restart.
    2) If the munkitools_launchd package to be installed has the same version as the currently installed munkitools_launchd package, install of these components is skipped by default. No restart is required.
    3) If the munkitools_launchd package to be installed has a different version from the currently installed munkitools_launchd package, a restart is required.

Unless you are upgrading from a very very old version of Munki, or the munkitools_launchd package is updated in the future, the third scenario will not occur.

So now future releases of Munki can ship a single package usable for more installation scenarios.

But all is not perfect here. There are other reasons Munki admins build their own packages. There are options in `` to include additional component packages that:
    - Set Munki’s bootstrap mode
    - Start a `managedsoftwareupdate —auto` run immediately after install
    - Install Rosetta2 on ARM-based hardware. (Needed to ensure many older packages actually _install_ on Apple silicon)
    - Include a configured /Library/Preferences/ManagedInstalls.plist
    - Install a a client certificate for server mTLS mutual authentication, at /Library/Managed Installs/certs/.

While many of these tasks can also be accomplished by installing additional packages in coordination with installing the munkitools, package, there are a couple of reasons admins have wanted these included with the Munki tools: 1) Providing an “all-in-one” package for users (or techs) to manually install, 2) Working around the unreliability of MDM installing more than one package at enrollment time.

This, then, brings us back to admins trying to build their own custom packages and running into issues with Xcode or pip or other challenges.

It would be impossible to pre-build packages that meet all these needs (and I am aware of a few other needs, like re-branding, adding “middleware” and/or adding additional modules to the Python framework).

But how can we make this easier for Munki admins? A few possibilities occur to me:

1) Make the package build scripts/process more modular, so admins can add additional component packages, or replace some, without having to actually (re-)compile the GUI apps or the Python framework.

2) Create and recommend the adoption of a tool similar to Rich Trouton’s that would allow Munki admins to easily bundle the munkitools package plus additional packages into a single wrapper package. Provide pre-built packages that set Munki’s bootstrap mode, started a `managedsoftwareupdate —auto` run, and other tasks. Admins could of course add other packages if they desired.

3) Advocate for the use of a tool like Erik Gomez’s — which works around the unreliability of MDM installing more than one package at enrollment time. Admins would then define a list of things to be installed which included the munkitools plus additional packages.

At first pass, #2 seems the easiest: both to implement, and for admins to understand and use. I’m curious about other thoughts about these proposals, or other possible solutions to these problems.


Ben Toms

May 4, 2022, 1:06:18 PM5/4/22
to, 'Gregory Neagle' via munki-discuss
To add another datapoint, we deploy the normal PKG regardless if ADE enrolled or not.

This is due to jamJAR manually running managedsoftwareupdate so the launchd items aren’t really worried about until a reboot.

And, we don’t deploy Munki via Munki.

For us, a single pkg wouldn’t be the holy grail here (such as option 2). But option 2 seems to be the best option. 

Find related discussion groups here:
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit



Ben Toms

May 4, 2022, 1:21:48 PM5/4/22
Realised this was a ramble.. but you’re right in saying offering a pkg to suit all is an impossible task.

But, a modular way to allow admins to create their own pkg (option 2) sounds great. 



Vaughn Miller

May 4, 2022, 1:37:48 PM5/4/22
I'm using #3, but I agree that #2 is likely to be more accessible to more people.



Gregory Neagle

May 4, 2022, 3:57:57 PM5/4/22
I don’t think adopting approach #2 would prevent an admin from using approach #3 if they desired. 

Sent from my iPhone

On May 4, 2022, at 10:37 AM, Vaughn Miller <> wrote:

Vaughn Miller

May 4, 2022, 4:02:24 PM5/4/22
Yes agreed.  

Reply all
Reply to author
0 new messages