Skip to main content

I have a fairly simple "Update Firefox" policy that's running right now, and I'm getting a ton of "Error: Package not successfully downloaded: 60" messages with a few successful deployments sprinkled in. I've tried downloading the package via the same path that the policy is using (https://casper.[redacted.com]:8443/CasperShare/Packages//Firefox 13.0.1.dmg) and it downloads fine from the machines I have tested. Why would this crop up now?



Admittedly, I did change the internal port for package distribution from 80 to 8443, but that was earlier this morning. The failures should have started immediately, and been consistent, if it were related to that. Right?

Theory #1: Tomcat is overwhelmed. Now that I'm using 8443 as the port for distributing packages, the OS X web server is no longer serving them - Tomcat is. When I flush the log of problems, I'll get a rush of "package not successfully downloaded" errors in the log, and then a few will trickle in that succeeded.



I have about 600 clients, and this policy affects more than 500 of them.


Why are you using the Tomcat port?


The problem is that we have clients connecting from outside of our network, and we're not able to open :80 (but can open :8443).


What about still using Apache and using 443 instead?


Do you have a cert installed? Is it trusted by the clients?


Jared, I've reverted to using port 80 and the problem is resolved. Our rep agreed that using Tomcat was not recommended. We're still running 10.6 server, and the baked-in Apache version is considered vulnerable by our security team (though I believe it's a "medium" vulnerability). So, my options were to use Tomcat (which doesn't seem to work, but also doesn't show up on scans) or use Apache (works great, picked up on scans). It may just be time to move to 10.7 server.



Bentoms, yep - always have. The change was which web server (and port) were being used to serve the downloads.