Software Upda

[tomdawson]

Hi guys,

 

Having a problem getting Software Update Server going on our Mac Mini server.

 

The service is started, configured to copy all updates from Apple, and to automatically enable copied updates. Configured to provide updates on the standard port 8088. But nothing happens. The only thing I get in the Service log is the following:

 

Fri Jan 14 09:35:21 swupd_syncd[78081] : Unable to download or create .smd file for product zzzz061-9823.

Fri Jan 14 09:35:21 swupd_syncd[78081] : Product zzzz061-9823 will not be available for installation.

Fri Jan 14 09:40:23 swupd_syncd[78081] : Unable to download or create .smd file for product 061-4612.

Fri Jan 14 09:40:23 swupd_syncd[78081] : Product 061-4612 will not be available for installation.

Fri Jan 14 10:02:54 swupd_syncd[78081] : Unable to download or create .smd file for product 061-7365.

Fri Jan 14 10:02:54 swupd_syncd[78081] : Product 061-7365 will not be available for installation.

 

So nothing's actually getting downloaded. But also when you point a client to the server, it says that the server isn't even there, and I get the following in the Error log:

 

[Fri Jan 14 09:26:57 2011] [error] [client ip.add.re.ss] Symbolic link not allowed or link target not accessible: /var/db/swupd/html/index-leopard-snowleopard.merged-1.sucatalog

 

And finally when accessing the server via a web browser it just times out and I get the following in the Error log:

 

[Fri Jan 14 10:22:03 2011] [error] [client ip.add.re.ss] Attempt to serve directory: /var/db/swupd/html/

 

Any suggestions at all?! Any pointers most welcome!

[AntonioRocco]

Hi

 

Apple's SUS won't work behind a Proxy that requires authentication:

 

Mac OS X Server v10.4 or later: Requirements for Software Update Service

 

Even if the Proxy is transparent you may find the LEA's upstream Filter blocking access? In my experience it happens a lot. Judging by what you've posted you should use the server's fqdn to access the service as per the kb's instructions. You may be able use the IP address, provided whatever you're using to resolve DNS can resolve the reverse pointer. Lookups from the platform may fail if you're using .local as the TLD for your domain. Depends on the namespace convention you've decided to use.

 

Antonio Rocco (ACSA)

[tomdawson]

Hi Antonio,

 

Thanks for the reply - sorry for my delay.

 

The mac is on an "unfiltered" proxy, but that's only web traffic; are you aware of software update needing or using any other ports?

 

Thanks,

Tom

[AntonioRocco]

Hi Tom

 

SUS uses port 8088 for internal use only. Judging by the information you've provide your problem is there are no updates coming from Apple at all that makes it to your server. That has to be either a block or ACL on your network somewhere or something similar further upstream. If it's neither of those then either you've misconfigured the Server (fiddling with the Firewall Service perhaps?) or there's something fundamentally wrong with the Server itself? Either the OS is borked in some way or the underlying drive/directory structure is not as healthy as it could/should be?

 

What is certain is traffic is clearly making its way out. It's the coming back in again that seems to be the problem? You could try using the tcpdump utility to see what pops up? You may have to run it for a while before you get anything useful back. Can you run Software Update on a client OK? Do updates come down then?

 

Antonio Rocco (ACSA)

[tomdawson]

Hi Antonio,

 

Sorry for the delayed reply, again!

 

Haven't been anywhere near the Firewall service. Yes clients can update OK away from using our own update server, and the server even lists a load of updates, they just don't get put into the list of available updates on the Software Update server :-/

 

Re drive/directory structure being unhappy...is there anything you can suggest? Disk utility's repair permissions thing maybe?

 

Tom.

[AntonioRocco]

Hi Tom

 

DU's repair permissions is worthwhile to run although TBH I hardly ever do it. Still you never know? From the information you've provided most of it seems OK although you've not confirmed you've configured your workstations as the kb article advises?

 

Antonio Rocco (ACSA)

[tomdawson]

Antonio,

 

I must apologise again for my slow reply! Yes the workstations are configured as the KB article suggests...however when accessing http://swscan.apple.com and all the other listed URLs I just get given a 404 not found error...? So how come each workstation and the server gets a list of updates if you manually run sw update?!

 

I will endeavour to getting around to a speedier reply this time!

 

Cheers

[AntonioRocco]

Hi Tom

 

The reason why you're getting 404 errors is because those urls are not actually real websites. The kb article clearly states:

 

"The latter (http://swcdn.apple.com) currently redirects to the Akamai content distribution network that hosts the updates. Note that the redirected IP address of http://swcdn.apple.com may vary over time or by geographic region."

 

Those urls all redirect to the Akamai network. This network - or at least the Apple content distribution part of it - are not easily accessible using a web browser. The Software Update Preferences Pane in OSX Client and Server as well as the Software Update Service in OSX Server are designed to access this network in a way that's not transparent to the end user.

 

It's looking more and more likely that either your local or upstream proxies are blocking access? You could look at running a traceroute to those urls and seeing at what point the trace stops? This is what I see when running traceroute from my network:

 

traceroute swcdn.apple.com

traceroute: Warning: swcdn.apple.com has multiple addresses; using 84.53.178.16

traceroute to a950.gi3.akamai.net (84.53.178.16), 64 hops max, 52 byte packets

1 cpc5-basf9-2-0-gw.12-3.cable.virginmedia.com (82.13.18.1) 11.185 ms 17.400 ms 12.472 ms

2 nott-core-1a-ge-310-2117.network.virginmedia.net (62.255.214.141) 9.763 ms 9.801 ms 7.952 ms

3 leed-bb-1a-as0-0.network.virginmedia.net (213.105.174.169) 59.333 ms 11.300 ms 14.284 ms

4 nrth-bb-1b-as2-0.network.virginmedia.net (62.253.185.101) 12.244 ms 15.058 ms 18.540 ms

5 nrth-tmr-2-ae6-0.network.virginmedia.net (213.105.159.34) 16.547 ms 17.583 ms 17.579 ms

6 tele-ic-1-as0-0.network.virginmedia.net (62.253.184.2) 16.097 ms 14.239 ms 15.834 ms

7 84.53.177.193 (84.53.177.193) 17.391 ms 17.921 ms 17.609 ms

8 84.53.178.16 (84.53.178.16) 15.146 ms 22.225 ms 17.224 ms

 

If you're not seeing the same it's probably your firewall, filter or proxy or a combination of all three?

 

You could also use the tcpdump utility to log traffic as it goes to and fro. Amongst the reams and reams of data you'll definitely see at what point packets are being dropped and which IP address/host is dropping those packets.

 

Antonio Rocco (ACSA)

Edited February 5, 2011 by AntonioRocco