By default, it seems that Mountain Lion directs software updates to the App Store. Although my internal catalogURL is populated in the com.apple.SoftwareUpdate.plist, I am still redirected to the App Store when I run Software Update... Is there an additional plist that needs to be updated? Thanks for any help.
Answer
Mountain Lion - Internal ASUS
+3Best answer by nessts
the key is you have to use the right URL which they changed from the previous swupd settings.
defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://yourserver:8088/index.sucatalog
yes app store opens, but you will see it respond noticeably faster.
and you can run softwareupdate -ai from the command line to use your internal server without having to look at app store.
+24That's the way Mountain Lion works. There is no longer a Software Update application. Well, there is, in CoreServices, but it just points bak to the Mac App Store. All updates now go through that.
+18the key is you have to use the right URL which they changed from the previous swupd settings.
defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://yourserver:8088/index.sucatalog
yes app store opens, but you will see it respond noticeably faster.
and you can run softwareupdate -ai from the command line to use your internal server without having to look at app store.
+23So what we need is a way for the App Restriction to allow the coreservices version to launch the SoftwareUpdate / MAS, but if the user launches the MAS directly then it will be locked out.
+24Unfortunately I doubt that will be possible, because of how Restricted Software works in Casper. Its just looking for the process name to kill. In the case of the Mac App Store, its just "App Store" That same process name shows up whether you launch the App Store directly from the Dock/Applications folder or it gets launched from Apple menu > Software Update or by double clicking the Software Update.app in CoreServices. In all cases, the App Store will get blocked.
There is no easy solution here other than to perhaps allow users to run Software Update from the command line through a Self Service policy.
+21How about point client machine to your internal sus and have the restricted software to allow root user. You can then provide software update in the self service :)
+24How about point client machine to your internal sus and have the restricted software to allow root user. You can then provide software update in the self service :)
Hmm, that doesn't sound like it would be very effective. Once the App Store launches as root, the user launching it from Self Service doesn't have to install any updates. They can just click on the "Featured" button or whatever and get right to the Mac App Store and purchase/download stuff. The issue here is the new multi purpose use of the App Store application. Before 10.8 it was quite simple. Software Update.app was for system and Apple application updates. Mac App Store was for everything else. You could block one or both, or none. Now with them being merged, it gets complicated.
Fortunately where I am we allow users to do both, as they are all admins, so nothing really blocked. So not a big problem here, but I feel the pain of those of you who are in this Apple created pickle :)
+23Going with the commandline / SS, how do we redirect output to the window so the users can see if updates are / were installed?
+18i would use cocoa dialog, run -l first to get the list of updates that had to be run, and then tell the users whats going to install, you can use a progress bar to tell them each update that is installing as it installs.
+24Yeah, CocoaDialog could do it. It was also suggested on another thread to look at Munki for this, though I have not used it so i can't comment on it.
FWIW, I had written a script that installed all available updates that did NOT require a restart that worked great under 10.6 and 10.7. Of course now that Apple made some changes to the command line output in 10.8 for 'softwareupdate -l' the script is broken so I need to work on fixing it at some point. The script could be run through Self Service and displayed a list of the updates that were being installed to the user in their human readable form. In the background it piped the shortname of the updates into 'softwareupdate -i' to install them.
+21ah yes sorry forgotten im already through a proxy so root user wouldn't matter in selfservice.
Does anyone know if the SUS/Netboot appliance works with 10.8 updates?
Im in a situation where i dont want to rebuild the Xserve and set up EVERY single thing again just to get SUS working for 10.8
+10If you don't want to update your OSX server to ML just for SUS, I found this discussion and the same trick used for Lion clients (http://support.apple.com/kb/HT4771) works for ML ones.
https://discussions.apple.com/thread/4026496?start=0&tstart=0
(Look for xiao zhong's post).
If you have "cascading" SUS (http://support.apple.com/kb/HT3765), editing /etc/swupd/swupd.plist and /etc/swupd/swupd.conf has to be done for each server.
+21Thanks Carlo much appreciated?
I'm am managing machines and updating in the background when the periodic scripts run at night after all the machines automatically power on and is no need to freak users out.
I can't comment on Munki because I haven't used it, I want zero interaction! No notice and just do it in the background and update from my sus when I want, simple.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.