"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]

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

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?

That’s not a crazy idea, but what if it never becomes something other than blank or http://munki? IOW, how long should it wait?

--
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/CAE%2BBptywAsXyAjb6iHYmM0gPNfY6ddc0xDEt8JDOOh286U8c3A%40mail.gmail.com.

[a...@nightingale.org]

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

[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

-- 
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.

[Alan]

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

That’s not a crazy idea, but what if it never becomes something other than blank or http://munki? IOW, how long should it wait?

I guess there's actually a bit of a chicken-and-egg situation here possibly. The AutoRunOnInitialInstall pref would be set either by script or config profile... presumably by whatever Munki itself would be waiting for... but Munki wouldn't know to even wait for SoftwareRepoURL unless AutoRunOnInitialInstall was already a set pref.

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/696ED6BF-88BF-44B7-9C81-CF7647A4F50B%40mac.com.

[Gregory Neagle]

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

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

That’s not a crazy idea, but what if it never becomes something other than blank or http://munki? IOW, how long should it wait?

I guess there's actually a bit of a chicken-and-egg situation here possibly. The AutoRunOnInitialInstall pref would be set either by script or config profile... presumably by whatever Munki itself would be waiting for... but Munki wouldn't know to even wait for SoftwareRepoURL unless AutoRunOnInitialInstall was already a set pref.

Well if it figured out this was a new/initial install it could _always_ wait, but obviously you don’t wait to wait too long...

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/CAE%2BBptxGS_TKQOm%2Bd-jBRVc1oWB68C1qEH5cp5wUJtfe50dq7A%40mail.gmail.com.

[a...@nightingale.org]

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.

Agreed that my 

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?

-Andrew Vo

[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

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.

[a...@nightingale.org]

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

[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

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

[Rob Renstrom]

For the question of how long to wait for the managed configuration to appear (from an MDM delivered configuration profile or otherwise) before the auto run is attempted, it could wait until another managedsoftwareupdate run starts (either a manual run or the background run that normally occurs later with the default Munki behavior). 

The autorun component package could make a launchd job that waits and watches the AutoRunOnInitialInstall key. If the key is enabled, it will do the auto run. If the key remains false (the default if not defined), it would stop waiting once another run is detected, bailing on this initial install auto run, since either the admin didn't configure AutoRunOnInitialInstall or the MDM config profile wasn't delivered in time. It would also exit if this isn't an initial install, perhpas by checking if LastCheckDate is set, to detect if an existing Munki install has already ran.

[Nixtar]

Adding my 2 cents:

This kind of functionality is something we have been investigating recently.

We are using Intune as our MDM and with its new await config settings it always ( in our testing at least ) installs profiles first before starting app installs during enrolment.

To take this to the next level it would be nice if MunkiStatus could run over setup assistant or the login window when it detects its running in this Smart Bootstrapping mode.

This is something I've looked at already, having a script that's packaged as a PKG that runs during await config that waits for both munki and the munki config to be installed then invokes munki.

In my PoC MunkiStatus works during setup assistant but there are guards in the code that prevent MunkiStatus from being topmost and from creating the overlay when its not running at the login window (atLoginWindow()).

We were looking at implementing our own munki bootstrapping mechanism with DEPNotify but as the development of that has stopped we are looking for another solution.

Our requirements are just to make sure Munki is "done" before the user gets a chance to use the device so having Munki run during enrolment and having a bonus of throwing up MunkiStatus to prevent the user from proceeding and to give them something to look at would be awesome.

[Per Olofsson]

I'm late to the party here, but my thoughts:

First of all, great idea! It should make deployment easier for new users, and if you already have a deployment workflow it provides an opportunity to simplify it.

We have our own bootstrap package installed by MDM when enrolling, which includes the munkitools package and scripts for kicking off the initial run. While I wouldn't call the scripts inside fragile, more like battle hardened, there's a lot of complexity inside to ensure that everything works smoothly, and if they fail they do so gracefully and with useful logging. Some of the pitfalls are:

• No guaranteed network access

In certain deployment scenarios the network goes down in the middle of enrollment, depending on your mdm vendor and your network config. Our script waits for internet access and has plenty of retries on every action that touches the network.

• The munki server might not respond

While we try to handle captive portals during the internet access check, sometimes the munki server still isn't reachable so there's an additional check there.

• Config profiles might not be present

I think some mdms still don't reliably deliver profiles before packages are installed. SimpleMDM does, but I still make sure because who knows what happens with macOS.

Personally I wouldn't expect munki to inherit any of this complexity. If you have a network that goes down, or an mdm that doesn't config profiles, or a server that doesn't respond, it's on you the admin to ensure that the preconditions are met before starting the munki install.

An "AutoRunOnInitialInstall" that does what it says on the tin seems like the best approach to me.

--
Per Olofsson, IT-service, University of Gothenburg

--
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/9C161F20-7A4C-4C1B-B483-5227A8EE6AB7%40mac.com.