Bug 142432 (IT_56874) - As configured, the hardware discovery script fails
Summary: As configured, the hardware discovery script fails
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: IT_56874
Product: Red Hat Ready Certification Tests
Classification: Retired
Component: other
Version: beta
Hardware: ia64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Rob Landry
QA Contact: Rob Landry
URL:
Whiteboard:
Depends On:
Blocks: 143442
TreeView+ depends on / blocked
 
Reported: 2004-12-09 18:07 UTC by Glen A. Foster
Modified: 2007-04-18 17:16 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-03-17 04:56:02 UTC
Embargoed:


Attachments (Terms of Use)
/var/log/rhr/debug (38.02 KB, text/plain)
2004-12-09 22:07 UTC, Glen A. Foster
no flags Details
typescript of running session (990 bytes, text/plain)
2004-12-09 22:30 UTC, Glen A. Foster
no flags Details

Description Glen A. Foster 2004-12-09 18:07:12 UTC
Description of problem: I installed the rhr2-rhel4-0.9-14.9i package
and started running the scripts - checking on fixes, etc.

Along the way I found that the 'discovery' script fails with the
following dialog box entitled " FAILED - Red Hat Ready" and text of:

FAILED: Could not establish required connection to xmlrpc.rhn.redhat.com

... this is new.  Is there some undocumented configuration requirement
for this utility to now work?

Version-Release number of selected component (if applicable):
# rpm -q rhr2-rhel4
rhr2-rhel4-0.9-14.9i

Comment 1 Glen A. Foster 2004-12-09 18:24:49 UTC
Adding Suzanne to the cc: list

I also forgot to mention, but it's probably apparent to Rob that with
this issue I cannot run any of the other cert-suite tests without
coming up with a hardware.conf file.

Comment 2 Rob Landry 2004-12-09 19:54:29 UTC
actually this is not a new requirement but a work around for an
already existing one.  Specifically discovery uses hardware.py from
rhn; previously if this couldn't reach xmlrpc.rhn.redhat.com then you
would end up with an essentially blank hardware.conf.

My guess would be that this particular machine (a)cannot reach
xmlrpc.rhn.redhat.com and (b)does not have http installed which means
that the rhr2 scripts couldn't work around the problem either; thusly
you get the error message as described above.

Can we verify that (a) and (b) is true?

Comment 3 Glen A. Foster 2004-12-09 20:14:43 UTC
(a) is not true.  I can run up2date just fine.  I am behind a
corporate firewall, and I'm not sure where in the cert-scripts I'd
need to set a proxy, so perpaps that's the issue with this.

(b) is not true, either; this is an 'everything' install of RHEL4 pre-RC1

Comment 4 Rob Landry 2004-12-09 21:52:55 UTC
Bummer, that's it for my ideas; looks like we'll have to use debug
mode; can that be duplicated with the -d flag? ("redhat-ready -d
/var/log/rhr/debug discovery") and then the debug file attached.

Comment 5 Glen A. Foster 2004-12-09 22:08:00 UTC
Created attachment 108265 [details]
/var/log/rhr/debug

as requested...

Comment 6 Rob Landry 2004-12-09 22:22:43 UTC
Thanks you sir; can we try a "ab xmlrpc.rhn.redhat.com/; echo
RETURNCODE:$?".  Assuming that doesn't exit 0, I believe I understand
the problem and need to code a fix in as discovery is coded to use
xmlrpc.rhn.redhat.com; it's in a variable, but for the purposes of an
end user it might as well be hard coded thusly discovery needs to be a
bit smarter and attempt to use the proxy server if one is configured
instead of always assuming the default.

Comment 7 Glen A. Foster 2004-12-09 22:30:05 UTC
Created attachment 108274 [details]
typescript of running session

I even tried setting http_proxy in another run of 'ab'; they both fail the same
way, apparently.

Comment 8 Rob Landry 2004-12-09 22:33:23 UTC
huh, ok, so that's not the problem I was chasing; though I do have
some more homework to do.  Thanks for the research and quick responses.

Comment 9 Glen A. Foster 2004-12-14 16:09:07 UTC
So that I can make some progress with the RHEL4 cert-suite before
year's end, what do you recommend I run to be able to test some things?

E.g., beta-2 and the -9i packages?  ISTR that some combination of
distro + cert packages worked at least a little.

Comment 10 Rob Landry 2004-12-14 17:38:32 UTC
In an attempt to move forward; before a patch comes out; the two
things I can think of are to make something respond as
xmlrpc.rhn.redhat.com to a web request on the same subnet or to change
RHNSERVER in /usr/share/rhr/scripts/define to the same server as PROXY
is configured to.

Comment 11 Rob Landry 2004-12-14 17:54:20 UTC
If the latter works I believe that's the best option since, as I
understand thing RHNSERVER should be changed to...

`awk -F = ' /serverURL=/ { print $2; } ' /etc/sysconfig/rhn/up2date`

...which should use the proxy by default.


Comment 12 Glen A. Foster 2004-12-14 21:07:53 UTC
Using the second work-around listed in comment #10, I modified line 29
to be the hostname used for $http_proxy and re-ran the discovery
script.  I got the following errors printed:

WARNING: unable to read from /dev/hda

(yes, the CD drive was empty at the time of running the script).  I
was also able to proceed past the "Could not establish required
connection..."; I was prompted (as expected) for the # of USB devices
and I was able to get a "hardware.conf" and can run past that.

Another way I was able to proceed was to install RHEL4 beta-2 and
rhr2-rhel4-0.9-14.9b package and go from there, then save
/etc/rhr/hardware.conf for later use.

Let me know if there's anything I need to do to make this patch
available ASAP.

Comment 13 Rob Landry 2005-01-19 17:00:37 UTC
should be fixed in rhr2-1.0-10

Comment 14 Rick Hester 2005-03-17 04:56:02 UTC
confirmed in 1.0-10


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