Posted on 07-11-2014 08:26 AM
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?
Posted on 07-11-2014 09:17 AM
Check if your web server is ok, by typing http://jss.company.com.
If you get a "browser can't connect to server", try restarting the apache service by typing this command without the quotes "sudo bash -x /usr/sbin/apachectl -k start". It works for me all the time.
Posted on 07-11-2014 09:30 AM
Thanks isradame. Our web server appears to be working as expected. We are able to download the pkg by hitting the URL directly as well from a browser.
Any other ideas?
Posted on 07-11-2014 11:06 AM
I'm seeing something that looks similar:
Executing Policy Office for Mac 2011...
[STEP 1 of 2]
Downloading http://jss.zzz.com/CasperShare/Packages/MS%20Office%20for%20Mac%202011.dmg...
Error: Could not connect to the HTTP server to download MS Office for Mac 2011.dmg
[STEP 2 of 2]
Posted on 07-11-2014 11:13 AM
njwinter, is this also happening on workstations that are remote and/or using wi-fi with poor network connectivity?
Posted on 07-11-2014 11:22 AM
@sirkyle This is happening with local machines both over WiFi and Ethernet.
The machine can definitely contact the JSS over HTTP. Recon works, re-enrollment works, direct download of pkg via web browser works. Self Service displays everything correctly and attempts to execute the policy but then fails.
Posted on 07-11-2014 12:11 PM
Is there a space in your PKG name? I've seen issues when using Cloud Distribution points and them not interpreting spaces correctly as "%20".
- Justin
Posted on 07-11-2014 12:16 PM
We are running 9.31 (clustered JSS, multiple distro points) and definitely seeing some of this sporadically. Servers/resources appear fine at this time. I don't have a very good view of network health in my role, but some packet captures are probably in order.
Executing Policy BLAH...
Downloading https://jss.company.com/CasperShare/Packages/GarageBand-10.0.2.dmg...
Error: Could not connect to the HTTP server to download GarageBand-10.0.2.dmg
Downloading https://jss.company.com/CasperShare/Packages/iMovie-10.0.4.dmg...
Verifying DMG...
Installing iMovie-10.0.4.dmg...
Closing package...
Downloading https://jss.company.com/CasperShare/Packages/iPhoto-9.5.1.dmg...
Verifying DMG...
Installing iPhoto-9.5.1.dmg...
Closing package...
Posted on 07-11-2014 01:50 PM
@justinrummel Yes, this particular package has multiple spaces in the name but we are't using cloud distro. It was working just fine until very recently. I will try removing the spaces.
The problem seems to be intermittent as well, as @CGundersen notes. My machine, for instance, can install this DMG 100% of the time. I'm beginning to wonder if this is a partial-download-resume issue.
Posted on 07-11-2014 01:59 PM
Got the same problem in my shop, also looking for a fix.
When those computers are connected @ work everything looks ok when connected @home that same policy fails.
Posted on 07-11-2014 03:10 PM
This looks like this is a known issue and it hopefully will be addressed soon.
Posted on 07-14-2014 05:26 AM
Try looking at this article. We were seeing this intermediately as well. Recreating the symlink fixed the issue.
https://jamfnation.jamfsoftware.com/article.html?id=116
We are running 10.9.3 mac server and this is the command specifically that worked for us:
sudo ln -s /Path/To/CasperShare/ /Library/Server/Web/Data/Sites/Default/CasperShare
Posted on 07-14-2014 12:56 PM
Just for the hell of it, does it work okay if you flip the policy to distribute over AFP? If so, there may be a "stuck" download on the client side that needs clearing out. I used to see this more pre-9.
Posted on 07-15-2014 07:03 AM
I've seen the same issue on my side, but what I did to fix it (temporarily) was to remove it from the policy, add it again and then rerun the policy. I, too, have spaces in the file name. I'll look to rename the packages.
Posted on 07-17-2014 08:24 AM
We have been experiencing this same issue since moving to Casper 9.3 (now 9.3.2) earlier this year. It seems very intermittent. Sometimes you can just flush the same policy and it runs fine to the same machine that it had just errored out on (same error as described above). Other machines receive the "pkg" or "dmg" packages fine. We have a ticket in JAMF, and I am testing running a package now that consistently errors to one particular system with "DEBUG" logging right now. I will send that to them shortly.
Also, we cache the vast majority of our installation policies, and "pkg" files, specifically from Adobe, will not download at all anymore. It used to be intermittent as well in Casper 8. Now we have to package it up in a dmg and then a packaged script (utilizing "PayloadFreePackageCreator" has been great) to run the installer after the fact.
Posted on 07-17-2014 01:04 PM
We were seeing the issue as well, below are some notes as to what we experienced and where we are now in our testing.
Server Config w/HTTP issues:
• Mac OS 10.9.3 w/Server 3.1.2
• JSS 9.3.1
• Performance Mode Enabled http://support.apple.com/kb/HT5359
*** Notes:
- A reboot seemed to clear our issues up for a few days or more.
- Memory slowly getting eaten up, appears to be a memory leak (10.9.4 Update appears to clear up the memory issue). The Server would show 95%+ memory utilization.
- App Nap was kicking in for the Finder and for Server app. Not sure of the impact on the HTTP issue, but we decided to test against it, because it is a possible variable.
TESTING SCENARIOS
Test Scenario 1 - Server has delivered all packages as of 7/11/14. App Nap was disabled and Server Rebooted. The memory consumption seems to be a little better after App Nap disable, maybe 80%+ utilization.
Server Config with no issues as of 7/11/14
• Mac OS 10.9.3 w/Server 3.1.2
• JSS 9.3.1
• Performance Mode Enabled http://support.apple.com/kb/HT5359
• Disabled App Nap "defaults write NSGlobalDomain NSAppSleepDisabled -bool YES"
• Rebooted
*** We plan to update this Server to 10.9.4
Test Scenario 2 - Server has delivered all packages as of 7/11/14. App Nap was disabled, OS Updated to 10.9.4 and Server Rebooted. The memory consumption is way better and showing only 20-35% utilization in comparison to 95%+ in 10.9.3 after Server had been running for awhile.
Server Config with no issues as of 7/11/14
• Mac OS 10.9.4 w/Server 3.1.2
• JSS 9.3.1
• Performance Mode Enabled http://support.apple.com/kb/HT5359
• Disabled App Nap "defaults write NSGlobalDomain NSAppSleepDisabled -bool YES"
• Rebooted
Posted on 07-29-2014 10:09 AM
We are on Mac OS 10.9.3, but no memory leakage. We have not tried rebooting the server, but had noticed that after an unrelated Tomcat restart things were better, for a bit.
We have a ticket in to JAMF right now on this, and they are looking thru our debug log now.
Posted on 07-29-2014 10:41 AM
I just fixxed my could not connect to http server problemen, in my case the permissions on the dmg or pkg file was wrong i did a chmod 755
Posted on 08-13-2014 12:19 PM
I'm still experiencing this issue as well, but with an amazon CDP. Initially, doing a chmod 755 fixed the issue, but it's popped up again and it's pretty regular. Sometimes it works, but oftentimes it doesn't. Does anyone have an idea how to fix this?
Posted on 09-18-2014 11:53 AM
This defect (D-005954) was not addressed in 9.5.
Posted on 09-18-2014 01:29 PM
We've been working with JAMF on this issue for a while now. I keep thinking it must be something in our environment. But it is a very intermittent issue. We typically get right around 5-6 errors per day. All other systems have no problems that day. The next day it's typically different computers with the problem, but still only a handful. And of course we're seeing everyday for the "all managed" scoped policies that run daily. Very finicky problem to nail down. But other policies we run once may, or may not see the problem at all.
Posted on 09-18-2014 08:30 PM
I have run into this... is there a partially-cached version of the download in /Library/Application Support/JAMF/downloads or /Library/Application Support/JAMF/Waiting Room? Clearing out those folders periodically seemed to help.
Posted on 10-20-2014 09:13 AM
I am having this same issue. It just started happening Friday, but i also noticed I get an issue for CasperAdmin. Say it cannot connect to my CasperShare.
Posted on 10-20-2014 09:18 AM
The thing that worked for us is to convert all .pkg files to .pkg.zip files. This fixes the permission issue and the failure to find a BOM file.
@palitech - for the failure to connect to CasperShare, double-check that it's not still mounted from a previous session, and eject it before trying to open CasperAdmin again.
Posted on 10-29-2014 09:56 AM
Thanks @jkuo- I got on a webex with JAMF and they had me re-create the symlink. This resolved the issue of the share not mounting. But I am still getting the HTTP error. Will try the .zip method. Also waiting oN JAMF for another webex. Thanks again.
Posted on 10-29-2014 10:51 AM
Check the clients for partially-cached files in:
/Library/Application Support/JAMF/downloads
/Library/Application Support/JAMF/Waiting Room
Purge them. Now try. Does this fix the issue?
Posted on 10-29-2014 12:25 PM
@sirkyle][/url Looks like D-005954 wasn't addressed in 9.6 either. :(
@RobertHammen that might fix the problem on one Mac, the pressing concern is the issue effects users across our global environment. Hoping JAMF addresses the defect soon.
Posted on 10-29-2014 05:10 PM
@donmontalvo I've seen this issue intermittently and it's frustrating. Often the Macs where it doesn't work, purging those folders fixes the issue on that machine. Thinking about a script to purge those and a weekly policy to do so, but have to be careful it doesn't hose any caching policies (I tend not to use those much)...
Posted on 10-30-2014 01:35 PM
I've started seeing this issue as well
From jamf.log
jamf[16404]: Executing Policy Cisco NAC Agent 4.9.5.3 (Install)... jamf[16404]: Error: Could not connect to the HTTP server to download Cisco2AC-0X1.39EC0BFF39EECP+0gent 0xbff39ec0kg
From running sudo jamf policy -verbose
Downloading Cisco%20NAC%20Agent%204.9.5.3.pkg... 2014-10-30 15:47:10.896 jamf[16404:332f] NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9812) 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... Downloading https://<SERVER>/CasperShare/Cisco%20NAC%20Agent%204.9.5.3.pkg... 2014-10-30 15:47:10.906 jamf[16404:332f] NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9812) Error: Could not connect to the HTTP server to download Cisco2AC-0X1.39EC0BFF39EECP+0gent 0xbff39ec0kg
Opened a case with JAMF referencing this thread. The D-005954 relates specifically to caching packages i was told, where they do not resume if connection was interrupted. So i don't believe that relates to what I am seeing as it's a direct install w/o interruption. It does appear to be garbling up the name though, not just with the %20 spaces, but on that final line. I'll update if i get something more helpful to share from my case.
Posted on 10-30-2014 01:44 PM
Just wanted to chime in that, although we're not using Casper Suite 9 just yet, I have been seeing this issue, because I've been assisting another admin with their version 9.5 JSS. I began seeing problems with an Office update policy that was generating these same errors. The package is valid and is definitely up on the share points. It also contains no spaces, just alphanumeric characters and periods.
I've had to come up with scripted workarounds for some policies due to this issue. It definitely is an annoying one, because there's seemingly no rhyme or reason why its failing.
I can check on permissions at some point, or try creating zipped versions of the files (actually I think the pkg I created automatically became zipped when I uploaded it?) to see what may help.
I hope this gets addressed soon, because its almost a showstopper. If packages fail to download, most deployment policies become useless unless you're pushing a script that's contained within the JSS 9.x database. Those seem to work just fine. Its only when accessing a package from an http share that I see this failure message.
Posted on 10-31-2014 07:16 AM
Also experiencing issues with HTTPS
Executing Policy VPN Install... [STEP 1 of 1] Downloading https://x.x.x.x/CasperShare/Packages/x.dmg... Error: Could not connect to the HTTP server to download x.dmg
We made an IIS instance to run the HTTPS download share.
If I put:
https://x.x.x.x/CasperShare/Packages/x.dmg
into a browser, it immediately pops up asking for credentials, which I provide and it downloads without any issue what so ever.
But once I try it in self service it fails to mount.
Posted on 10-31-2014 07:24 AM
@mm2270 wrote:
I hope this gets addressed soon, because its almost a showstopper.
To be honest, it actually is a show stopper for environments that need to deploy software to remote users (combinations of small pipe, latency, VPN, Wi-Fi, etc.).
HTTP offers resumable downloads. So where a deployment is staged (cache package; install package), Casper has to ensure the download is complete before running the policy. In our case it looks like Casper tries to run the policy before the package is fully cached, then fails, never tries to run again.
We had a talk with some JAMF folks yesterday; they know it's serious and they're putting resources on fixing it.
Don
Posted on 10-31-2014 07:25 AM
@wstewart3 wrote:
But once I try it in self service it fails to mount.
Shouldn't try to mount if the policy is using default HTTP only protocol?
Posted on 10-31-2014 07:27 AM
Probably not....
But I have "Use HTTP downloads" checked with all the right settings as far as I know.
Posted on 10-31-2014 07:36 AM
@wstewart3 are you using a self signed certificate? I was never able to get HTTPS downloads working with a self signed certificate. HTTP downloads work fine.
Posted on 10-31-2014 07:39 AM
In JSS 9.x the default is to use HTTP. When you added the package to the policy, did you select Distribution Point > Specific file share distribution point > File Share Distribution Point > (DP name) > [x] Force file sharing over AFP/SMB?
Posted on 10-31-2014 07:40 AM
That was actually the issue I think.. sort of...
Our certs are not self signed, but I think that was part of the problem. In "General" under "File Share Distribution Points"
We had set:
Server
Hostname or IP address of the distribution point server
To our servers IP address. But once I changed it to our actual host name instead it worked perfectly with HTTPS and username and password credentials.
Posted on 11-20-2014 10:35 AM
we continue to have this problem here as well despite working with jamf for weeks on the issue.
our set up:
hosted JSS with jamf running JSS 9.52.29190.c
VM Win2012 server hosting our CasperShare in our DMZ
no other distribution points
clients spread out around the globe
what we've tried:
+ forcing file sharing over afp/smb
+ forcing http by unchecking the afp/smb options
+ flushing the policy errors to re-run and hope for best
what we've not tried:
purging data in /Library/Application Support/JAMF/downloads & /Library/Application Support/JAMF/Waiting Room
and we won't try that. jamf needs to get their shit together. this functionality is THE CORE SERVICE they provide. i don't want to have to hack around it to make it work. that takes time and effort. and if i'm going to invest my time and effort, it will be on the phone with every jamf VP i can talk to.
this. is. ludicrous.
Posted on 11-20-2014 12:26 PM
We have been getting this for quite a while now, it's probably 10% of machines in a big deployment (all internal so WiFi or Ethernet). It's managable but I just wish there was retry options on policies so you you didn't need to flush failed machines before they retried, it would be lovely if they just retried again 24 hours later.
Haven't tried clearing local client cache files, might add that to weekly maintenance and see if it helps.
Posted on 01-28-2015 04:57 PM
Hey all - I'm still encountering this same issue on a small percentage of computers, regardless of what distribution point/method they are using. I don't see anything in /Library/Application Support/JAMF/downloads & /Library/Application Support/JAMF/Waiting Room and no phantom volumes. Any ideas what else I can try?
Thanks!