Has anyone implemented the API for Superman? Specifically the api details.
I am a little lost on the configuration of it any help would be appreciated.
https://github.com/Macjutsu/super
Thanks!
Solved
S.U.P.E.R.M.A.N api
+3Best answer by daniel_behan
We plan on using the API for both and seem to have to set up, how is it you are triggering it?
and what was your way of deploying?
For testing I trigger it with a monthly check in using execute command /super however this will prompt the users regardless of pending updates or not.
Thank you
The options are limitless. I'm still testing it myself. You can have one policy that deploys super to all machines, then have separate polices that run /Library/Management/super/super with whichever options you want. How and when you trigger it all depends on your environment and change control procedures. Once it runs, the deferrals are cached locally into a launchdaemon, so the frequency of the policy really depends on how you set the deferrals. Read thoroughly the options regarding default-defer and focus-deadline.
For Apple Silicon Macs, you need either script user credentials that have boot volume ownership, or use API commands in a script so that MDM Commands push the updates. The API credentials in JAMF Pro need the following Permissions: "Computers Create", " Compuers Read", and "Send Computer Remote Command
to Download and Install macOS Update".
You can encrypt those credentials in a script. The deferral and deadline options need to be read through a few times to suit your environment.
I have a policy that caches super, then runs the following script. In this example, I left a default of 3 deferrals.
"#!/bin/bash
function superSilicon () {
APIUSER="JAMF_APIUSER"
pword="Encrypted_JAMF_APIPASSWORD"
/Library/Management/super/super --jamf-account $APIUSER --jamf-password $pword --count-deadline 3
}
function superIntel () {
/Library/Management/super/super --count-deadline 3
}
function superbyProcessor () {
# Check to see if Intel or Apple Silicon
processor=$(/usr/bin/arch)
if [ "$processor" = "i386" ]; then
superIntel
elif [ "$processor" = "arm64" ]; then
superSilicon
fi
}
# Run SUPER if installed
if [ -f "/Library/Management/super/super" ] ; then
superbyProcessor
else /usr/local/bin/jamf install -package super.pkg -path /Library/Application\\ Support/JAMF/Waiting\\ Room/ -target "/"
superbyProcessor
fi"
+3We are using it and are encouraged by the results. What questions do you have?
Once install onto a Mac how is it triggered is it a manual process each time you want to update?
do you have any recommendations on best practices to make it as foolproof as possible?
Thanks
+3For Apple Silicon Macs, you need either script user credentials that have boot volume ownership, or use API commands in a script so that MDM Commands push the updates. The API credentials in JAMF Pro need the following Permissions: "Computers Create", " Compuers Read", and "Send Computer Remote Command
to Download and Install macOS Update".
You can encrypt those credentials in a script. The deferral and deadline options need to be read through a few times to suit your environment.
I have a policy that caches super, then runs the following script. In this example, I left a default of 3 deferrals.
"#!/bin/bash
function superSilicon () {
APIUSER="JAMF_APIUSER"
pword="Encrypted_JAMF_APIPASSWORD"
/Library/Management/super/super --jamf-account $APIUSER --jamf-password $pword --count-deadline 3
}
function superIntel () {
/Library/Management/super/super --count-deadline 3
}
function superbyProcessor () {
# Check to see if Intel or Apple Silicon
processor=$(/usr/bin/arch)
if [ "$processor" = "i386" ]; then
superIntel
elif [ "$processor" = "arm64" ]; then
superSilicon
fi
}
# Run SUPER if installed
if [ -f "/Library/Management/super/super" ] ; then
superbyProcessor
else /usr/local/bin/jamf install -package super.pkg -path /Library/Application\\ Support/JAMF/Waiting\\ Room/ -target "/"
superbyProcessor
fi"
We plan on using the API for both and seem to have to set up, how is it you are triggering it?
and what was your way of deploying?
For testing I trigger it with a monthly check in using execute command /super however this will prompt the users regardless of pending updates or not.
Thank you
We plan on using the API for both and seem to have to set up, how is it you are triggering it?
and what was your way of deploying?
For testing I trigger it with a monthly check in using execute command /super however this will prompt the users regardless of pending updates or not.
Thank you
The options are limitless. I'm still testing it myself. You can have one policy that deploys super to all machines, then have separate polices that run /Library/Management/super/super with whichever options you want. How and when you trigger it all depends on your environment and change control procedures. Once it runs, the deferrals are cached locally into a launchdaemon, so the frequency of the policy really depends on how you set the deferrals. Read thoroughly the options regarding default-defer and focus-deadline.
+4Once install onto a Mac how is it triggered is it a manual process each time you want to update?
do you have any recommendations on best practices to make it as foolproof as possible?
Thanks
Currently, yes, we trigger it via a policy that we update monthly to meet the deadlines that we have for compliance.
Kevin, the developer, is working on version 2.0 now and he hopes to have a daily run companion part.
As for the API part, creating a user with a very narrow permission set does the trick for us. When we don't have a mandatory update policy running we can disable that user or change the password and it is neutered.
+3Currently, yes, we trigger it via a policy that we update monthly to meet the deadlines that we have for compliance.
Kevin, the developer, is working on version 2.0 now and he hopes to have a daily run companion part.
As for the API part, creating a user with a very narrow permission set does the trick for us. When we don't have a mandatory update policy running we can disable that user or change the password and it is neutered.
Thanks this makes sense now.
+21For Apple Silicon Macs, you need either script user credentials that have boot volume ownership, or use API commands in a script so that MDM Commands push the updates. The API credentials in JAMF Pro need the following Permissions: "Computers Create", " Compuers Read", and "Send Computer Remote Command
to Download and Install macOS Update".
You can encrypt those credentials in a script. The deferral and deadline options need to be read through a few times to suit your environment.
I have a policy that caches super, then runs the following script. In this example, I left a default of 3 deferrals.
"#!/bin/bash
function superSilicon () {
APIUSER="JAMF_APIUSER"
pword="Encrypted_JAMF_APIPASSWORD"
/Library/Management/super/super --jamf-account $APIUSER --jamf-password $pword --count-deadline 3
}
function superIntel () {
/Library/Management/super/super --count-deadline 3
}
function superbyProcessor () {
# Check to see if Intel or Apple Silicon
processor=$(/usr/bin/arch)
if [ "$processor" = "i386" ]; then
superIntel
elif [ "$processor" = "arm64" ]; then
superSilicon
fi
}
# Run SUPER if installed
if [ -f "/Library/Management/super/super" ] ; then
superbyProcessor
else /usr/local/bin/jamf install -package super.pkg -path /Library/Application\\ Support/JAMF/Waiting\\ Room/ -target "/"
superbyProcessor
fi"
getting Error: Unrecognized Options: --count-deadline 3
+4getting Error: Unrecognized Options: --count-deadline 3
Join the #super slack channel in Mac Admins. Kevin is responsive and helpful.
https://macadmins.slack.com/archives/C03LKQ8EN2C
+21changed-count-deadline 3 to --hard-count=3
currently version 2 once deferred creates a launch daemon pointing to /Library/Management/super/super-starter which doesn't exist and so it does nothing.
Can you also use for prompting users to upgrade 3rd party applications too? I looked at IBM Notifier some months ago but never got around to doing anything with it.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.