This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 492423 - After following a redirect and getting a 404, rhnlib makes a bad http request to the original host
After following a redirect and getting a 404, rhnlib makes a bad http request...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rhnlib (Show other bugs)
4.8
All Linux
high Severity medium
: rc
: ---
Assigned To: Pradeep Kilambi
Jan Hutař
: TestBlocker
Depends On:
Blocks: 490076 492638
  Show dependency treegraph
 
Reported: 2009-03-26 15:32 EDT by James Bowes
Modified: 2013-01-10 05:02 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 492638 (view as bug list)
Environment:
Last Closed: 2009-05-18 16:14:45 EDT
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 James Bowes 2009-03-26 15:32:40 EDT
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
 https://xmlrpc.rhn.webqa.redhat.com/XMLPRC/
instead of something like
 https://xmlrpc.rhn.webqa.redhat.com/XMLRPC/$RHN/channellabel/getPackage/RPM.rpm


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.
Comment 3 Brock Organ 2009-03-27 12:07:59 EDT
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 ...
Comment 8 Jan Hutař 2009-03-31 05:28:55 EDT
Hello,
I can not reproduce with system registered in webqa:

# grep -i serverURL= /etc/sysconfig/rhn/up2date
noSSLServerURL=http://xmlrpc.rhn.webqa.redhat.com/XMLRPC
serverURL=https://xmlrpc.rhn.webqa.redhat.com/XMLRPC
# rpm -q up2date rhnlib
up2date-4.8.1-27.el4.i386
rhnlib-2.1.4-4.el4.noarch

But according to the tshark, there is no comunnication with Akamai (96.17.90.196) - already asking this in a email.

https://wiki.test.redhat.com/BaseOs/Projects/Akamai/VerifyAkamaiWorks

Regards,
Jan
Comment 9 Grant Gainey 2009-03-31 08:42:55 EDT
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.
Comment 18 errata-xmlrpc 2009-05-18 16:14:45 EDT
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.

http://rhn.redhat.com/errata/RHBA-2009-0974.html

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