Bug 107201

Summary: up2date registration errors on step 3: hardware
Product: [Fedora] Fedora Reporter: Greg Bogle <greg>
Component: up2dateAssignee: Adrian Likins <alikins>
Status: CLOSED CURRENTRELEASE QA Contact: Fanny Augustin <fmoquete>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: redhat.10.magnum3065, redhat.bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-24 20:00:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
test script for testing network hostname
none
Output of testhardware.py
none
Output of ifconfig none

Description Greg Bogle 2003-10-15 19:20:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 
1.1.4322)

Description of problem:
At Step 3 in registration for up2date (up2date --register), all fields 
show 'ERROR' for data, and I get a traceback in the terminal window:

Traceback (most recent call last):
  File "/usr/share/rhn/up2date_client/gui.py", line 759, in onProfilePagePrepare
    self.hardware = hardware.Hardware()
  File "/usr/share/rhn/up2date_client/hardware.py", line 511, in Hardware
    ret = read_network()
  File "/usr/share/rhn/up2date_client/hardware.py", line 339, in read_network
    hostname, ipaddr = findHostByRoute()
  File "/usr/share/rhn/up2date_client/hardware.py", line 319, in findHostByRoute
    hostname = socket.gethostbyaddr(intf)[0]
socket.herror: (1, 'Unknown host')

I just did an install (not an update) of Test3 on an IBM Thinkpad 600X.  I had 
Test2 on it, and registration worked fine then.

Version-Release number of selected component (if applicable):
up2date 4.1.7-1

How reproducible:
Always

Steps to Reproduce:
1. Run up2date --register
2. Enter data in windows...use an existing account
3.Check "Included Information" in Step 3: Register a System Profile - Hardware
    

Actual Results:  Window shows "ERROR" (without the quotes) as the data value in 
all fields in the "Included Information" box.  Traceback occurs in Terminal 
window.

Expected Results:  Various valid values in each field

Additional info:

Comment 1 Adrian Likins 2003-10-15 20:18:09 UTC
interesting. Could you send me the output of
     /sbin/ifconfig

and the output of the testhardware.py script
attached to this bug report?

Comment 2 Adrian Likins 2003-10-15 20:18:49 UTC
Created attachment 95210 [details]
test script for testing network hostname

Comment 3 Greg Bogle 2003-10-17 01:01:50 UTC
Created attachment 95246 [details]
Output of testhardware.py

Comment 4 Greg Bogle 2003-10-17 01:02:21 UTC
Created attachment 95247 [details]
Output of ifconfig

Comment 5 Mads V. Pedersen 2003-10-18 08:16:26 UTC
I see the same problem on an IBM Intellistation M-Pro 6868-35U with a freshly
installed test3.
I also have the same output from testhardware.py.
Only (small) difference is that my eth0 is configured to IP 192.168.1.100 by
DHCP from my router.
I also tried testhardware.py on a similar box that is set up with RH9 and there
it works fine, could this be a bug in the library python uses on test3?

Is there any more info you would like from me?


Comment 6 Matthew Good 2003-10-27 17:34:23 UTC
This occurs when the ip address of the machine does not resolve to a host name.
 Usually this is a result of using a home router since they don't provide a DNS
lookup for the local 192.168.*.* addresses.  When up2date tries to get a host
name it fails.  The new version up2date-4.1.10-1 seems to try to fix this
problem, but causes another.

In hardware.py in the function findHostByRoute() (line 321) the print statement
is broken:

print _("unable to resolve hostname for for this machine")

Removing the underscore and parentheses fixes this problem, though actually
removing the print statement completely would probably be the way to go.  The
host is set to "unknown" so the user will still see this when it is displayed.

By fixing this I was able to complete registration successfully.

Since Fedora seems to be implementing a lot of tools in Python I think it's
necessary for all the code to be run through some sort of syntax checker prior
to releasing packages.  This will ensure that errors like this one get caught
before the package is released, rather than at run-time.  I'm not really sure
where to put this suggestion since it relates to many projects, so if someone
knows of the appropriate place to suggest this I'll file it there.

Comment 7 Adrian Likins 2003-10-27 17:51:15 UTC
yeah, print statement removed.

seems to work better now, got some testing in.

And since fedora will never actually hit
these code paths (only hit when registering,
which is not used on fedora), looks closed
to me.

4.1.12 has the print removed.