Error: Could not connect to the HTTP server to download

[sirkyle]

We are experiencing an issue with JSS 9.31 while attempting to cache a large package to remote users over HTTP that are connected via VPN and possibly Wi-Fi.

If you review the policy error below, the package partially downloads then times out. The error is "could not connect to the HTTP server to download pkg." In this policy, an additional smaller package is also cached at the same time. As you can see, this OtherSoftware.pkg has no problem downloading and caching.

We are working with JAMF support, but I would like to know how others in the JAMF community distribute large software deployments to client workstations that may have poor network connections. Also, I was able to reproduce this behavior with a DMG as well.

Actions from policy log:

Executing Policy SomeSoftware Cache Package... Caching package SomeSoftware.pkg... Downloading SomeSoftware.pkg... This package is a PKG or an MPKG, and the index.bom file is not found. Attempting to open the package as a flat package... Resuming download of http://jss.company.com/CasperShare/Packages/SomeSoftware pkg... Error: Could not connect to the HTTP server to download SomeSoftware.pkg Caching package OtherSoftware-1.0.0.pkg.zip... Downloading http://jss.company.com/CasperShare/Packages/OtherSoftware-1.0.0.pkg.zip...

Has anyone experienced this issue?

[RobertHammen]

@Look @jkuo What version of the JSS are you running? On 9.62 or 9.63 and haven't seen this error recently. Have really not changed anything on the web servers. Client I was seeing this at most often was on Server 2008R2 w/IIS. Been decent since on 9.62...

[jkuo]

@RobertHammen - I'm running 9.63. In new development, switching affected clients to use an AFP share instead of SMB navigated this particular issue (all on Linux). But that still doesn't address what happened or our users that are using a cloud distribution point. Any other thoughts?

[nzmacgeek]

Hi there,

Seeing this in a 9.62 environment with JSS and DPs running RHEL 6.6.

Executing Policy Install Canoscan Toolbox...
Downloading https://jssfiles2.aaa.ccc/CasperShare/Packages/CanoScanToolbox_5.0.1.2.pkg.zip...
Error: Could not connect to the HTTP server to download CanoScanToolbox_5.0.1.2.pkg.zip
    Retrying using distribution point CasperShare Main [OGGB]...
Downloading https://jssfiles.aaa.ccc/CasperShare/Packages/CanoScanToolbox_5.0.1.2.pkg.zip...
Error: Could not connect to the HTTP server to download CanoScanToolbox_5.0.1.2.pkg.zip
Submitting log to https://jss.aaa.ccc:8443/

That is despite the fact I can immediately run curl to download the same packages:

mac-16:~ xadmin $ curl -o  CanoScanToolbox_5.0.1.2.pkg.zip -u user:pass https://jssfiles.aaa.ccc/CasperShare/Packages/CanoScanToolbox_5.0.1.2.pkg.zip
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10.9M  100 10.9M    0     0  10.0M      0  0:00:01  0:00:01 --:--:-- 10.0M
mac-16:~ xadmin$ curl -o CanoScanToolbox_5.0.1.2.pkg.zip -u user:pass https://jssfiles2.aaa.ccc/CasperShare/Packages/CanoScanToolbox_5.0.1.2.pkg.zip
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   348  100   348    0     0    467      0 --:--:-- --:--:-- --:--:--   467
mac-16:~ xadmin $

[bentoms]

@nzmacgeek, double check that the username & password for the HTTP DP is correct or present in the JSS.

[jagress]

Hi everyone,

Seeing something similar on our 9.64 JSS. Saw it before in 9.32 and 9.6. Maybe 5-10% of clients that receive a policy requiring HTTP download of a package can't connect to the distribution point. But manually connecting using curl on those machines works fine. Distribution points also working fine. Oftentimes a flush will allow it work in a second execution of the policy, but sometimes not.

Has anyone else found a solution? I can try switching to smb, but would really rather not because of clients external to our network.

[rfreeborn]

We just this week began experiencing the Error: Could not connect to the HTTP server to download... on one of our Distribution Points running Yosemite. After digging around awhile I noticed in File Sharing in Server App that our CasperShare permissions for Everyone had changed to none. Switched back to read only and stopped and started service and http downloads started connecting again. We suspect recent Security update 2015-002 which installed I installed on 3/18 may have been culprit because all was fine before then.

[shassabo]

Hate to necro this thread, but I just ran into this issue in 9.81... Has there been any official response on this at all?

[ronb]

Our initial problem with this had been resolved with an earlier version of Casper. However, we did get this problem again after a Mac OS Server upgrade. In this case it was easily resolved by commenting out a single line in a plist "#listen 8443" -

The Fix:
In terminal, run the command:
sudo nano /Library/Server/Web/Config/Proxy/apache_serviceproxy.conf
 
In the second section of this file, which looks like this:
/Library/Server/Web/Config/Proxy/apache_serviceproxy.conf
listen 80
listen 443
listen 8008
listen 8800
listen 8443
listen 8843

We will comment out 'listen 8443' so that the Server App is not trying to serve responses on that port:
/Library/Server/Web/Config/Proxy/apache_serviceproxy.conf
listen 80
listen 443
listen 8008
listen 8800
"#listen 8443" (without the quotes)
listen 8843

Then CTRL + X to exit, Y to save, and Enter to exit.
Restart the Websites feature in Server.app and then restart Tomcat.

This was from another thread found - https://jamfnation.jamfsoftware.com/discussion.html?id=17110

[shassabo]

I'm running this on Windows Server 2012, but I'll take a look to see if IIS is listening on 8443 (doubtful, but good to check.)

Thanks for hopping on to help.

[jimmy-swings]

Hi - Has anyone had any luck fixing these issues? I'm now working on self enrolment in El Capitan. My JSS has a self signed certificate and our test machine is unable to download policies which include packages. Navigating manually to the .dmg location is successful.

Mon Dec 14 10:22:56 client-name jamf[6365]: Executing Policy Google Chrome 46.0.2490.80...
Mon Dec 14 10:22:56 client-name jamf[6365]:     The network connection was interrupted while downloading the package from https://server-name/CasperShare/Packages/googlechrome-46.0.2490.80.dmg. Attempting to reconnect...
Mon Dec 14 10:22:57 client-name jamf[6365]: Error: googlechrome-46.0.2490.80.dmg is not available on the HTTP server.

[donmontalvo]

Make sure the PKG is on that server and make sure permission is set to 755 (if Windows similar).

[damienbarrett]

I had a very similar issue that JAMF helped me to resolve. In my case, Server.app on 10.10 server had done two things that were getting in the way:

1) there was a redirect set in the Websites section of Server Admin that forwarded all https traffic to http. I didn't set this redirect; it must have been done during Server Admin's setup.

2) Also in the Website section, we had to set the "Store Site Files" to be the Shared Items folder, not the "CasperShare" or "Packages" folder. Seems the http query couldn't navigate the path correctly otherwise. Also something I didn't explicitly setup.

[NightFlight]

To simplify, I just encountered this with 9.81 and it's only on a couple clients with interrupted downloads. Clearing client cache of the partial download at /Library/Application Support/JAMF/Downloads in my case resolves the problem, circumventing the HTTP resume call.

Thu Feb 11 11:03:01 XX-DC063 jamf[61893]: Executing Policy X...
Thu Feb 11 11:03:03 XX-DC063 jamf[61893]:   The network connection was interrupted while downloading the package from http://xx-jssrepo.xxx.com:8080/Packages/X.pkg. Attempting to reconnect...
Thu Feb 11 11:03:03 XX-DC063 jamf[61893]:   The network connection was interrupted while downloading the package from http://xx-jssrepo.xxx.com:8080/Packages/X.pkg. Attempting to reconnect...
Thu Feb 11 11:03:03 XX-DC063 jamf[61893]: Error: X.pkg is not available on the HTTP server.

access_log (server is two minutes off):

[11/Feb/2016:11:05:23 -0500] "GET /Packages/X.pkg HTTP/1.1" 416 386 "-" "jamf (unknown version) CFNetwork/760.2.6 Darwin/15.3.0 (x86_64)"

After clearing the partial X.pkg in /Library/Application Support/JAMF/Downloads

Thu Feb 11 11:06:03 XX-DC063 jamf[63698]: Checking for policies triggered by "X"...
Thu Feb 11 11:06:06 XX-DC063 jamf[63698]: Executing Policy X...
Thu Feb 11 11:06:11 XX-DC063 jamf[63698]:   Verifying package integrity...
Thu Feb 11 11:06:11 XX-DC063 jamf[63698]:   Installing X.pkg...
Thu Feb 11 11:06:20 XX-DC063 jamf[63698]:   Successfully installed X.pkg.

Additionally I tried re-creating the issue by interrupting curl with ^C downloading X.pkg to simulate a resume request. The result was that casper behaved perfectly. Thinking it through... I checked the file sizes.

Cached failed download had a file size of: 46170984
The file size of the current package on the repo: 46163264

The file on the repository is smaller than the one attempting to be resumed. Therefore the start offset for resume was beyond the EOF of the file in the repository - thus the error.

Looking up HTTP response 416
416 Requested Range Not Satisfiable

Makes sense.

I suspect either the interrupted transfer got garbage tacked onto it, or the interruption corrupted the allocation of the file thus it was oversized. Or we've since replaced the package with one slightly smaller.

The long and short of it is (unexpected pun alert!) is that we should be able to get JAMF to resolve this defect by implementing either a file size check or wiping the cached file on HTTP resume failure or even more correctly when it senses a 416 HTTP response code.

[bpavlov]

@NightFlight This is a known issue and you should sign up for 9.9 Beta 1. Check for defect: [D-009836] HTTP Downloads will not resume or overwrite if a package is detected in the /L/AS/JAMF/Downloads folder

[james_ridsdale]

I can also confirm this is a defect - [D-009836]. We have this issue on around 40 of our JSS's. Bit of an issue as it's making our MySQL swell with all of the failed policies.

[NightFlight]

@bpavlov JAMF has a public/customer facing bug tracker? A serach for [D-009836] brings up nothing for me.

[thoule]

@NightFlight Jamf's bug tracker is secret. Your TAM may clue you in if you run into a bug. If you find a bug, they'll give you the number so you can watch for it in release notes of new versions.

I've also seen plenty of download errors (http) in the logs, but after trying again they run successfully. And like others, trying to download manually using the URL and everything works so I know my server is just fine.

[bpavlov]

@NightFlight They do not as already mentioned. It just so happens to be the second most requested feature:
https://jamfnation.jamfsoftware.com/featureRequest.html?id=1699

[donmontalvo]

One of the benefits to Encompass is getting detailed support history for your account, but probably won't get you defects info not related to your account.

I agree, having an open defects database, at least open to Encompass customers, would be extremely helpful.

Don

[bpavlov]

@donmontalvo What is Encompass? And why would a JAMF defects db be available only to Encompass customers? It should be available to all JAMF customers.

[mpermann]

@bpavlov information about Encompass can be found here. I agree, a public facing defects database should be available to all customers.

[millersc]

At minimum clients that are current on licensing should have access to a defect list. Hiding it or making paying clients pay a "premium" to see a monthly defects report is bad business.

[NightFlight]

Well, everyone pretty much agrees that the Apple model sux in this respect. Should we just start a public/external 'Radar' for JAMF ;-)

[bpavlov]

I've suggested that on Slack. Not sure what we would use to track the bugs though. Github? Between release notes which have some defects listed, and what customers have it would provide at least a place where people can search which is better than nothing at this point.

[NightFlight]

It would just be a wish on my part. I don't have the bandwidth to start/maintain it - our IT department runs pretty lean...

[lynnp]

Is this really still an open defect? I have encountered this periodically since we first started using JAMF (9.32) up until now (9.97) and we are still getting this when pushing large packages, such as creative cloud.

Executing Policy ac-PushAdobeCreativeCloud
Resuming download of http://10.12.1.51/Packages/ev-creative-cloud-all-no-scout-no-acrobat-17.3.17-install.pkg.zip...
Error: Could not connect to the HTTP server to download ev-creative-cloud-all-no-scout-no-acrobat-17.3.17-install.pkg.zip.

[donmontalvo]

@lynnp that doesn't look like the D-009836 issue resolved in 9.9, at a glance.

That looks more like network anomalies causing download to stop/start (resume).

we are still getting this when pushing large packages, such as creative cloud.

We cache all PKGs over a certain size...um...Creative Cloud packages would surely exceed our threshold. :)

[lynnp]

@donmontalvo Oh. I suppose if I were actually able to read the defect report that might have been useful :P I really dislike that I have to use my JAMF Buddy as an interface for that information.

What sort of "network anomalies" would consistently affect only JAMF's process for this? This is all internal over a gigabit network. Certainly curl is robust enough to not freak out about even a 20GB download..

Is there a way of configuring the jamf binary to be more tolerant of whatever it is that's causing it to bail out? Or possibly adjusting apache config on the distribution share side?

Caching locally doesn't help us for pushing out the initial install via policy.

[lynnp]

FYI, we wrote a script that curls the package from the same fileserver, unzips, and runs installer and it works 100% of the time. It's hard to think that this isn't the jamf binary doing something stupid that it thinks is really clever.

[Winterhalter]

I'm still seeing the file not found error for the index.bom on HTTP delivery of a .pkg file on JAMF Pro 10.5. :(

[Winterhalter]

Probably a silly question, but does this phantom index.bom file come from indexing a .pkg file (as opposed to a .dmg)?