Posted on 03-16-2021 11:50 AM
I'm trying to get a handle on managing OS updates for Macs and trying to see if there is a way I can accomplish my ideal workflow, which is this:
My questions are:
- is there a way to block all users from running softwareupdate? In my tests, even a standard user was able to update Safari. I want all updates to start from a policy.
- Does a Software Updates policy only install what a Mac has already determined what it needs, or does it do a fresh scan when run? I am using a policy with this now, but as I have it only scoped to Macs that have pending updates I can't tell from my own experience and I have yet to find documentation that states either way.
- regarding deferrals, this post, states that the deferment is from the time the Mac is aware of the update. Is that still the case, and is there a way around that? I know I could do things like make accessing some critical app dependent on being at a certain build, but would rather not have to do that.
Posted on 03-16-2021 01:01 PM
I'm still reading about new changes to softwareupdates myself.
This may help:
Deploying macOS Upgrades and Updates with Jamf Pro
Recently updated to include M1 devices.
Posted on 03-16-2021 01:30 PM
@snowfox Thanks. I think I have seen that before. The issue with that method is that as it's a mass action I don't think it can be scheduled via policy, and it doesn't give the option to delay, which I see that I failed to mention. I want something whereby I release that update at 3 PM Thursday, but the user has until 3 AM Sunday to install it, at which time it automatically applies.
Posted on 03-16-2021 01:36 PM
So I tried this:
#! /bin/zsh
# get path for softwareudpate
swPath=$(which softwareupdate)
# get current permissions and log them in case we need to revert
perms=$(stat -f%A "$swPath")
echo "permissions for $swPath before script are $perms"
# change the permissions
chmod 700 "$swPath"
newPerms=$(stat -f%A "$swPath")
# make sure the change worked
if [[ "$newPerms" != "700" ]]; then
echo "permission change did not work, attempting to revert"
chmod "$perms" "$swPath"
perms=$(stat -f%A "$swPath")
echo "permissions are now $perms"
exit 1
fi
echo "permission change worked"
exit 0
But got this back:
Script result: permissions for /usr/sbin/softwareupdate before script are 755
chmod: Unable to change file mode on /usr/sbin/softwareupdate: Operation not permitted
permission change did not work, attempting to revert
permissions are now 755
This was run from a policy, so as root.
I'm guessing that /usr/sbin is on the read-only part of the disk and that's why this didn't work.