Red Hat Bugzilla – Bug 51045
the default resolv.conf is too static
Last modified: 2015-03-04 20:09:25 EST
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.
Steps to Reproduce:
1. Start up neat, noting that the existing resolv.conf is copied into the
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.
resolv.conf becomes static.
DHCP should be able to replace/modify resolv.conf as necessary, that is
part of its job.
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.
This defect is considered SHOULD-FIX for Fairfax.
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 ***