Red Hat Bugzilla – Bug 492423
After following a redirect and getting a 404, rhnlib makes a bad http request to the original host
Last modified: 2013-01-10 05:02:21 EST
From an email thread about an rpm existing in the qa env but not on the cdn:
This particular package exists in webqa but not in rhn live, so when
up2date is redirected to the CDN it gets a 404 response. At this point
up2date incorrectly requests
instead of something like
IMO this isn't very major from rhn hosted's POV. If we redirect and the client can't get the rpm from the CDN on the first try, then they aren't going to get it at all. The client should probably make its retry requests against the CDN though, rather than returning to hosted.
The consensus from yesterday's conf call with jbowes, brandon, ggainey, morazi and others was that this defect is legitimate, and needs to be addressed before 4.8 goes live ...
So I will ask the devel folks for an ack on this bug, to get the process moving forward ...
I can not reproduce with system registered in webqa:
# grep -i serverURL= /etc/sysconfig/rhn/up2date
# rpm -q up2date rhnlib
But according to the tshark, there is no comunnication with Akamai (18.104.22.168) - already asking this in a email.
In WEBQA, in order to fix the "newer RPMs in WEBQA than in PROD" issue, pursuant to the conversation on 26-MAR referred to in COmment#2, we changed things so that rhn.webqa points to fake-akamai at content-xmlrpc.rhn.webqa which points to origin.rhn.webqa.
client-cdn is ON, whitelist is OFF. IP address of "akamai" in this environment is 10.10.40.112, and I see lots and LOTS of 302/redirects happening.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.