Skip to main content
Question

deferring software updates on Macs

  • March 16, 2021
  • 3 replies
  • 15 views
I
Forum|alt.badge.img+7

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:

  • Apple releases Gatekeeper, XProtect, etc, update and the Mac automatically installs it (this is default and is working for me now)
  • Apple releases a security update, point release update, etc and the Mac downloads it in the background (looks like I can do this with a config profile, have not set it up yet)
  • Prevent users from checking for updates via Software Update (looks to be possible via a restriction config profile)
  • Prevent users from installing updates via softwareupdate command
  • Allow users to check for updates in a self-service policy
  • have a scheduled maintenance window once a week whereby any available updates are installed

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.

    3 replies

    snowfox
    Forum|alt.badge.img+9
    • snowfox
    • Contributor
    • March 16, 2021

    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.

    I
    Forum|alt.badge.img+7
    • imy
    • Author
    • Contributor
    • March 16, 2021

    @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.

    I
    Forum|alt.badge.img+7
    • imy
    • Author
    • Contributor
    • March 16, 2021

    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.

    Terms & ConditionsCookie settingsAccessibility statement