Bug 62855 - Using neat to configure eth0 via dhcp puts PEERDNS=no into ifcfg-eth0, which is BAD!
Using neat to configure eth0 via dhcp puts PEERDNS=no into ifcfg-eth0, which ...
Status: CLOSED RAWHIDE
Product: Red Hat Public Beta
Classification: Retired
Component: redhat-config-network (Show other bugs)
skipjack-beta2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
:
: 62946 (view as bug list)
Depends On:
Blocks: 61590
  Show dependency treegraph
 
Reported: 2002-04-06 08:29 EST by Manfred Hollstein
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-12 14:36:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Manfred Hollstein 2002-04-06 08:29:17 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.18-0.13 i686)

Description of problem:
Configuring an ethernet device using redhat-config-network and selecting 'dhcp'
puts
a line 'PEERDNS=no' into the corresponding
/etc/sysconfig/network-scripts/ifcfg-eth0
file. This is especially bad, since it stops pump (or dhcpcd) from generating a
new
/etc/resolv.conf file based on the information received from the DHCP server.

Version-Release number of selected component (if applicable):
redhat-config-network-0.9.21-1


How reproducible:
Always

Steps to Reproduce:
1.Start redhat-config-network
2.Configure ethernet device using dhcp
3.Save changes
	

Actual Results:  The generated file contains named line, while it shouldn't.

Expected Results:  No such line should be generated, at least not until the user
is able to choose himself, if /etc/resolv.conf should be generated or not, ie.
if
PEERDNS=no|yes should be emitted.

Additional info:

This is bad for mostly laptop users who are connecting to different DHCP
servers.
While the first boot after an installation will most likely succeed, any further
attempt
using a *different* DHCP server will fail, because it's unlikely that the
nameserver,
whose address had been emitted into /etc/resolv.conf during the first boot, is
still
accessible.
Comment 1 Harald Hoyer 2002-04-08 08:04:55 EDT
already fixed in CVS. Wait for 0.9.23.
Comment 2 Harald Hoyer 2002-04-08 08:06:23 EDT
*** Bug 62946 has been marked as a duplicate of this bug. ***
Comment 3 Trond Eivind Glomsrxd 2002-04-11 20:35:36 EDT
Is this stil a problem with version 0.9.24 at http://people.redhat.com/teg/neat/ ?
Comment 4 Manfred Hollstein 2002-04-12 14:36:09 EDT
Works perfectly now!

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