Apple Software Update wishes
Since we’ve examined some ways to script around Software Update’s limitations, I thought maybe now would be a good time to describe changes I’d like to see to Apple’s Software Update so we don’t have to hack at it…
When a client is managed via MCX to use an internal Software Update Server, there should be an additional management option that causes Apple Software Update to behave in the following manner:
- Available updates are downloaded in the background. (This exists currently)
- When all available updates have been downloaded, if a user is logged in, the user is notified that updates are available (This also exists currently)
- When the user clicks “Install”, the updates should be installed without requiring administrator credentials. Since the admin has “approved” the updates by making them available on the internal Software Update Server, and has enabled the proposed “non-admin” install option via MCX client management, no further administrative approval should be needed/required. (This would be new behavior).
- If no user is currently logged in, all managed updates (those on the internal SUS) are installed, but there is a progress window displayed over/instead of the loginwindow so a user does not login or power off a machine during a software update session. (This would be new behavior).
These changes would allow systems administrators to deploy Apple software updates to a group of machines without resorting to scripting hacks, running background command-line processes that can interfere with active users, or third-party tools that largely (and incompletely) duplicate Apple’s solutions.
In addition:
- Admins should be able to mark updates on their internal Software Update Servers as mandatory.
- When an OS X Client is managed to use an internal SUS, updates marked as mandatory should not be able to be deselected by the user.
This change would allow systems administrators to use an internal Software Update Server to deploy critical updates (like Security Updates) without resorting to scripting hacks or third-party tools.
October 13, 2009 at 8:29 am
I like your idea, but would like to add one small change:
Why make it dependent on having your on SUS. If you have a SUS, then you are approving/holding back updates. But if you don’t then you are implicitly saying that Apple is doing the approving for you. So why not offer the option to put this mechanism in play even when there is not a SUS involved?
And going even one step further, there are probably a lot of unmanaged computers (say one at home) that could benefit from this option. So rather than tying it to MCX policies only, make it a checkbox in some preference pane. I agree that this should be controllable by MCX, but think that there is a broader use as well.
I have always been surprised that the ability for non-admins to do updates never made it into /etc/authorization. It would seem to be a natural fit. I do like your addition to it Greg, so would push for that, but I would be happy with a /etc/authorization entry.
October 13, 2009 at 9:42 am
What I’ve decided to do is block network accounts from logging in and displaying text in the loginwindow indicating that software updates are running and login is disabled.
However I’m having a lot of internal debate as to how I want to achieve this.
One approach is running a script that changes settings locally, then puts them back after updates are installed.
Another is placing machines in an OD group with the loginwindow prefs set to run all this, and the end of the script putting the machine back into its proper group
October 13, 2009 at 9:47 am
The easiest way to prevent logins is to obscure the loginwindow with something like iHook or MunkiStatus. These can cover the loginwindow and present status info. Unfortunately, that status info would be limited to something like “Installing Apple updates, please be patient…”, and the user would have no idea if it’s going to take 1 minute or 30 minutes, or even if the process has hung. So in my environment, it’s a less-than-ideal solution.
October 13, 2009 at 9:58 am
Locally if you modify /var/db/dslocal/nodes/Default/groups/com.apple.access_loginwindow.plist it will disable network logins, specifically the nestedgroups array.
That’s what gets changed when you check/uncheck “Allow Network Users to login to this computer”
Sadly there is still the complete lack of an accurate progress indicator. Maybe using echo to pipe the output of softwareupdate to osascript?
December 22, 2009 at 3:18 am
Go call steve jobs:Dhehehe:D