Munkit 6.0.1 shows Ventura updates on up2date Monterey device

[L B (TheWrongGuy)]

Dear all,

I wanted to report something which is a little unintuitiv.

I have the option InstallAppleSoftwareUpdates enabled in the MSC preferences file.

This worked fine until now. Now it also shows e.g. Ventura 13.1 in the MSC Update

window on a Monterey device. Before, even with a new major release being released,

it showed only the latest minor update for the current major version. So on Monterey

12.5 it should show 12.6.2. At the moment in this case it shows Monterey 12.6.2 AND

Ventura 13.1 update. See the picture attached. This is what it looks like on a 12.6.2

up to date Monterey device. It still shows the Ventura Update. Is it possible to hide the

major upgrades with a preference I'm not aware of?

To just skip the Ventura Update would also trigger aggressiveUpdateNotification I assume. I don't want to force my users to upgrade Ventura right now. Do I have to disable InstallAppleSoftwareUpdates all together?

Best,
LB

[James Cody]

I had the  sameVentura update show up in Munki even though my software update in system preferences doesn’t show it. So far, even though my users try to do it from Munki, it won’t go because the OS doesn’t see the update. 

I am at least seeing the same thing. 

Jim

---------------------------------------------------
Jim Cody
NBCPS Technology Coordinator
jc...@nbtigers.org

North Bend Central Public Schools
1320 Walnut St.
P.O. Box 160
North Bend, NE  68649

Phone: (402)652-3268
Fax: (402)652-8348

On Dec 22, 2022, at 3:38 AM, L B (TheWrongGuy) <darkfa...@gmail.com> wrote:

ture at

This is a staff email account managed by the North Bend Central Public School District. The contents of this email are governed by the laws of the State of Nebraska and the board policies of the school district.

For abuse, misuse, or objectionable content concerns, please contact prob...@nbtigers.org

[Gregory Neagle]

Munki merely displays any updates that are in the output of `softwareupdate -l`. Apart from being able to tell if an update requires a restart or not, Munki doesn’t really have any conception of what the updates are/what they do.

It seems to be a new (mis-)feature that on (at least) macOS 12.3 and up, `softwareupdate -l` may list an available Ventura upgrade (possibly alongside available Monterey updates as well).

Like any other software update that requires a restart, Munki will not actually attempt to install this; Managed Software Center will merely open the Software Update preferences pane, where the end-user can then install the updates/upgrades (or not).

There is no _Munki_ preference to suppress these major OS upgrades since Munki has no idea what a major OS upgrade coming from `softeareupdate` _is_.

Apple supports deferring the availability of major OS upgrades for up to 90 days via MDM profile. In my experience, this works sometimes.

With the tools we have available from Apple, you’ll have to figure out what the best approach is for your org on your own, I’m afraid. There is no ideal solution here that actually works reliably, whether your goal is to encourage/enforce upgrades, or to discourage/prevent upgrades.

-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/3cc3a1dd-d9d6-4d57-8f88-28fb7f1149d2n%40googlegroups.com.
<MicrosoftTeams-image.png>

[L B (TheWrongGuy)]

Happy new year!

Thanks for the explanation. Yes the "issue" seems to be that macOS lists major updates in software -l now, which they didn't before. Damn...

I liked the current solution. Only minor updates would appear, now we push users to update to Ventura, what we don't want at the moment.

Of course this is our problem. We will try to find a solution.

Without being a developer by anymeans and without checking the sourcecode a quick idea:

The part where managedsoftwareupdate is "fetching" the information from softwareupdate -l, munki maybe could

search and exclude all updates not matching the major version e.g. "13" and only show updates containing the major

release number of the currently installed munki. This option could be controlled via OnlyShowAppleSoftwareupdatesForCurrentMajorRelease

or something in ManagedInstalls.plist. Maybe I will give it a try with my limited python skills. But if anybody with the skills, the

time and the mood has an idea, I would be really happy. :)

[Gregory Neagle]

Munki 6.1 (currently in beta) has a new feature to address this issue.

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/d518f2a2-6b53-47c2-b751-d4419377c59fn%40googlegroups.com.

[L B (TheWrongGuy)]

This so awesome! Thanks for adressing this! :)

[L B (TheWrongGuy)]

Hello Gregory,

I wanted to report some feedback on this feature. So in most cases this works perfectly fine and changing the value instantly shows the major upgrades or not.

But in some cases I saw now that the major upgrade  is shown in MSC always. With default settings, with the MajorUpgrade flag set to false it always shows the

Ventura Upgrade. Disabling installing of MacOS Updates lets all updates disappear.

The only difference to the other devices where it works I'm aware of is, that on the devices where Ventura always shows the user tried to install the upgrade, which

then was blocked by JAMF. So they have the pkgidentifier "com.apple.pkg.InstallAssistant.macOSVentura" (which I can't forget by the way) and maybe the installer

in "/Applications". However I tried to reproduce this on another device and tried to install Ventura until it gets blocked and there the Ventura update is not always shown in MSC.

I also wiped the following files and folders on the affected devices in hopes of clearing some cache or something, which didn't work:

/Library/Managed Installs/AppleUpdateHistory.plist

*/AppleUpdates.plist

*/swupd/content & mirror

Do you have any idea what could cause this? Both devices are running Version 6.2 of Munki. Thanks for all the great work and support.

[Greg Neagle]

I’d want to see the output of `sudo managedsoftwareupdate —show-config` and a portion of `sudo managedsoftwareupdate -vvv` showing the Apple softwareupdate part.

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/e309b82a-e118-4587-9fb0-48c6153207a8n%40googlegroups.com.

[Gregory Neagle]

Actually it turns out that `sudo managedsoftwareupdate —show-config` won’t show the value of AppleSoftwareUpdatesIncludeMajorOSUpdates.

So I’d like to see the output of 

munki-python -c "from CoreFoundation import CFPreferencesCopyAppValue ; print(CFPreferencesCopyAppValue('AppleSoftwareUpdatesIncludeMajorOSUpdates', 'ManagedInstalls'))”

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/12F21ABC-CBB0-4B4F-B890-B63F9E62089A%40mac.com.

[L B (TheWrongGuy)]

Hi Gregory,

the on-liner didn't work so I just put this in a simple script test.py:

from CoreFoundation import CFPreferencesCopyAppValue
print(CFPreferencesCopyAppValue('AppleSoftwareUpdatesIncludeMajorOSUpdates', 'ManagedInstalls'))

And then "munki-python test.py
None"

So "None" on a device where I never set this, and it should default to excluding the major upgrade and

on the other:

munki-python test.py
False

"False" where I set the value. Both show pretty much the same when doing sudo managedsoftwareupdate:

sudo /usr/local/munki/managedsoftwareupdate
Managed Software Update Tool
Copyright 2010-2022 The Munki Project
https://github.com/munki/munki

Starting...
    Performing preflight tasks...
Checking for available updates...
    Preventing idle sleep
    Start apple update check
    enabled
    Allowing idle sleep
Checking Apple Software Update catalog...
    0..20..40..60..80..100
    Skipping full Apple Software Update check because sucatalog is unchanged, installed Apple packages are unchanged and we recently did a full check.
Checking for available Apple Software Updates...
   
    The following Apple Software Updates are available to install:
        + Safari-16.3
           *Must be manually installed
        + macOS Monterey 12.6.3-12.6.3
           *Restart required
           *Must be manually installed
        + macOS Ventura 13.2.1-13.2.1
           *Restart required
           *Must be manually installed

Run managedsoftwareupdate --installonly to install the downloaded updates.
Finishing...
    Performing postflight tasks...
Done.

Here is a portion of the apple softwareupdate part of managedsoftwareupdate -vvv attached.

[Greg Neagle]

For a test machine here, here is the relevant output from sudo managedsoftwareupdate -vvv —-applesuspkgsonly:

    softwareupdate cmd: ['/usr/local/munki/ptyexec', '/usr/sbin/softwareupdate', '--verbose', '-l', '--include-config-data']

    softwareupdate run results: {'installed': [], 'download': [], 'failures': [], 'updates': [{'Label': 'XProtectPlistConfigData_10_15-2166', 'identifier': 'XProtectPlistConfigData_10_15', 'version': '2166', 'Title': 'XProtectPlistConfigData', 'Version': '2166', 'Size': '953KiB', 'Recommended': 'YES'}, {'Label': 'XProtectPayloads_10_15-89', 'identifier': 'XProtectPayloads_10_15', 'version': '89', 'Title': 'XProtectPayloads', 'Version': '89', 'Size': '10666KiB', 'Recommended': 'YES'}, {'Label': 'macOS Ventura 13.2.1-22D68', 'identifier': 'macOS Ventura 13.2.1', 'version': '22D68', 'Title': 'macOS Ventura 13.2.1', 'Version': '13.2.1', 'Size': '3950046K', 'Recommended': 'YES', 'Action': 'restart'}], 'exit_code': 0, 'post_action': 0}

    Filtering out macOS Ventura 13.2.1-22D68-13.2.1 from available Apple updates

I see that the label is "macOS Ventura 13.2.1-22D68”.

If we look at the code here: https://github.com/munki/munki/blob/main/code/client/munkilib/appleupdates/au.py#L138-L158

we can see it’s attempting to filter out labels that start with “macOS ”.

In your attachment, we can see an unexpected label, for the Ventura update:

Checking for available Apple Software Updates...

    softwareupdate cmd: ['/usr/local/munki/ptyexec', '/usr/sbin/softwareupdate', '--verbose', '-l', '--include-config-data']

    softwareupdate run results: {'installed': [], 'download': [], 'failures': [], 'updates': [{'Label': 'XProtectPlistConfigData_10_15-2166', 'identifier': 'XProtectPlistConfigData_10_15', 'version': '2166', 'Title': 'XProtectPlistConfigData', 'Version': '2166', 'Size': '953KiB', 'Recommended': 'YES'}, {'Label': 'Safari16.3MontereyAuto-16.3', 'identifier': 'Safari16.3MontereyAuto', 'version': '16.3', 'Title': 'Safari', 'Version': '16.3', 'Size': '130905KiB', 'Recommended': 'YES'}, {'Label': 'macOS Monterey 12.6.3-21G419', 'identifier': 'macOS Monterey 12.6.3', 'version': '21G419', 'Title': 'macOS Monterey 12.6.3', 'Version': '12.6.3', 'Size': '1354164K', 'Recommended': 'YES', 'Action': 'restart'}, {'Label': 'macOS\xa0Ventura\xa013.2.1-22D68', 'identifier': 'macOS\xa0Ventura\xa013.2.1', 'version': '22D68', 'Title': 'macOS\xa0Ventura\xa013.2.1', 'Version': '13.2.1', 'Size': '5652860K', 'Recommended': 'YES', 'Action': 'restart'}], 'exit_code': 0, 'post_action': 0}

Specifically: 'macOS\xa0Ventura\xa013.2.1-22D68’

The current code in Munki would not match on that label, since it does not start with “macOS “. I’m not yet certain how to best handle this (or what triggers this). I’m presuming that `\xa0` is a representation of some alternate Unicode space.

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/d6f626b9-eb78-4ca5-839f-939f1c93f24an%40googlegroups.com.
<munki_applesoftwareupdates.txt>

[Gregory Neagle]

After some experimentation, it appears that ‘\xa0’ is a Python representation of a non-breaking space. Why Apple is sometimes using that in a label and sometimes a “normal” space is a mystery. Note that in your attachment, the Monterey update does not have non-breaking spaces in its label:

'Label': 'macOS Monterey 12.6.3-21G419'

In any case, I have an idea how to handle this for a future Munki release.

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/225DBF75-4B53-41B7-92FA-49FD6A7D22EB%40mac.com.

[Greg Neagle]

Fix is in the Munki6dev branch here, and will be in a future Munki release:

https://github.com/munki/munki/commit/1db146ffaad0a888f1d85b0c18c7b33af058af5e

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/93AA3EBD-B669-4B3F-ABCF-F3CB3AEFC56C%40mac.com.

[L B (TheWrongGuy)]

Thank you so much for the detailed explanation and the fix. That's just awesome!