munkitools packages and the future

[Greg Neagle]

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 (https://github.com/munki/munki/wiki/Updating-Munki-Tools). 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” `make_munki_mpkg.sh` 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 `make_munki_mpkg.sh` 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 https://github.com/rtrouton/First_Boot_Package_Install_Generator 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 https://github.com/macadmins/installapplications — 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.

-Greg

[Ben Toms]

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:
https://github.com/munki/munki/wiki/Discussion-Group
---
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 munki-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/2497454F-2F75-43CE-937A-BEE5EEB6E3CA%40mac.com.

--

Regards,

Ben

[Eric Holtam]

I initially used Erik Gomez's method to create a mega-package of Munki tools + custom pkgs for the specific reason that MDM's InstallEnterpriseApplications was unreliable to deliver multiple packages to be installed in one fell swoop when MDM enrolled.  It was a welcome workaround at the time, but cumbersome to implement when any of the embedded packages updated.

The addition of adding bootstrap, client config, and no-reboot to the munki tools package generating script solved the issue of me needing to hand edit the mega-package Distribution. 

As of now, my MDM vendor (SimpleMDM) has their own implementation of something like Erik's InstallApplications that if more than one package is assigned in the MDM it uses a script to install the batch instead of relying on the MDM spec to deliver multiple packages.  

All the above is for working around the shortcomings of MDM and the ability to reliably deliver multiple packages. So yes, the need for an all encompassing pkgs is still needed in my opinion. 

Going thru all the above, I think that if option 2 existed during that time it would be the most accessible to admins trying to accomplish the custom deployments. 

I don't see any way to provide a pre-built package for something like a custom configuration plist or certificate as those would need to be supplied at the pkg generation runtime.  

One concern would be that if _any_ package can be added to the mix via the tool, then how many would come back for support on their custom workflows?  Maybe isolating the modularity to just the munki tool options would be most sane.  

-Eric