Bug 55502 - Allow package RPMs to be fetched via http cacheing proxy
Allow package RPMs to be fetched via http cacheing proxy
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
4.0
All Linux
high Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-01 08:48 EST by Thais Smith
Modified: 2015-01-07 18:52 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-31 15:26:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thais Smith 2001-11-01 08:48:55 EST
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 
like:

1. Check local disk for already-downloaded package (this already happens 
anyway)
2. If option "Fetch packages through HTTP Cacheing Proxy" is not checked, 
goto 6
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 
work right.
Comment 1 Mihai Ibanescu 2001-11-01 11:07:02 EST
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.
Comment 2 Greg DeKoenigsberg 2002-01-31 15:16:56 EST
So then should this request be closed?
Comment 3 Mihai Ibanescu 2002-01-31 15:26:45 EST
Yes, the client has a configuration option, useNoSSLForPackages, which allows
one to do non-SSL GETs (independent of the protocol chosen for the server).
Comment 4 Jay Turner 2002-05-15 08:38:59 EDT
Fix confirmed with up2date-2.7.86-7.x.3.

Note You need to log in before you can comment on or make changes to this bug.