Bug 51045 - the default resolv.conf is too static
Summary: the default resolv.conf is too static
Status: CLOSED DUPLICATE of bug 51081
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-network   
(Show other bugs)
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-06 21:19 UTC by Panic
Modified: 2015-03-05 01:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-06 22:29:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Panic 2001-08-06 21:19:40 UTC
Description of Problem:

neat writes the existing resolv.conf into the default Profile the first
time it runs.  This resolv.conf is then applied across the board even if
the interfaces are changed or receive a new DHCP configuration.  This is
probably a combination of the initscripts and neat's use of the default

An example of this is the resolv.conf is set once, and reappears even after
the machine has been moved and received a new DHCP configuration. 
Essentially, neat/initscripts is not allowing DHCP to do its job setting
the nameserver configuration.

How Reproducible:


Steps to Reproduce:
1. Start up neat, noting that the existing resolv.conf is copied into the
default profile.
2. now shut down, move the machine, get a new DHCP configuration.
3. Note that while the IP address is correct, the resolv.conf is the old
one from the previous configuration.

Actual Results:

resolv.conf becomes static.

Expected Results:

DHCP should be able to replace/modify resolv.conf as necessary, that is
part of its job.

Additional Information:

Comment 1 Panic 2001-08-06 21:38:21 UTC
An addendum to this bug -- I cannot make neat accept a DHCP delivered
resolv.conf at all.  Apparently, after a resolv.conf has been written to the
default profile, dhcpcd is always run with the flag that prevents the writing of
/etc/resolv.conf, even if no resolv.conf exists anywhere.

The only way to recover from this scenario is to run dhcpcd manually, get the
file in place in /etc/resolv.conf, delete the default resolv.conf, and then run
neat to copy the correct resolv.conf to the default profile.  This sets it again
for this setting, but you have to do this every time to get the correct
resolv.conf in place for each DHCP connection.

Comment 2 Glen Foster 2001-08-06 22:29:52 UTC
This defect is considered SHOULD-FIX for Fairfax.

Comment 3 Phil Knirsch 2001-08-07 11:49:31 UTC
This bug is related to the usernetctl problem and other tools who require the
files generated by neat not to be symlinks.

As we will switch to either hardlinks or to real copies of the files this should
be fixed in the next version as well.

I'll mark it as DUPLICATE of another symlink bug of neat, although it is only
similar, not the same...

Read ya, Phil

*** This bug has been marked as a duplicate of 51081 ***

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