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.
Managing OS X 
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.
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
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.
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?
Go call steve jobs:Dhehehe:D
This can be achieved by creating an daily.local file. The daily.local file continues after the daily periodic script runs at 3.15am.
The daily.local file can point to other scripts like repair permissions, software update etc. Then using mcx set startup and shutdown times like startup 3am shutdown 6.30am everyday.
Then the machines will update from the enabled updates from your sus server at night without having to do anything.
One step further is to create a trigger file and use ligon to create a launch daemon if the trigger file is touched. Then create a read only apple script and put it in /Library/Scripts, the users can they access it from the scripts menu. The apple script simply touches the trigger file. The software update.app will run as root user and will not prompt for admin details. I have used these method for a number of year now.
I think that for most environments it’s going to be more complex than that. A task run by periodic at 3:15 am isn’t always going to do the right thing if a user remains logged in overnight with an open, unsaved document, or for a laptop user who has closed the lid or taken the machine home for the night. But if your environment is controlled enough that you can do this, then great!
If a user is logged on with unsaved documents the computer will not force shutdown it just cancels out so no problem there
Laptops are problems but the best way is through a launch daemon and script. I use a script which runs at startup and checks if the last daily, weekly and monthly ran when connected to the corporate network. If it didn’t it runs next time its started up and on the LAN
I was able to create a shell script that checks the user status and checks to see if there is any software updates. If there are no software updates, the script stops. If there are software updates and the user is logged in, it will install any updates it can and then the next time the user restarts his/her machine, it will install the rest of them. And lastly, if the user is not logged on and there are software updates, it will display a message to the user, then install the updates, then restart after it is finished. However, I have setup a cronjob that runs this script. (Times are different if it’s a laptop or desktop.) Then, in WGM, all users cannot access Software Update unless they are an admin.
Any chance you still have that script? or could share pieces of it?
Just use Munki! http://code.google.com/p/munki/wiki/AppleSoftwareUpdatesWithMunki