Closed erikng closed 6 months ago
There is a MunkiReport module, supported_os
that maintains a similar database:
https://github.com/munkireport/supported_os/blob/master/supported_os_data.yml
Nudge would only need to worry about "major" OS versions, so we'd only need to update the list once a year if it was hardcoded in the app.
If Nudge could just assume that an upgrade was supported for a Model not on the list then in theory the list would only need to be changed after WWDC when the list of supported models for the fall's release are announced. (And not anytime Apple shipped new hardware.)
You could probably use the same regex as this extension https://github.com/MLBZ521/MacAdmin/blob/master/Jamf%20Pro/Extension%20Attributes/Get-LatestOSSupported.sh
That provides a good list of all the models not supported by a given OS, with the assumption being that if they aren't in that they are supported. This EA was just updated for macOS 14, so the regex should be up to date.
This is one of the things stopping me from deploying Nudge. Our lifecycle is such that we'll run machines until Apple no longer supports the OS. We still have Monterey and Big Sur machines in service that can't go further. I can't seem to figure out a way, even using different profiles, to deploy Nudge with different requiredMinimumOSVersion so we stop at the last supported OS version. Our MDM doesn't have the ability to filter based on model name, unfortunately.
I may look into conditions using Munki to deploy different JSON files since it does support models, but I much prefer configuration profiles.
It'd be nice if a future Nudge had something that knew the EOL mac models and their max supported OS built in.
For much more modern macOS releases and hardware, parsing the output of ioreg -a -r -c IOPlatformExpertDevice -d 1
(or API equivalent if possible) for the value of target-sub-type
and then comparing that with the hardware ID's that Apple includes in their gdmf
API object could work (especially as new Mac hardware no longer has a MacBookProX,Y
or MacminiX,Y
style model identifier).
I've been contemplating that perhaps a process where in the configuration file that Nudge uses, if there is an optional array (for example, supportedDevices
within the osVersionRequirements
object, that could be filled with the various supported devices scraped from the gdmf
API, and then Nudge checks for this and offers up updates (or not) based on whether the device exists in that supportedDevices
array.
In circumstances where supportedDevices
is not included, then the default behaviour would be to proceed with processing the Nudge configuration as it normally would.
This is really only viable for macOS releases within the last couple of years and Apple Silicon.
ioreg
output without the -a
flag for XML:
ioreg -r -c IOPlatformExpertDevice -d 1
+-o J316cAP <class IOPlatformExpertDevice, id 0x100000274, registered, matched, active, busy 0 (8538 ms), retain 41>
{
"IOPolledInterface" = "AppleARMWatchdogTimerHibernateHandler is not serializable"
"#address-cells" = <02000000>
"AAPL,phandle" = <01000000>
"serial-number" = <<redacted>>
"IOBusyInterest" = "IOCommand is not serializable"
"target-type" = <"J316c">
"platform-name" = <<redacted>>
"name" = <"device-tree">
"secure-root-prefix" = <"md">
"region-info" = <<redacted>>
"manufacturer" = <"Apple Inc.">
"target-sub-type" = <"J316cAP"> # this is the info found within the GDMF API endpoint Apple has
"compatible" = <"J316cAP","MacBookPro18,2","AppleARM">
"config-number" = <<redacted>>
"IOPlatformSerialNumber" = "<redacted>"
"regulatory-model-number" = <<redacted>>
"time-stamp" = <"Tue Nov 14 20:37:00 PST 2023">
"clock-frequency" = <00366e01>
"model" = <"MacBookPro18,2">
"mlb-serial-number" = <<redacted>>
"model-number" = <<redacted>>
"device-tree-tag" = <"EmbeddedDeviceTrees-8408.61.1">
"IOConsoleSecurityInterest" = "IOCommand is not serializable"
"IONWInterrupts" = "IONWInterrupts"
"model-config" = <"Sunway;MoPED=<redacted>">
"device_type" = <"bootrom">
"#size-cells" = <02000000>
"IOPlatformUUID" = "<redacted>"
}
Perhaps Nudge could show a window for machines where they are not capable of running the OS version requested by the system administrator.
We would need to have hardcoded lists for each OS of board IDs and/or model names.