Bug 51045 - the default resolv.conf is too static
the default resolv.conf is too static
Status: CLOSED DUPLICATE of bug 51081
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-network (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-06 17:19 EDT by Panic
Modified: 2015-03-04 20:09 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-06 18:29:56 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 Panic 2001-08-06 17:19:40 EDT
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
profile.

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:

Always

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 17:38:21 EDT
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 18:29:52 EDT
This defect is considered SHOULD-FIX for Fairfax.
Comment 3 Phil Knirsch 2001-08-07 07:49:31 EDT
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.