Cannot connect to swscan.apple.com. There may be a proxy in place

[jarednichols]

This has been dogging me for a long ass time and I finally am close to solving it. I know others are in the same boat so listen up:

1. You have a proxy that systems must go through in order to access the outside world.
2. You have an internal SUS that you're setting on client systems through whatever means (MCX in my case).
3. You're collecting receipt information and when machines recon, you get an error during receipt collection (Curl is throwing this one)

   Cannot connect to swscan.apple.com. There may be a proxy in place.

4. The resulting error means that on machines that actually have updates available when the user runs Software Update, a machine's inventory "Software Update" section reports zero updates.

I always thought it odd that even though systems were pointed to an internal SUS they were trying to get out to Apple. Anyway, it seemed to me that an environment variable needed to be set. Because, you can do:

sudo su
http_proxy="http://my.company.proxy:port"
export http_proxy
jamf recon

And things work fine. The available software updates on your internal SUS even show up in the machine's inventory.

So today I set out once and for all to solve this thing. In involves two lines of information in two separate files.

In your /etc/profile file add:

export http_proxy=http://my.company.proxy:port

In your /etc/suoders file add:

Defaults       env_keep += "http_proxy"

Essentially what this is doing is:
1. In /etc/profile setting the environment variable for all users on the system
2. MOST IMPORTANTLY when a user sudos, it does not strip out the http_proxy environment variable. This was my missing link for like the last 3 bloody years.

So now, doing

sudo jamf recon

works as expected. Nice and quick, no timeout during that receipt collection.

However, all is still not working as you'd expect. If you have the "Update Inventory" box checked in the advanced tab of a policy, it will give the proxy error during the policy's execution.

I've done 'env' and 'sudo env' as my logged in normal user, 'env' and 'sudo env' as my casper admin user and 'env' as root and all of them return my proxy information.

I feel like I'm so close to finally licking this problem. Anyone have ideas why machine-initiated recons will now work as expected but not policy-initiated ones?

[charles_hitch · Accepted solution]

To solve this I just created a policy which wrote the CatalogURL entry in the /var/root/Library/Preferences/com.apple.SoftwareUpdate.

sudo defaults write /var/root/Library/Preferences/com.apple.SoftwareUpdate CatalogURL 'http://sus.domain.com:8088/index.sucatalog'

No more cannot connect to swscan.apple.com errors when running recon. This of course only works when you have an internal SUS and you want recon to pull update info from that and not Apple. Otherwise your proxy idea is probably your best bet.

[rockpapergoat]

maybe because recon's running as root during policy runs? check out root's env variables.

[rockpapergoat]

or, i misread that last bit of your post, and that's not the issue…

[jarednichols]

Yeah thought that initially but the env variable comes up everywhere... stumped. Curl is what's throwing the hissy over the proxy. Is there any global curl config file you're aware of? I thought it was supposed to default to environment variables unless you define proxy when you're running it.

[rockpapergoat]

i've seen some evidence that policy runs will spawn a new shell via sh -c #scriptname or similar.

check it out yourself by running: strings /usr/sbin/jamf| grep -i "sh -c"

the jamf binary is basically just spawning subshells for bunch of stuff. i'm guessing the subshell doesn't inherit the env variable here, though i could be wrong.

also, some of what the jamf binary does under the hood is pretty ghetto. some would even call it "wack."

[cvgs]

Did you also do "env" from within a policy? The policy log should show you if the http_proxy shows up or not.

If the http_proxy variable is missing when being run from a policy, you might have success by inserting the env variable into the appropriate launchd.plist (see http://support.apple.com/kb/TS3099).

Now, the jamf binary rewrites those launchd.plists by itself and might overwrite your additions; and i have no idea how the self service app starts its policies; but it might be worth a shot.

Edit: Hmm, launchd environment variables can be set globally by creating /etc/launchd.conf:

bash-3.2# cat /etc/launchd.conf
launchctl setenv MY_ENV_SET_FROM_ETC_LAUNCHD_CONF set_to_something
launchctl setenv http_proxy http://my.proxy.url

[rockpapergoat]

you could try dropping in an /etc/curlrc file with the proxy variables defined. likewise, a /var/root/.curlrc may work.

[tlarkin]

Hey Jared,

I got your email and wanted to respond, but was busy working on a project. Last I checked SUS has issues working with proxies. Does your SUS have a direct connection to the main Apple repository servers? See this Apple KB:

http://support.apple.com/kb/HT3923

from the KB:

Proxy Authenticated proxy servers are not supported by the synchronization module, which means updates will not be mirrored by the server. While the synchronization module may work with non-authenticated and transparent proxy servers, Apple recommends that the Software Update server have direct access to the public Software Update servers listed above.

I do not currently have any proxy servers to test this. Just so I am clear on your set up Jared, you have your internal SUS, pointed to Apple's repository update servers directly, no proxies, correct? Then your clients pointed towards your internal SUS catalog? Do your clients connect to your internal SUS over a proxy?

Thanks for the email earlier and sorry for taking a while to get back to you.

-Tom

[jarednichols]

@rockpapergoat (nate) I'll give those ideas a shot tomorrow. specifically about the curlrc file, every source I could find with Google indicated that curl was "config file-less" and took all of its config as you ran it (via flags) or from the env variables. I'll give it a shot anyway - doesn't hurt right?

@cvgs I'll check out launchd in the morning as well.

Great suggestions, both of you.

@Tom No worries about the delay getting back. Wasn't expecting something immediate as you're a busy JAMF now :)

We're not running authenticated proxy (thank the lord) so that article doesn't apply. There *is* another SUS/proxy article (http://support.apple.com/kb/TS3099) that should have my bloody name all over it because I'm the one that was hammering AppleCare Enterprise Support about the ludicrous statement that SUS was never meant to run behind a proxy. I pretty much wrote that article and they stole it... not bitter ha (Maybe the Apple Internal version has my name on it?? That'd be nice.)

At any rate, the issue isn't that SUS can't get out of the proxy. I'm using Krause's NetBoot/SUS appliance and defined the proxy in Reposado's preferences.plist file to get it outside our walls. It's working just fine.

It's that for whatever reason, even though the client is pointed at our internal SUS where there's no proxy requirement to hit it, the client still insists on going out to swscan.apple.com. No clue why.

Bonus of the new gig: we can GoToMeeting or WebEx if you want to actually see it in (in)action. Old gig didn't allow that :) Though, I know I'm on a trial so you guys aren't obligated to help me out (yet!). It would just be nice to understand this thing that's been dogging me for years and finally bury it.

[rockpapergoat]

alternate take: punt on this and redirect swscan.apple.com transparently via dns on your lan, if you can do it.

less for you to manage that way…

[tkimpton]

Why are you not using authentication proxies? I am finding it hard to understand why you would have proxies without authentication. No point right?

Like the dns idea, but wouldn't your SUS then notbe looking to go out the real apple servers because dns on your lan woud mean your sus server would point to itself for updates to download and fail.

May be all irrelevant in the future if the rumours for 10.8 updates are going to be by app store only turn out to be true!

[charles_hitch · Accepted solution]

To solve this I just created a policy which wrote the CatalogURL entry in the /var/root/Library/Preferences/com.apple.SoftwareUpdate.

sudo defaults write /var/root/Library/Preferences/com.apple.SoftwareUpdate CatalogURL 'http://sus.domain.com:8088/index.sucatalog'

No more cannot connect to swscan.apple.com errors when running recon. This of course only works when you have an internal SUS and you want recon to pull update info from that and not Apple. Otherwise your proxy idea is probably your best bet.

[jarednichols]

@charles.hitch You've got to be f-ing kidding me. This works. I suppose the question now is... why? I've got a system-level enforced MCX defining my SUS.

Does root ignore MCX by default?

[tlarkin]

MCX shouldn't overwrite root's preferences. MCX profiles will go in /Library/Managed Preferences. My SUS servers weren't ever behind proxies so I just manually edited the catalogs to point to my internal. I had 6 of them, 1 parent and 5 children that cascaded. I just used the information from the OS X Server 10.6 administration guide off of Apple's site.

[charles_hitch]

@jarednichols, I can't say conclusively that root ignores MCX but it certainly doesn't look at it here. I have com.appple.SoftwareUpdate.plist set in /Library/Preferences and root doesn't take that setting either. It had to be in root's ~/Library. Anyway glad this helped.

[tlarkin · Accepted solution]

Hey Guys,

I just wanted to chime back in on a few pointers. It has been a while since I set up any SUS boxes, because once you set it up you tend to forget about it. Just some things to consider when using Casper. I had to jog my memory on this because I set up my last SUS boxes probably two years ago last.

You need to add the SUS in the Servers menu under settings in the JSS. You also need to check the box that reads: "Set Server System Wide." This will set the proper settings to all users, including root. Root, I'm pretty sure, may not use the preferences in /Library/Preferences, I think it uses it's own, which would be in root's home folder in /private/var/root.

Then you will need to apply the SUS servers to the clients in Casper. This can be done many ways. At my last job when I was managing 1,000s of Macs I used network segments to set the proper SUS. Then you can use policy to trigger the updates, and again, with policy you can do this a plethora of ways.

So, you shouldn't need to modify anything on your systems with scripts or commands, the framework should be able to configure these settings.

Hope this helps,

Tom

[jarednichols]

Tom-

That helps, thanks. What you mentioned did dust off a portion of my brain that says this makes sense. Thinking back, the reason I was assigning via MCX vs defining the SUSes in Servers and setting via the Network scopes is because we had a lot of machines that were encrypted, a lot of machines that weren't and some that needed bleeding edge updates. All of these machines could exist on the same network segment.

Thus, I needed something a bit more flexible. Setting them with MCX based on smart group therefore would provide that. However, then without it being set for root, you get the proxy timeout.

I may not need that flexibility at my new job, so I think I'll look at going back to setting up the SUS in Servers and setting via the network segments.

Thanks again!

[dwsak]

Is anyone else still having this problem? It returned in our environment (not sure exactly when, but sometime in 9.x) and now even 'sudo defaults write /var/root/Library/Preferences/com.apple.SoftwareUpdate CatalogURL 'http://sus.domain.com:8088/index.sucatalog'' won't fix it.