Software Update Badly Broken

[MentalFabric]

Hi All,

I'm a mostly mac sys admin. On many of our machines (mostly those that have had a user account migrated or previously were set to a now redundant software update server now return the networking error "timed out (-1001) " when software update is run.

I've tried resetting the software update server, deleting the caches/preferences, running every automation in Onyx and running SU through the terminal, but nothing seems to work.

I've manually upgraded these machines to 10.5.8, but how can I check which other updates they need without a functioning software update (or, how can i fix SU without creating a new account?)

Many thanks!

mentalfabric

 

[Hellhammer]

All updates are published in MacRumors index page or in Page 2 if they are minor. Also, Apple's download page shows all updates

 

[MentalFabric]

All updates are published in MacRumors index page or in Page 2 if they are minor. Also, Apple's download page shows all updates

Thanks, but what I really mean is, how do I know which updates I should take from Apple's download page to apply to these machines? Is there for instance a way I could run a system profile through some app or website?

btw I should mention I also use Apple Remote Desktop, if there's a way I can update using that app? (I've managed to update the ARDclient that way ) And we have a 10.5 xserve running software update server, to the machines that will accept it...

 

[calderone]

I am guessing you have checked the CatalogURL in /Library/Preferences/com.apple.SoftwareUpdate? Is it correct?

Are you managing these machines with MCX?

What does:

softwareupdate -l

return?

You can update using ARD, but of course the problem is knowing what you need. If the above command works, try installing an update from there.

Have you check the logs, to see if you can get any more information from there?

Did you delete the ~/Library/Caches/com.apple.softwareupdate cache? I know you said you deleted caches, I don't know which ones of course.

EDIT: Are these machines otherwise functioning on your network?

 

[MentalFabric]

I am guessing you have checked the CatalogURL in /Library/Preferences/com.apple.SoftwareUpdate? Is it correct?

Are you managing these machines with MCX?

What does:

softwareupdate -l

return?

You can update using ARD, but of course the problem is knowing what you need. If the above command works, try installing an update from there.

Have you check the logs, to see if you can get any more information from there?

Did you delete the ~/Library/Caches/com.apple.softwareupdate cache? I know you said you deleted caches, I don't know which ones of course.

EDIT: Are these machines otherwise functioning on your network?

Thanks for your help! The com.apple.softwareupdate files had been reset in the terminal and trashed variously in the past, but I think that was what was throwing me off! I've finally found a fix for this problem...

It was the .plist files in HD/Library/Managed Preferences (both system and user softwareupdate.plist files) that were causing the problem - so in the Terminal:

cd ~/.Trash
(enter return)

sudo rm -f
(drag .plist file in to terminal to save path-typing and hit return)

Software Update finally works again! The CatalogURL in the .plist files did seem to be pointing at apple's su servers so not sure what was going on there, but I'm just happy it works again!

for reference:

softwareupdate -l returned a similar error when it was broken
I actually deleted every cache on the machine in my desperation to no avail
and the machines were otherwise functioning perfectly on the network...

I know a lot of people have problems with SU so hopefully this will help someone out!

 

[calderone]

So it was indeed MCX.

Just to make this more clear, were you trying to point your own SU server or Apple's? If so, what plist was conflicting and what information did it have?

I am guessing it was the user plist, assuming the typical hierarchy. But of course it could have been both.

 

[MentalFabric]

So it was indeed MCX.

Just to make this more clear, were you trying to point your own SU server or Apple's? If so, what plist was conflicting and what information did it have?

I am guessing it was the user plist, assuming the typical hierarchy. But of course it could have been both.

Originally the machines were pointed at our own server with no problems, once a bunch of eMacs were migrated to iMacs this problem cropped up on many of the machines and occurred with the upgrade to 10.5 on other machines, so I shut off the SU service and tried to redirect to apple's servers so I could start fresh...

Interestingly, after the machine I was testing this on restarted having accessed SU for the first time in a while, the problem was back again - the CatalogURLs were pointing at our SU server (service still turned off). So I've done the same thing making sure to delete all the other SU .plists as well, figuring they were retaining the wrong info and writing it to the managed prefs. I also am guessing that it's because of the multiple .plists containing the same info that sudo defaults write location CatalogURL myserver:8088 wouldn't even make it work once. Didn't have time to see if it stuck this time, but I know at least that this will make it work once :/ I'll check tomorrow whether it's still working...

edit: forgot to mention that when it stopped working the CatalogURL appeared correct... pointed to our su server which was working for other machines. And that CatalogURLs have always remained uniform across .plists

 

[calderone]

If the problem is coming back, it is likely that the preference is being managed server side on a group of machines, or individually. You will have to stop managing that preference. Even if the service is turned off, if you are managing the software update plist on the server, it keep changing back to the local server you specified in Workgroup Manager.

 

[MentalFabric]

If the problem is coming back, it is likely that the preference is being managed server side on a group of machines, or individually. You will have to stop managing that preference. Even if the service is turned off, if you are managing the software update plist on the server, it keep changing back to the local server you specified in Workgroup Manager.

actually in workgroup manager su is set to manage: never with the su server field blank... we do use OD/workgroup manager but not for SU server... I didn't get anywhere with man mcx, how do I make the terminal tell me whether workgroup manager tells the truth?

 

[calderone]

You can check Managed Preferences in System Profiler --> Software --> Managed Client.

Also check com.apple.MCX.plist in ~ and / That what tell you what prefs are being managed globally.

Also consider that you can manage per user, so the user you are using could have it managed while others do not. Just a thought.

It used to be MCXCacher that could force an MCX update. However, that has changed. Technically MCX updates after 10.5 get pushed instantly. You could look into /System/Library/CoreServices/ManagedClient and see what you can find there.

I believe removing the com.apple.MCX.manifest in ~ should be similar to MCXCacher.

 

[MentalFabric]

You can check Managed Preferences in System Profiler --> Software --> Managed Client.

On the server this is blank, on the client, contrary to workgroup manager on the server, both su and loginwindow (...afp?) are managed...

Also check com.apple.MCX.plist in ~ and / That what tell you what prefs are being managed globally.

same as above... I've deleted this as well as everything else with the CatalogURL inside it I could find but it's still returning with a restart...

Also consider that you can manage per user, so the user you are using could have it managed while others do not. Just a thought.

It used to be MCXCacher that could force an MCX update. However, that has changed. Technically MCX updates after 10.5 get pushed instantly. You could look into /System/Library/CoreServices/ManagedClient and see what you can find there.

there is a ManagedClient 'app' there - doesn't open up anything though...

I believe removing the com.apple.MCX.manifest in ~ should be similar to MCXCacher.

I've deleted com.apple.mcx.plist but can't find .manifest? And I keep finding new prefs listing the old CatalogURL... (there was a 'complete.plist' i missed before too but it doesn't seem to have made a difference including that in my CatalogURL deletions...

Thanks for all your help so far!

 

[MentalFabric]

ooh, having a look at other machines with the same problem, and they have no MCX records whatsoever!

But, the one off fix above still works once, so that's all the thought I'm putting towards this unless someone else has a hint for me