Bug 107201 - up2date registration errors on step 3: hardware
up2date registration errors on step 3: hardware
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
Depends On:
  Show dependency treegraph
Reported: 2003-10-15 15:20 EDT by Greg Bogle
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-24 16:00:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test script for testing network hostname (247 bytes, text/plain)
2003-10-15 16:18 EDT, Adrian Likins
no flags Details
Output of testhardware.py (246 bytes, text/plain)
2003-10-16 21:01 EDT, Greg Bogle
no flags Details
Output of ifconfig (837 bytes, text/plain)
2003-10-16 21:02 EDT, Greg Bogle
no flags Details

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

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:

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 

Expected Results:  Various valid values in each field

Additional info:
Comment 1 Adrian Likins 2003-10-15 16:18:09 EDT
interesting. Could you send me the output of

and the output of the testhardware.py script
attached to this bug report?
Comment 2 Adrian Likins 2003-10-15 16:18:49 EDT
Created attachment 95210 [details]
test script for testing network hostname
Comment 3 Greg Bogle 2003-10-16 21:01:50 EDT
Created attachment 95246 [details]
Output of testhardware.py
Comment 4 Greg Bogle 2003-10-16 21:02:21 EDT
Created attachment 95247 [details]
Output of ifconfig
Comment 5 Mads V. Pedersen 2003-10-18 04:16:26 EDT
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 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 12:34:23 EST
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 12:51:15 EST
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.

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