In the Super.log in the Status, it would be really helpful to put a Status : Super Version x.xbx

It would be helpful to know the current version of Super that is running. With all the great beta releases, its hard to keep track in the logs on what version did what.

When checking the logs , something is not working prop..

Super starts, it reading the proper prefs, it finds the update, its validating the bootstrap.
It sometimes start to download the actual updater, buts it always stalls on:
Error code: Unable to reach Apple Software Update server, trying again in xxx seconds.

Details:
MacBook Pro 14" - macOS 13.0.1 (22A400) Same issues with a macbook air 2018 on macos 12.1
Superman v3.0-b4 (attached used config profile)

There are no other software updates deferal profiles or restrictions.

Tested on different geo locations
Tested on different MacBooks
Tested on different macOS versions

Latest super version 2.0 was working great!

Jamf Pro kicks-off the run command for super once a day per computer with the following command:
/Library/Management/super/super --jamf-account=apiuser --jamf-password=securepasswd

I just noticed what happens when an error occurs, in that super uses the DefaultDefer setting to check again later. Problem is, there is no feedback to the user when that happens if super was manually started.

What I would like to see is the option to set a much shorter automated defer on errors such as "Error: Download of system update/upgrade via MDM push command timed out after 300 seconds, trying again in 86400 seconds", and something to identify when such an error has occurred from a manual (i.e. jamf self service start) to report to the user an error occurred and that it will try again automatically after the error timeout.

With this is mind, I'm thinking settings like:

--ErrorDefer=<secondcount>
--ErrorCount=<max number of retries separated by ErrorDefer>
--NotifyErrorOn (and matching super's settings style:) --NotifyErrorOff

The first two can be Config Profile options as well, while the 3rd should be command line only. NotifyError can be stored and automatically removed either upon successful update or ErrorCount exceeded along with a final notification. These should only apply to actual errors, such as the timeout example above.

In Secure environments, access to GitHub could be blocked (as it is in my secure space).

The request is to allow Erase-install.pkg, MovablePython3 ,IBM Notify, etc to be installed via policy and pulled from our available Jamf Repositories.

Very minor one, In the message 'The deferrment deadline of xxxxx has passed'. Deferrment should be spelt with 1 r, so 'deferment'

and something so minor I am embarrassed to mention it. Is it possible not to have the full stops after each text line, I don't think they are required. If not it is not a problem.

For the 'This computer will automatically restart very soon' is it possible to have a countdown timer displayed. I see that a countdown timer is possible, as you have one in the deferral message 'Please make a selection in 00:00:54'
It just means the person knows exactly when the host will reboot as 'restart very soon' can be interpreted differently by different people.

Many thanks and love the product by the way

Since super installs itself, is it plausible to add the ability to uninstall itself?

I've got everything working as I'd like using command line configuration options, but when I convert them to a Configuration Profile and put it in jamf, deferring thorough the notification menu is failing in a weird way. It adds 2 hours to whatever is selected by the client to defer. Specifically, I've tested 5 and 15 minutes out of the selection with the menu set to <key>MenuDefer</key><string>300,900,3600,7200,14400,28800</string>. I'm attaching a log as well - super.log - with the notable events starting at Tue Nov 08 11:05:41. Attached is the profile file as well. super.plist.txt

Hello, thank you for your script!
I would like to change the icon with the --display-icon "/local/path or URL" option but I can't get the desired result. In the log file, I have each time "Unable to locate specified icon from". For the tests I have the image on my desktop, I entered -display-icon " /User/Myname/Desktop/Logo.png.
Do I need the format of the icns image?
Did I enter it correctly?

I would love to see Super support an unattended mode and/or maintenance windows. Unattended mode would ensure Super only installs/reboots when no one is logged into the machine. Maintenance Windows only allow Super to install/restart during specific time frames. The original use case for this were computer labs and/or Libraries where the machines could be accessed at any point during the day but we don't want to disrupt the experience of the user at all if possible; there are large parts of the day where the machine is unattended however. Deferrals do not work in this instance as it will be a different user each time and would just add confusion.

Thanks!

Currently Super doesn't prompt for charger, perhaps we could use the code from erase-install here?

`check_power_status() {
# Check if device is on battery or AC power
# If not, and our power_wait_timer is above 1, allow user to connect to power for specified time period
# Acknowledgements: https://github.com/kc9wwh/macOSUpgrade/blob/master/macOSUpgrade.sh

# default power_wait_timer to 60 seconds
[[ ! $power_wait_timer ]] && power_wait_timer=60

power_wait_timer_friendly=$( printf '%02dh:%02dm:%02ds\n' $((power_wait_timer/3600)) $((power_wait_timer%3600/60)) $((power_wait_timer%60)) )

if /usr/bin/pmset -g ps | /usr/bin/grep "AC Power" > /dev/null ; then
    echo "   [check_power_status] OK - AC power detected"
else
    echo "   [check_power_status] WARNING - No AC power detected"
    if [[ "$power_wait_timer" -gt 0 ]]; then
        if [[ -f "$jamfHelper" ]]; then
            # use jamfHelper if possible
            "$jamfHelper" -windowType "utility" -title "${!dialog_power_title}" -description "${!dialog_power_desc} ${power_wait_timer_friendly}" -alignDescription "left" -icon "$dialog_confirmation_icon" &
            wait_for_power "jamfHelper"
        else
            # open_osascript_dialog syntax: title, message, button1, icon
            open_osascript_dialog "${!dialog_power_desc}  ${power_wait_timer_friendly}" "" "OK" stop &
            wait_for_power "osascript"
        fi
    else
        echo "   [check_power_status] ERROR - No AC power detected after ${power_wait_timer_friendly}, cannot continue."
        exit 1
    fi
fi

}`

This has been mentioned in Slack, just adding here as a request.
Thank you

The 15 minutes part is slightly off center and clicking it does nothing. I must click the down arrow on the side. Not a big deal but end users may be confused by it.

This could be a either a FR or bug depending on things

As the below example isn't a MAJOR update,

Should the majorUpgradeNAMES and majorUpgradeNAME variables be blank or perhaps fill with "No Major version detected" ?

Fri Dec 02 14:24:10 X2102825 super[29857]: Verbose Mode: Function checkAllAvailableSoftware: availableOSUPDATES is: === OS Update Item ===
Product Key: MSU_UPDATE_22C5059b_patch_13.1_minor
Title: macOS Ventura 13.1 Beta 4
Version: 13.1 <Build: 22C5059b> <PMV: 13.1>
Deferred: no (Date: )
Tags: (null)
MacOSUpdate: YES
MSU: YES (Major: no Full: no DL: no label: macOS Ventura 13.1 Beta 4-22C5059b)
Splat: no <(null)> (Revoked: no)
IsMacOSUpdate(): YES
IsMajorOSUpdateViaIA(): no
Available updates (install debug profile for more details): (
{
AllowsInstallLater = 1;
AppIdentifiersToClose = (
);
Build = 22C5059b;
DownloadSize = 1135939717;
HumanReadableName = "macOS Ventura 13.1 Beta 4";
HumanReadableNameLocale = "en-GB";
IsConfigDataUpdate = 0;
IsCritical = 0;
IsFirmwareUpdate = 0;
IsSecurityResponse = 0;
ProductKey = "MSU_UPDATE_22C5059b_patch_13.1_minor";
RequiresBootstrapToken = 1;
RestartRequired = 1;
SupplementalBuildVersion = 22C5059b;
Version = "13.1";
}
)
Fri Dec 02 14:24:10 X2102825 super[29857]: Verbose Mode: Function checkAllAvailableSoftware: majorUpgradeNAMES is:
Fri Dec 02 14:24:10 X2102825 super[29857]: Status: No available major system upgrade. May be deferred via MDM.
Fri Dec 02 14:24:10 X2102825 super[29857]: Verbose Mode: Function checkAllAvailableSoftware: majorUpgradeVERSION is: FALSE
Fri Dec 02 14:24:10 X2102825 super[29857]: Verbose Mode: Function checkAllAvailableSoftware: majorUpgradeNAME is:

It looks like it finished downloading the section of update and then timed out? Not sure if this has been seen elsewhere by others or not?

2022-11-22 18:00:48.240681+0000 0xe395     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.587777 totalWrittenBytes:2509573966 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.316546
2022-11-22 18:00:49.243226+0000 0xe499     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.588819 totalWrittenBytes:2515586894 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.048247
2022-11-22 18:00:50.238802+0000 0xe4a9     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:00:51.240325+0000 0xe499     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:00:52.242284+0000 0xe499     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:00:53.242274+0000 0xe499     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:00:54.242397+0000 0xe499     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:00:55.237481+0000 0xe395     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:00:56.242236+0000 0xe499     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:00:57.242327+0000 0xe395     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:00:58.241780+0000 0xe4a9     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:00:59.242267+0000 0xe499     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:01:00.238597+0000 0xe395     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:01:01.241615+0000 0xe499     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:01:02.241173+0000 0xe395     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:01:03.239979+0000 0xe499     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:01:04.241857+0000 0xe395     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
2022-11-22 18:01:05.238569+0000 0xe4a9     Default     0x0                  11642  0    softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:SU] [SUMacControllerProgressManager] Reported progress (inter): phase:DOWNLOADING_UPDATE stalled:NO portionComplete:0.589000 totalWrittenBytes:2516628239 totalExpectedBytes:2516628239 estimatedTimeRemaining:0.000000
Tue Nov 22 18:01:05 X2029172 super[10745]: **** S.U.P.E.R.M.A.N. MDM PUSH WORKFLOW TIMEOUT FAILURE ****
Tue Nov 22 18:01:05 X2029172 super[10745]: Error: Push workflow for download of system update/upgrade via MDM timed out after 120 seconds, trying again in 120 seconds.

It would be great to have a key that will only offer a defer if there's an update requiring a restart

--defer-restartsonly
Only offers defer if there's an update requiring a restart.

Hi,

I'm currently implementing your solution and wondered if there was any way to delay the start of the notification by a certain number of days automatically

What I mean by that is I would like to have super doing a recheck-defer every day but as soon as it detect a new update it sets the zero day date a week after the updates releases

The Idea would be to leave us enough time to test the update and verify the impact on users before deploying

For now we are doing a simple workaround where we republish a policy running once per users once we release the update to the users

Thanks for the great work on the project

During the update prepare step, the process is killed after 300 seconds preventing it from completing. The log indicates the timeout was for the download step, but that step was already completed.
I tried to re-run the process and had the same result on each of four attempts.
Here are the two lines from the log. I've also attached the complete log files if needed (it will be the most recent run attempt starting Sat Oct 22 10:03:02)

Sat Oct 22 10:18:41 ZG13088 super[35311]: Status: Download complete, now preparing system update/upgrade, should be done in a few minutes... Sat Oct 22 10:25:51 ZG13088 super[35311]: Error: Download of system update/upgrade via MDM push command timed out after 300 seconds, trying again in 3599 seconds.

super.log
update.log
asu.log
mdm.log

/Library/Management/super/super-starter doesnt exist in v2 and so the launch daemon after the deferral does nothing.

Hello just start looking at your solution, looks really good.
I've noticed the in the Jamf MDM commands you did not specify the version.
For example:
jamfJSON='{ "deviceIds": ["'${jamfProID}'"], "skipVersionVerification": false, "applyMajorUpdate": false, "updateAction": "DOWNLOAD_ONLY" }'

The Jamf 10.38.1 API has this schema

{
  "deviceIds": [
    "1",
  ],
  "maxDeferrals": 7,
  "version": "12.0.1",
  "skipVersionVerification": false,
  "applyMajorUpdate": false,
  "updateAction": "DOWNLOAD_AND_INSTALL",
  "forceRestart": false
}

By ignoring the version you are requesting the latest available?
Regards

There are two lines of code in version 3.0b1 producing an error that reference a non-existing function (SendToASU). I believe these should be referencing the function SendToASULog:

Line 2995: sendToASU "Status: Installing Recommended Software Update $((i + 1)): ${recommendedLABLES[i]}..."
Line 3020: sendToASU "Status: Installed Recommended Software Update: $updateRECOMMENDED."

Thank you for making this, love it and have implemented it a couple times.

Would be good to add to the jamf marketplace, then I can send my customers there as well looking for this amazing solution!

1. Support for additional dialog systems, I'm currently using DEPNotify, and I'm looking to replace that with swiftDialog.

2. Option to supply the Jamf Pro device id, saving the need to check the computers UUID and then bothering the server with then looking up the computers device id. I've noticed that the jamf recon command finishes processing with the computers device id (i.e. <computer_id>1330</computer_id>), so I've started capturing that and storing it on the computer for use in working with the Jamf Pro API like this.

Using Jamf Pro here.

Passing paramaters in thescript to deploy super is great, however exposes the API creds in the policy.

And at present, due to another issue (API permission requires Computers > Create/Read) is somewhat of a security hole.

Issue: API - Computers Create and Read Removed - Super doesnt run
#36

Need a variable to customize what server the API request gets pointed to. we have a dedicated api node to offload all the API traffic from our other nodes and would love to point super’s API calls other than using the local config.

There seem to be a lot of security issues with this script, mainly race conditions where temporary files are used e.g.

curl "URL/" -L -o "/tmp/erase-install.pkg"

It'd be better to do something like:

output=$(mktemp) curl "URL/" -L -o "${output}"

Is there a way to make it so the Mac will not need a restart if no update is found?

I came across an issue where the super script failed to connect to my Jamf instance (Status: Jamf Pro service unavailable) and as a result the recheck deferral I have set did not trigger. I believe the expected behavior should be that the script should run again after the designated recheck deferral timeframe even in the event of a failure so the process can try again next time.

Below are log examples of a successful attempt, and the attempt where the Jamf Pro service was unavailable and the recheck deferral did not trigger

Mon Oct 10 09:53:05 ZG81939 super-starter[32829]: **** S.U.P.E.R.M.A.N. LAUNCHDAEMON ****
Mon Oct 10 09:53:06 ZG81939 super[32836]: **** S.U.P.E.R.M.A.N. STARTER ****
Mon Oct 10 09:53:06 ZG81939 super[32836]: Starter: Deleting previous LaunchDaemon com.macjutsu.super.plist.
Mon Oct 10 09:53:06 ZG81939 super[32836]: Status: Current GUI user is andrewsp with a UID of 503.
Mon Oct 10 09:53:08 ZG81939 super[32836]: Starter: Found saved credentials for super service account "super".
Mon Oct 10 09:53:09 ZG81939 super[32836]: Starter: Validated saved credentials for super service account "super".
Mon Oct 10 09:53:09 ZG81939 super[32836]: Starter: Found saved credentials for Jamf Pro API account "_Jamf_SuperAPI".
Mon Oct 10 09:53:12 ZG81939 super[32836]: Starter: Validated saved credentials for Jamf Pro API account "_Jamf_SuperAPI".
Mon Oct 10 09:53:12 ZG81939 super[32836]: Starter: Bootstrap token escrow validated.
Mon Oct 10 09:53:12 ZG81939 super[32836]: **** S.U.P.E.R.M.A.N. STARTER END ****
Mon Oct 10 09:53:12 ZG81939 super[32836]: **** S.U.P.E.R.M.A.N. UPDATE APPLE SILICON ASU SERVICE ACCOUNT ****
Mon Oct 10 09:53:12 ZG81939 super[32836]: Status: Checking available Apple software updates...
Mon Oct 10 09:53:20 ZG81939 super[32836]: Status: Double-checking available Apple software updates...
Mon Oct 10 09:53:42 ZG81939 super[32836]: Status: No Apple software updates available. Some may be deferred via MDM.
Mon Oct 10 09:53:42 ZG81939 super[32836]: Status: Recheck deferral should restart super in 3600 seconds.
Mon Oct 10 09:53:42 ZG81939 super[32836]: Exit: LaunchDaemon com.macjutsu.super.plist is scheduled to start at 10:53 on 10/10.
Mon Oct 10 09:53:43 ZG81939 super[32836]: **** S.U.P.E.R.M.A.N. EXIT ****
Mon Oct 10 10:53:43 ZG81939 super-starter[33362]: **** S.U.P.E.R.M.A.N. LAUNCHDAEMON ****
Mon Oct 10 10:53:43 ZG81939 super[33374]: **** S.U.P.E.R.M.A.N. STARTER ****
Mon Oct 10 10:53:44 ZG81939 super[33374]: Starter: Deleting previous LaunchDaemon com.macjutsu.super.plist.
Mon Oct 10 10:53:44 ZG81939 super[33374]: Status: Current GUI user is andrewsp with a UID of 503.
Mon Oct 10 10:53:46 ZG81939 super[33374]: Starter: Found saved credentials for super service account "super".
Mon Oct 10 10:53:47 ZG81939 super[33374]: Starter: Validated saved credentials for super service account "super".
Mon Oct 10 10:53:47 ZG81939 super[33374]: Starter: Found saved credentials for Jamf Pro API account "_Jamf_SuperAPI".
Mon Oct 10 10:53:48 ZG81939 super[33374]: Status: Jamf Pro service unavailable.
Mon Oct 10 10:53:48 ZG81939 super[33374]: Exit: Unable to connect to Jamf Pro to validate user account.
Mon Oct 10 10:53:48 ZG81939 super[33374]: **** S.U.P.E.R.M.A.N. EXIT ****

It appears that the super and super-starter binary isn't signed and therefore can't make a PPPC setting.

Unless I'm missing something

Thanks again for the work, after disabling the software update notifications was able to test it on VM successfully from 12.3.1 to 12.4.
Now testing on few laptops and the updates download stuck just like before even though Software Update notifications are disabled. by looking at the mac's I see that they downloaded the update even before the Super Script started, so super script checks for the available updates and triggers the download command and then it gets stuck up waiting for the "phase:COMPLETED" but as the updates already downloaded that never happens again.

I wish Apple should have provided some feedback from softwareupdate that tell us the update already downloaded, I am looking for options to identify these cases but no luck yet. Any other options out there ? some one also looking for the same issue https://community.jamf.com/t5/jamf-pro/monitor-software-update-download-status/td-p/263400

I've been running into an issue where super is going through the MDM download process, gets to the point where it's waiting for the download to start, the MDM log show's the MDM download workflow as complete, but the download isn't starting. I've had it try probably 20+ attempts, tried a reboot, also tried version 2.0 but had the same resut
This is running on macOS 13.0 trying to update to 13.1 beta so I'm not sure if that's causing an issue, but wanted to call it out and send over the logs in case there is an issue with softwareupdate on macOS 13 or if you spot something I'm missing

super (1).log
mdm (1).log
update (1).log

Hello,

I'm Robert.

First: The script is amazing. Thanks you very much for that.

Second: I tried it out with MDM workflow. Unfortunately it did not work for me. That's why I read through the whole script and I think I found a small mistake. In line 2517 the script checks the update.log for phase "COMPLETED" but in the log there is phase "COMPLETED". But there is a phase "COMPLETE". I think this is the reason why the script is not working for me.

I changed it in the script and now it works. Can you please update it?

Thanks in advance.

Kind regards,

Robert

Using the API method here.

While the documentation and logging says to remove Create, and Read computer object permission in Jamf Pro, doing so causes super to not run with the following.

Error: Unable to request Blank Push via Jamf Pro API account "INSERT_API_ACCOUNT". Verify this account has has the privileges " Jamf Pro Server Objects > Computers > Create & Read".

Enabling this this resolves the problem however exposes our jamf pro server to risk.

Add the option to run a jamf policy after the update has applied.

Such as or example
--postupdatereboot-runjamfpolicy

Adds into the configuration
<key>RunJamfPolicyAfterUpdateReboot</key>
<true/>

Which runs any policy with the Custom Trigger of "SupermanRunAfterUpdateReboot" after the machine has rebooted. Assuming there are policies set with that custom trigger.

Customers would only need to put policies in with that trigger.

Would love for the dialogs to display the actual updates that are to be installed for the end user.
Case would be, if end user inadvertently received an update/upgrade notification to defer, et. al., they would, in the least, know whats to be updated/upgraded. Safari, Security Update, Major OS Upgrade, etc.

Downloading software updates while on VPN can be very bandwidth demanding on most corporate infrastructure. We currently have in place a VPN check that we added to Super v2 for consideration to be placed as optional in the Main Code

checkVPN() {
local onPPP=$(ifconfig | grep -iv inet6 | grep ppp0 | wc -l | sed 's/ //g')
local onIPSEC=$(ifconfig | grep -iv inet6 | grep utun | grep -i noarp | wc -l | sed 's/ //g')
    if [[ ${onPPP} -gt 0 || ${onIPSEC} -gt 0 ]]; then
		echo " >>> Active VPN connection detected! Should not Install or run SUPER while connected to VPN!... Bail, Bail, Bail..."
    	exit 1
    fi
}

this confirm works with Forticlient and Cisco Anyconnect in our environment with Super v2

I think this is a niche scenario and only limited to companies where their estate shutdowns Macs / Standby and delete FV2 key etc.

I want a way to trigger super to run at key times of the day (say 0900 1200 1500 1800) to ensure it loads itself after a cold start whilst still respecting any User deferment time period.

The only way I can see this working is whereby super checks on initial execution if an existing deferment window is in place and kills itself

Configuration is done via Managed Preferences. The workflow is set to user. The goal is to nudge users into clicking the update in the System Preferences.
Running v3.06b on Monterey 12.6.2, the background process is not downloading the Ventura update. When agreeing to update, the second super window is trying to open the none existing installer instead of opening the System Preferences.

Let me know if I can do anything to debug this further.

HI really nice concept to do this update and also recommending to add the upgread option to do that migrating to new version of OS.

im having the issue with this script
i tried as you given by jamf configuration
where im getting struck with downloading the IBM notifier & where i manully tried open the link its perfect download the IBM notifier

find the error snap and log pls fix that why its happen.

MDM account still in keychain after running shell script to remove super.

It is working great for the most part! But I had a user come to me with an issue where they did not get a deferral option. It gave them the "you have deferred the maximum number of 5 times. A required software updated will automatically restart this computer in about 5 minutes." Which unfortunately came at an inopportune time. I have included the log with the notable events starting at 14:57 :mysuper.log

and the deferment plist:

JamfProID
$JSSID
MenuDefer
300,1800,3600,7200
FocusCount
5
HardCount
5
FocusDays
2
DisplayRedraw
10800
DisplayIcon
/private/var/tmp/icon_for_superman/icon.icns
IconSizeIbm
128
IconSizeJamf
128
ForceRestart

We know that Apple is moving to a smaller upgrade solution but we may still have the cases of lack of hard drive space to do the job.
I know via Jamf Pro we could run some pre-checks and warn end users to clean up before pushing SUPER out, but still the script is local and could handle the check there and then.

Thanks for your work on this project. Very excited to get it implemented in our K-12 district.

One additional deferral feature that would be really nice to have is the ability to set a time based deferral window starting with the availability of updates on a computer. IE, instead of a count or fixed-date deferral window, something like "updates must be accepted/installed within X days of being discovered by super".

Thanks again!

Need to have an ability to uninstall all components of SUPER in case it is no longer needed.

In our environment we tunnel all connectivity through a VPN. The machines will pass the check that a connection is valid as the wifi is enabled and active , however there can be the instance where the VPN has not established and therefore we have no connectivity out to apple.

From my testing with super in the above scenario the logs exit with error code 1 with the line "Unable to parse Apple softwareupdate results".

The issue I'm seeing is after this point no launchdaemon is recreated so super never runs again. I had a look at the script and this appears to be happening at line 2240 to 2244 - If you add the function call 'makeLaunchDaemonCalendar' to line 2243 - just before sending S.U.P.E.R.M.A.N EXIT to the logs it resolves the issue

The other thing you could do is have a connectivity check out to apple at the same point you check the network interfaces but I think the above is easier

Hello,
Thank you for the script and work. Any one seen issues with Monterey 123.1 to 12.4 when run via Jamf ? its Intel mac only

I am trying to test and the script with different options and messages on Big Sur (11.6.5) and Monterey 12.3.1, script working as expected on Big Sur but on Monterey Jamf exits and Launch Daemon will start the Super script and Super finding 12.4 update and then running 'softwareupdate --download --all --agree-to-license'

Update.log stuck at these wont move forward to the Download Phase and even if we wait few days

2022-05-20 13:16:30.247635-0400 0x3ae2d Default 0x0 316 0 softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:ScanManager] [Progress] Scan reported progress (start): phase:SOFTWARE_UPDATE stalled:NO portionComplete:0.000000 estimatedTimeRemaining:-1.000000 2022-05-20 13:16:30.480709-0400 0x3b1d1 Default 0x0 316 0 softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:ScanManager] [Progress] Scan reported progress (end): phase:SOFTWARE_UPDATE stalled:NO portionComplete:19.000000 estimatedTimeRemaining:-1.000000 2022-05-20 13:16:30.482147-0400 0x38d09 Default 0x0 316 0 softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:ScanManager] [Progress] Scan reported progress (start): phase:BRIDGE_OS_SOFTWARE_UPDATE stalled:NO portionComplete:50.000000 estimatedTimeRemaining:-1.000000 2022-05-20 13:16:31.939043-0400 0x3ae2d Default 0x0 316 0 softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:ScanManager] [Progress] Scan reported progress (end): phase:BRIDGE_OS_SOFTWARE_UPDATE stalled:NO portionComplete:69.000000 estimatedTimeRemaining:-1.000000 2022-05-20 13:16:31.939942-0400 0x3ae2d Default 0x0 316 0 softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:ScanManager] [Progress] Scan reported progress (start): phase:UPDATE_BRAIN stalled:NO portionComplete:70.000000 estimatedTimeRemaining:-1.000000 2022-05-20 13:16:32.167076-0400 0x3ae30 Default 0x0 316 0 softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:ScanManager] [Progress] Scan reported progress (end): phase:UPDATE_BRAIN stalled:NO portionComplete:79.000000 estimatedTimeRemaining:-1.000000 2022-05-20 13:16:32.168075-0400 0x3ae2d Default 0x0 316 0 softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:ScanManager] [Progress] Scan reported progress (start): phase:MINOR_DOCUMENTATION stalled:NO portionComplete:90.000000 estimatedTimeRemaining:-1.000000 2022-05-20 13:16:32.403863-0400 0x3b1d1 Default 0x0 316 0 softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:ScanManager] [Progress] Scan reported progress (end): phase:MINOR_DOCUMENTATION stalled:NO portionComplete:99.000000 estimatedTimeRemaining:-1.000000 2022-05-20 13:16:32.406838-0400 0x3ae30 Default 0x0 316 0 softwareupdated: (SoftwareUpdateMacController) [com.apple.SoftwareUpdateMacController:ScanManager] [Progress] Scan reported progress (start): phase:COMPLETE stalled:NO portionComplete:100.000000 estimatedTimeRemaining:-1.000000

-->If I trigger the Super from terminal, it then start the update downloads with no issues. I have been testing and trying to pin point the issue. I see that if we run Super script via LaunchDaemon it will not proceed to the download phase no matter if it was run via Jamf or local admin account

For testing I removed 'makeLaunchDaemonRestartNow' logic so Jamf can directly trigger's the update and that works fine, so its the issue with LaunchDaemon.

I have not dig into the Apple logs a lot yet, but nothing glaring from the software update logs.

Although the JAMF API credentials are saved to the keychain anyway, the API credentials are exposed to the client devices when Files and Processes are run with --jamf-account and --jamf-password. when running sudo jamf policy -v

Is it possible to send through a script and using the $4 and $5 variables instead and setting the script to run "after", or will this cause issues?

I was looking at the focus code, and I was wondering if we could allow for managing the kinds of focus, for example, I have 4 focus settings setup and scheduled, so my devices are always in one focus or another, so I'm looking for a way of identifying the difference.

What I'm thinking is identifying the difference between a custom focus, and a standard focus like Do Not Disturb or Sleep, I've discovered from your code that they can be filtered and differentiated:
% plutil -extract data.0.storeAssertionRecords.0.assertionDetails.assertionDetailsModeIdentifier raw -o - "/Users/wakco/Library/DoNotDisturb/DB/Assertions.json"
com.apple.sleep.sleep-mode
% plutil -extract data.0.storeAssertionRecords.0.assertionDetails.assertionDetailsModeIdentifier raw -o - "/Users/wakco/Library/DoNotDisturb/DB/Assertions.json"
com.apple.donotdisturb.mode.default
% plutil -extract data.0.storeAssertionRecords.0.assertionDetails.assertionDetailsModeIdentifier raw -o - "/Users/wakco/Library/DoNotDisturb/DB/Assertions.json"
com.apple.focus.work
% plutil -extract data.0.storeAssertionRecords.0.assertionDetails.assertionDetailsModeIdentifier raw -o - "/Users/wakco/Library/DoNotDisturb/DB/Assertions.json"
com.apple.focus.personal-time
% plutil -extract data.0.storeAssertionRecords.0.assertionDetails.assertionDetailsModeIdentifier raw -o - "/Users/wakco/Library/DoNotDisturb/DB/Assertions.json" | grep -v focus | grep -ic com.apple.
0

As you can see, a custom focus is identified as com.apple.focus.name while a standard focus identifies the focus type without the word focus.

This option would however require being limited to macOS 12 Monterey or newer. I checked macOS 11,12,13, and saw the code for macOS 11 and earlier was not as flexible.

If this is possible it would be very helpful to have a defer any OS update but still install items like Safari and Xcode

One of the complaints I've received is when there's an update to Safari, it will just close without any notification to the user. It would be helpful in V5 with SwiftDialog to have the option to display a notification to the user that Safari will quit if there's an update for it.
If that's not feasible then perhaps an option added to ignore updates to Safari, but that wouldnt be the most ideal scenario.

More of a heads up as I know the posture on macOS beta support atm

I'm guessing super's OS logic will need to be updated to factor in RSR updates that add on a letter on to the build number of an OS

"Error: Downloaded macOS update version of 13.2 doesn't match expected version 13.2 (a), trying again in 120 seconds."