Bug 140997

Summary:	network configuration can truncate /etc/hosts to 0 bytes
Product:	[Fedora] Fedora	Reporter:	Andre Robatino <robatino>
Component:	system-config-network	Assignee:	Harald Hoyer <harald>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	1.4.7-1.fc8	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-01-11 22:20:43 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:
Bug Depends On:
Bug Blocks:	87718

Description Andre Robatino 2004-11-27 17:15:57 UTC

Description of problem:
Setting up networking after a clean install of FC3 can cause a
previously normal copy of /etc/hosts to be truncated to 0 bytes.

Version-Release number of selected component (if applicable):
system-config-network-1.3.22-1

How reproducible:
always (but I don't know the exact steps necessary)

Steps to Reproduce:
1.  Do a clean install of FC3 using default hostname
localhost.localdomain.  Verify that /etc/hosts is the following:

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain   localhost

2.  Configure a dial-up modem and corresponding network connection.
  
Actual results:
  /etc/hosts truncated to 0 bytes.  This leads to the error message
when logging in

Could not look up internet address for localhost.localdomain.  This
will prevent GNOME from operating correctly.  It may be possible to
correct the problem by adding localhost.localdomain to the file
/etc/hosts.

(or something to this effect).

Expected results:
  /etc/hosts should be unchanged.

Additional info:
  This bug report is secondhand.  My father did a clean install of FC3
on two basically identical machines, one with an internal and one with
an external modem.  After configuring networking the above problem was
observed on the first machine (and fixed by editing /etc/hosts). 
Immediately after installing on the 2nd machine, we verified that
/etc/hosts was correct.  But after configuring networking, the problem
occurred again.  It seemed likely that configuring networking was the
cause.  I observed that on my own machine, the modification time on
/etc/hosts is exactly the same as that of the files ifcfg-* in
/etc/sysconfig/network-scripts created during network configuration,
indicating that system-config-network does in fact manipulate this
file (though in my case, /etc/hosts remained normal).  Unfortunately,
I don't know exactly the steps he took resulting in the problem, but
whatever they were, it's reproducible.

Comment 1 Harald Hoyer 2004-11-29 11:14:05 UTC

do you have selinux turned on or off?

Comment 2 Andre Robatino 2004-11-29 18:30:53 UTC

  All machines mentioned have the default selinux configuration (on).
 Also forgot to mention that on my machine (which didn't experience
the problem) I configured xDSL, while on both of my father's (which
did) he configured dialup.  Also, my machine is ethernet capable and
his aren't.  On all of these machines, the default
localhost.localdomain is used, so the original /etc/hosts was exactly
the 3 lines above.

Comment 3 Harald Hoyer 2004-11-30 10:08:39 UTC

ok, this is it... Thx for spotting this bug, and sorry it bit you!

Comment 4 Andre Robatino 2005-07-08 17:03:58 UTC

  This bug is now occurring in a clean install of FC4.  I verified that the
modification time on the empty /etc/hosts file is exactly the same as the
/etc/sysconfig/network-scripts/ifcfg-* file created when my father's dialup
configuration is set up, and the error did not occur before the dialup config
was done.  Please upgrade this bug to FC4.

Comment 5 Christian Iseli 2007-01-22 10:07:29 UTC

This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Comment 6 Andre Robatino 2007-01-22 10:21:12 UTC

  I'm updating to FC5 since I'm not absolutely sure it happened in FC6, but am
quite sure it happened in FC5.

Comment 7 Andre Robatino 2007-06-10 01:36:19 UTC

  Just helped my father do a clean install of F7, and verified that configuring
a modem connection still truncates /etc/hosts to 0 bytes (fortunately, we made a
copy in advance).  Updating to F7.

Comment 8 Andre Robatino 2007-06-10 01:50:02 UTC

  Also, as reported earlier, configuring an xDSL connection doesn't seem to
truncate /etc/hosts, though configuring a modem connection does.  The behavior
hasn't changed.

Comment 9 Andre Robatino 2007-06-10 21:40:00 UTC

  My father installed on a second machine, and this time it did not truncate
/etc/hosts.  On the first machine, where /etc/hosts was truncated, he had an
internal modem on ttyS1, which was automatically detected by s-c-network.  On
the second machine, where it was not truncated, he had an external modem on
ttyS0, which was not automatically detected (even though it was connected and
turned on), so he manually changed "/dev/modem" to "/dev/ttyS0", after which it
worked properly.  Other than that, the procedure on both machines was exactly
the same.

Comment 10 Fedora Update System 2007-12-06 20:44:45 UTC

system-config-network-1.4.7-1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update system-config-network'

Comment 11 Andre Robatino 2007-12-06 20:50:14 UTC

  My father yesterday did a clean install of F8, and configuring the modem
didn't wipe /etc/hosts as happened with earlier Fedora versions (this only
pertains to the original system-config-network-1.4.3-1.fc8, of course).

Comment 12 Fedora Update System 2008-01-11 22:20:22 UTC

system-config-network-1.4.7-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.