munki / munki

Managed software installation for macOS —

Home Page:https://www.munki.org/munki/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

catalogs data not being collected in ManagedInstallsInfo after 6.5.1.4661 update

TonyPaco opened this issue · comments

After updating to v6.5.1.4661, catalogs data is no longer being collected in ManagedInstallsInfo.plist (and thus doesn't trickle over to Munki Report.)

Attached is a screenshot of a BBEdit comparison of "/Library/Managed Installs/ManagedInstallReport.plist" on a 6.5.0 client and then on a 6.5.1 client.

ManagedInstallsInfo_comparison

If this change is by design, my apologies for pointing out the obvious, and I'd appreciate any help in crafting my own condition to return this functionality (it's one of the few things I harp upon my users to check in MR.)

Please and thank you.

This change isn't really by design, but a side-effect of another change.
The catalogs list recorded before 6.5.1 wasn't necessarily the list of all catalogs ever considered, but rather the catalog list for the last manifest that was processed (there may be multiple manifests due to included_manifests). I could restore the previous behavior, but I think it's actually misleading. I'll have to think about how this should be handled.

I'll note that https://github.com/munki/munki/wiki/Conditional-Items says:

| catalogs | array of strings | This contains the current catalog list for the manifest being processed. |

Note the "manifest being processed". This means this list can change during the Munki run as different manifests are processed. (It's good practice to have only the primary manifest contain a catalog list, but this is not always followed.)

Understood.

I actually went through my manifests looking to see if I inadvertently double dipped and that caused the error/omission with Munki Facts: we aim to only have catalogs in the "machine" manifest and keep all other manifests to be included free of catalog designations.

I thank you kindly for your response, insight, and explanation.

I think I have fix here that is more useful/consistent than the original implementation: 6c4a8bc

The catalogs list that is reported is for the primary manifest.

Working perfectly on the handful of clients I've tested. Thanks!

Thank you for testing and reporting your results!

Also, in order to satisfy my own curiosity, tested on and confirmed it also works on clients that only reference the site_default manifest.