"Smart" Munki bootstrapping/initial background run

[Gregory Neagle]

I’ve noticed of late that new Munki admins seem to struggle most with the initial Munki run.

It’s a common want to have Munki run as soon as possible after the first boot of a deployed machine so that it can install needed software as soon as possible. A default install of just the Munki tools may not do a background check-and-install for up to two hours after the initial install of the tools.

If we rewind a few years (OK, closer to ten) a very common deployment method was “imaging”: you’d prep a machine for deployment by imaging the startup disk with a pre-prepared disk image. That image could contain the OS, the Munki tools, and a trigger file that caused Munki to enter “bootstrap mode” when the OS boots. So you’d image the machine, and on the first boot, Munki would run in bootstrap mode, checking for updates, downloading software, and installing it, in a loop, until it has nothing to do. Once it was done, the machine would be at the login window, ready for a user to login (perhaps with an AD or LDAP account).

Even after imaging became less useful, people could use tools like Bootstrappr to “inject” the Munki tools and the bootstrap trigger file onto the startup disk of a machine. So again, on the first boot, Munki would run in bootstrap mode.

But now the most common deployment workflow is to use MDM together with DEP/ADE. In this workflow, your MDM server installs the Munkitools during Automatic Device Enrollment. For whatever reason, it’s only been possible to reliably install one single package during ADE, making it difficult to install the Munki tools and a second package that triggers bootstrap (or a background run). So there are flags to the Munki package build scripts that can inject component packages that trigger either bootstrap mode or an immediate background run.

(You’d probably want bootstrap mode if no user is created during ADE enrollment; if a user account is created, since the Mac then never stops at the login window, but instead goes directly to the new user’s desktop, in that situation you’d want to just trigger an immediate background run.)

But making use of these options means building the Munki tools and package yourself, and signing it all properly. This is difficult for many Mac admins, and tedious in any case. Most admins would rather use a pre-built (and pre-signed!) package, like the ones offered at https://github.com/macadmins/munki-builds  The packages offered there are for general usage, including for upgrades of existing Munki installs, and therefore do not contain any of the extra bootstrapping/background run components.

So it’s a struggle. Mac admins need to either build the tools themselves with the correct options, or figure out some other way that works with their deployment tools to trigger a bootstrapping/background run soon after the Munki tools are installed.

I want to make this easier.

My goal: a single “style” of Munki tools package that (subject to control of the admin) will do a bootstrap run/background run without having to install anything else.

The idea I have is a new ManagedInstalls preference that could be in an MDM profile. Something like “AutoRunOnInitialInstall”.

A preinstall script might determine if there is an existing Munki install: if not, we check for that preference. If set, we can set bootstrap mode, or we can set up an automatic background run.

This all seems doable and not terribly hard. But I’d be interested in other people’s thoughts!

-Greg

[Gregory Neagle]

Some discussion of this idea is happening in the #munki channel of MacAdmins Slack. (Not linkable for non-members)

One big reservation: not all MDMs ensure all configuration profiles are installed before packages are installed. (Mine seems to.)

If that’s your case, there are other problems, because you don’t want to auto-run Munki until its configuration is in place. 

While I can imagine alternative mechanisms to trigger bootstrap mode or an auto-background run on initial install, if the Munki client does not yet have a valid SoftwareRepoURL (and the default repo detection described here (https://github.com/munki/munki/wiki/Default-Repo-Detection) isn’t applicable fo you), you’d need some way to either wait for the managed configuration to appear, or a way to re-trigger things _after_ the managed configuration appears. Ideas?

-Greg

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/9C161F20-7A4C-4C1B-B483-5227A8EE6AB7%40mac.com.

[Alan]

Just spitballing here, but could it be part of the AutoRunOnInitialInstall to wait until the SoftwareRepoURL becomes something other than blank or http://munki ? That way you know either some script used defaults write or some MDM config profile landed?

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/EAE2ECBA-1EE5-4740-A5B9-CB3C4846847E%40mac.com.

[Gregory Neagle]

I’m glad you’ve solved this for yourself, but you have to agree this sounds fairly complex and intimidating. My proposal is to make it easier, especially for new Munki admins.

-Greg

On May 14, 2024, at 2:58 PM, a...@nightingale.org <a...@nightingale.org> wrote:

I create a package bundled with a signed munkitools package, a package with a munki_config postinstall script, and a custom DEPNotify package. I then upload it into my MDM (Airwatch) and set it as a bootstrap package.

The munki_config postinstall script installs an aws s3 middleware and configures the managedinstalls.plist with the s3 bucket information. I also unload the LaunchD for managedsoftwareupdate-check.plist and create a checkandinstallatstartup file used in the original bootstrapping (not sure if this is really necessary but I ran into issues not having this file created). 

In my custom DEPNotify package, I have a configuration script that will wait for Managed Software Center.app to exist before running and at some point down the scripts I have it checking to see if there is there is a managedsoftwareupdate process running, and if not, it will set up the run to the script to set managedsoftwareupdate to -auto. Once all the software has been installed, the DEPNotify script will remove the checkinstallatstartup file and restart the device. 

I'm not sure if all this makes sense to you, but this is how I have been able to successfully get Munki to run automatically along with DEPNotify. I'm still fairly new to all this so this may not be the best way to do things. I'm linking my public scripts so you can see what I'm working with.

https://github.com/Pherall/Munki-Config-Script/blob/main/Munki_Configuration-PostInstall.sh

https://github.com/Pherall/DEPNotify-Scripts/blob/main/DEPNotify/depinstall

-- 
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/abda9706-dd75-436d-9d9b-25457b3c2dcen%40googlegroups.com.

[Gregory Neagle]

On May 14, 2024, at 3:23 PM, a...@nightingale.org <a...@nightingale.org> wrote:

Agreed that this is very complex and took me a while to figure out. I'm still trying to wrap my brain around on how everything fully works.

Similar to how you have checkinstallatstartup for bootstrapping before, can you do the same with AutoRunOnInitialInstall and have munki set into that mode if that file exists? Or is this still too complicated?

Sure, but that doesn’t actually address the problem. The problem is “how do we have a single signed and notarized package that, under admin control, can either enter bootstrap mode or do a background run without requiring the install of any other package?”

During DEP/ADE, MDM can install configuration profiles, and a _single_ package.

-Greg

-Andrew Vo

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/d31f2a92-6c7b-4726-b7f2-6a26d91b303en%40googlegroups.com.

[Alan]

It’s a common want to have Munki run as soon as possible after the first boot of a deployed machine so that it can install needed software as soon as possible.

I guess something else to consider in implementation here is—are there a lot of scenarios in which a Munki admin would want to deploy Munki on a fresh Mac... and then not want Munki to run afterwards (as long as the config profile or other prefs are set)? In other words, should this be the default behavior, assuming Munki hasn't run before on that particular macOS installation?

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/37391ACB-E0C1-49A4-A08D-697CAE0FEA08%40mac.com.

[Gregory Neagle]

On May 14, 2024, at 3:48 PM, Alan <alan...@gmail.com> wrote:

It’s a common want to have Munki run as soon as possible after the first boot of a deployed machine so that it can install needed software as soon as possible.

I guess something else to consider in implementation here is—are there a lot of scenarios in which a Munki admin would want to deploy Munki on a fresh Mac... and then not want Munki to run afterwards (as long as the config profile or other prefs are set)? In other words, should this be the default behavior, assuming Munki hasn't run before on that particular macOS installation?

It’s always risky to change the default behavior of something that’s been in use a long time. You don’t know what’s been built that relies on the assumption of current behavior.

Additionally: there are two different ways Munki might run after install.

If no local user is created in the Setup Assistant during DEP/ADE (this is the case here), you probably want Munki to run in bootstrap mode at the loginwindow, with the UI that blocks access to the loginwindow until Munki is done installing everything.

On the other hand, if a local user is created during Setup Assistant, the OS exits from Setup Assistant directly to the desktop of the newly-created user. In this scenario, bootstrap mode is not useful, and instead you probably want Munki to just run a background session to check for and install software.

There’s no way I can think of for the Munki tools package to know which of the two modes is appropriate, so there has to be a mechanism for the admin to tell the Munki tools package what do do.

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/CAE%2BBptwg2j-%2Bhw2%3DN384TJWKZXzLtxGXjKNyqsXw81Z-ftUuQw%40mail.gmail.com.

[Gregory Neagle]

If people have access to things like Freestyle Orchestra then they can develop their own solutions to this problem.

Again: I’m looking to make this easier for a new Munki admin, and I can’t control what MDM they might be using or what additional features it might provide past the installation of configuration profiles and _one_ initial package.

-Greg

On May 14, 2024, at 3:52 PM, a...@nightingale.org <a...@nightingale.org> wrote:

Do other MDMs have Workflow deployments similar to Airwatch's Freestyle Orchestra? I have not fully tested this out myself yet with Munki, but it might be possible to create a condition for "A preinstall script to determine if there is an existing Munki install: if not, we check for that preference. If set, we can set bootstrap mode, or we can set up an automatic background run."

-Andrew Vo

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/24b2f13a-f9b1-4d59-917b-c34f52a981f7n%40googlegroups.com.