Description of problem: system-config-network crashes with a Python traceback if /etc/hosts contains an invalid entry, e.g., a line with just an IP address Traceback (most recent call last): File "/usr/sbin/system-config-network-gui", line 167, in main window = mainDialog() File "/usr/share/system-config-network/netconfpkg/gui/maindialog.py", line 248, in __init__ self.hydrate() File "/usr/share/system-config-network/netconfpkg/gui/maindialog.py", line 392, in hydrate self.hydrateProfiles() File "/usr/share/system-config-network/netconfpkg/gui/maindialog.py", line 602, in hydrateProfiles hclist.append([host.IP, host.Hostname, TypeError: sequence item not a string or unicode object Version-Release number of selected component (if applicable): system-config-network-1.3.99.12-1.el5.noarch How reproducible: every time Steps to Reproduce: 1. edit /etc/hosts and add a new line with only an IP address 2. launch system-config-network Actual results: crash with Python traceback Expected results: user friendly error message Additional info: system-config-network-1.5.95-1.fc10.noarch in Fedora 10 handles this gracefully, so we just need a backport of some changes to fix this
The problem seems to be that host.Hostname is None when there's just an IP address in /etc/hosts, and hclist doesn't like None ("not a string or unicode object"). This band-aid allows s-c-network to start: --- maindialog.py.ORIG 2008-11-12 12:45:32.000000000 -0600 +++ maindialog.py 2009-03-30 13:27:11.000000000 -0500 @@ -599,6 +599,8 @@ # skip localhost and comment lines if host.IP == "127.0.0.1" or host.IP == '::1' or host.isComment: continue + if host.Hostname == None: + host.Hostname = "" hclist.append([host.IP, host.Hostname, string.join(host.AliasList, ' ')]) hclist.set_row_data(row, host) In newer releases, the CList was changed to a Gtk ListStore which is happy to have None as an entry. http://git.fedorahosted.org/git/system-config-network.git?p=system-config-network.git;a=commit;h=0c0d5cf9218bf66234b1fb09ed6e4f8f7ee3c851
Created attachment 337253 [details] backported upstream patch from comment #1 This is the upstream patch from comment #1 backported to RHEL5. With this patch, s-c-network no longer crashes on the bad /etc/hosts entry, but it doesn't report the error either. Some more work is needed.
*** Bug 502628 has been marked as a duplicate of this bug. ***
*** Bug 508083 has been marked as a duplicate of this bug. ***
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
*** Bug 574108 has been marked as a duplicate of this bug. ***
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: When the /etc/hosts configuration file contained an invalid entry (for example, an IP address without a hostname), an attempt to run the system-config-network utility failed with a traceback written to standard error. This update corrects the utility to verify that the /etc/hosts file does not contain erroneous lines. As a result, when an invalid entry is present, a warning message is displayed, and system-config-network starts as expected.
I am trying system-config-network-1.3.99.19-1.el5 and it writes such a warning with erroneous /etc/hosts: # system-config-network ERROR: Error while parsing /etc/hosts: Wrong Hostname on line 8 Wrong Hostname on line 10 Wrong Hostname on line 11 /usr/share/system-config-network/netconfpkg/gui/maindialog.py:282: GtkWarning: gtk_window_realize_icon: assertion `info->icon_pixmap == NULL' failed self.dialog.show() There is no warning in old version, system-config-network-1.3.99.18-1.el5.noarch Could this warning be fixed?
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-2011-0817.html