Gregory Neagle
unread,Aug 21, 2024, 7:43:56 PMAug 21Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to 'Gregory Neagle' via munki-discuss, munki-dev
Weeks of betas and preview releases, and no-one noticed this issue:
Munki 6.6 is the first release with a new launchd component package in many years.
Because prior versions of the launchd component package required a restart when doing an upgrade install, a common strategy was to decompose the Munki distribution package into its components, and not install the (unchanged) launchd component package on upgrade, thereby avoiding a restart (which would just add friction and delay to a new Munki version rollout).
Munki 6.6 requires a new set of launchd plists, and so this component package must be installed. To avoid the need for a restart, a new helper tool manages the unloading of the prior launchd jobs and the loading of the new launchd jobs. This should allow upgrades to Munki 6.6 and later to be done by simply installing the distribution package, without all the “decomposition” steps.
But if you are using the decomposition technique, or using the munkitools6.munki AutoPkg recipe (which uses the decomposition technique) you need to be aware of an issue:
The munkitools6.munki AutoPkg recipe does NOT mark the munki_launchd package with “unattended_install” as True. (This would have been the correct behavior prior to version 6.6). But this means that Munki will NOT install the updated launchd package in an unattended manner, and will require user cooperation. Since Munki cannot install the launchd package unattended, it will also refuse to upgrade other component packages that declare they require the launchd package:
In ManagedSoftwareUpdate.log, it might look something like this:
Aug 21 2024 08:42:06 -0700 Install of munkitools_admin-6.6.0.4686.pkg was successful.
Aug 21 2024 08:42:06 -0700 Skipping install of munkitools_launchd because it's not unattended.
Aug 21 2024 08:42:06 -0700 Skipping unattended install of munkitools_core because these prerequisites were skipped: munkitools_launchd
Aug 21 2024 08:42:06 -0700 Skipping unattended install of munkitools because these prerequisites were skipped: munkitools_core, munkitools_launchd
Aug 21 2024 08:42:06 -0700 Skipping unattended install of munkitools_app_usage because these prerequisites were skipped: munkitools_core, munkitools_launchd
This might lead to problems!
In the short term, if you are using the munkitools6.munki recipe or any variation of the “decomposition” approach, you should (manually if needed) mark the munkitools_launchd 6.6.0.4656 package with unattended_install as True.
In the longer term, you (and the community) should experiment with just importing the Munki tools package as-is, without decomposing it into component packages, and marking it with unattended_install as True. The intention is that this should just work.