Bug 483257 - resolv.conf rewritten even though PEERDNS=no
resolv.conf rewritten even though PEERDNS=no
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-01-30 10:22 EST by Jonathan Kamens
Modified: 2014-03-31 13:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-16 16:26:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to /etc/sysconfig/network-scripts/network-functions (1.09 KB, patch)
2009-02-05 20:51 EST, Jonathan Kamens
no flags Details | Diff

  None (edit)
Description Jonathan Kamens 2009-01-30 10:22:56 EST
Updated this morning from Rawhide.  Rebooted.  /etc/resolv.conf was rewritten when my DHCP interface (eth0) was brought up, even though I have PEERDNS=no in /etc/sysconfig/network-scripts/ifcfg-eth0.
Comment 1 Jonathan Kamens 2009-02-05 20:50:59 EST
This really should have been an alpha blocker.  At the very least, it should be a beta blocker.  The problem is that the source_config function in /etc/sysconfig/network-scripts/network-functions is buggy -- it assumes that the config file name isn't an absolute path.  I will attach a patch which fixes this as well as does a number of other related clean-ups.
Comment 2 Jonathan Kamens 2009-02-05 20:51:25 EST
Created attachment 331078 [details]
patch to /etc/sysconfig/network-scripts/network-functions
Comment 3 Jonathan Kamens 2009-03-15 07:22:39 EDT
Hello?  Anybody there?  I filed this ticket over a month ago and even provided a patch, and yet nobody has done anything with it.  Surely breaking /etc/resolv.conf is a release blocker?
Comment 4 Bill Nottingham 2009-03-16 14:22:59 EDT
1) got busy with other things
2) it's not necessarily correct in that config files in random locations isn't really supposed to work. It could be easily fixed in dhclient-script too
3) it leads to the question of whether the PARENTCONFIG stuff there really is still needed
Comment 5 Jonathan Kamens 2009-03-16 14:28:35 EDT
Concerning (2), while my fix catered to the fact that there was all that weird code in the script to allow config files in random locations, that's not the bug I initially reported or fixed.  The bug is that even when the config files are all in the standard locations, dhclient changes resolv.conf even when PEERDNS is no.  This is surely a release blocker.
Comment 6 Bill Nottingham 2009-03-16 16:26:34 EDT
Sure, but while I'm looking at it, I'd like to get the whole thing right.


Will be in 8.91-1.

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