Description of Problem:
Updating a number of machines is very slow, since the same (often large)
packages must be downloaded repeatedly by each machine. It would be useful
if it were possible to fetch the package RPM (not the header data) via
normal http rather than over SSL. The RPM is already protected by both an
MD5 and a GPG signature, so no security is lost. I envisage a procedure
1. Check local disk for already-downloaded package (this already happens
2. If option "Fetch packages through HTTP Cacheing Proxy" is not checked,
2. Fetch package using cacheing http proxy.
3. Check package. If package fails or is truncated, fetch package again
with Pragma: no-cache set to force the cache to refresh.
4. Check package. If package still fails, the proxy is bad. Complain and
fall back to SSL operation. Goto 6
5. Done fetching this package, proceed to next package
6. Fetch package using SSL method, proceed to next package
In the general case the proxy's copy will be good, saving much download
time and load on the RHN servers. Having to turn the option on in the first
place forces the Sysadmin to assess whether or not his cache is going to
We're kind of going that path. We still miss a configuration option and
some tweaking to treat GET requests differently than regular XMLRPC calls (which
go over POST), but the request is already cacheable, and was made cacheable
exactly for this reason.
So then should this request be closed?
Yes, the client has a configuration option, useNoSSLForPackages, which allows
one to do non-SSL GETs (independent of the protocol chosen for the server).
Fix confirmed with up2date-2.7.86-7.x.3.