Red Hat Bugzilla – Bug 126637
DHCP lease renewals overwrite /etc/resolv.conf thereby throwing away nameservers needed by VPN
Last modified: 2007-11-30 17:10:45 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 Description of problem: I am using Redhat linux 9 running on IBM Thinkpad T21. I connect to the Internet through DHCP. In addition, I setup a VPN connection to my office (using pptpconfig). The VPN requires me to put additional nameservers in my /etc/resolv.conf. The problem is that periodically, the dhcpclient overwrites the /etc/resolv.conf file when it renews its lease. This throws away the nameservers needed by my VPN connection (these are put in /etc/resolv.conf by pptpconfig when the VPN is set up). So everytime my Redhat linux box renews its dhcp lease, I have to manually edit /etc/resolv.conf and put the VPN related nameservers there. Please fix. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Setup dhcp over a network interface 2. Add some additional nameservers into /etc/resolv.conf manually 3. Everytime dhcp renews its lease, /etc/resolv.conf gets overwritten, thus throwing away the nameservers that were manually added. Actual Results: /etc/resolv.conf gets overwritten everytime dhcp lease is renewed. Expected Results: /etc/resolv.conf should retain the nameservers that were put additionally. Additional info:
Why are reporting a Redhat linux 9 "bug" to fedora core 2? I don't know about dhcpclient but for dhclient there is a configuration file called dhclient.conf where you can adjust the behaviour of dhclient to your needs. Maybe the supersede / prepend statements in combination with domain-name-servers could keep dhclient from or restore the values for your name servers. Maybe you could configure the DHCP server not to provide values the DHCP client does not need. So, is this a bug at all?
I'm reporting the bug against Fedora core 2 because I didn't find "Redhat Linux" in the list of options that bugzilla offered. I thought Fedora probably inherited the bug, so filed against that. The other close option was "Redhat Enterprise Linux" - I believe that's not a free version anymore - so decided against filing on that. I've checked the dhcpclient.conf man page. Notice that my dhcp client needs the nameserver information from the router the first time. But on lease renewal, it doesn't need that information. There doesn't seem to be a way to specify this. I believe the default behavior of dhcpclient should be such as to not overwrite /etc/resolv.conf if the lease renewal doesn't change any of the earlier parameters.
I don't think that dhcpclient overwrites resolv.conf. In the case of dhclient it's dhclient-script that updates resolv.conf. The man page for dhclient-script states: >This script is not meant to be customized by the end user. If local >customizations are needed, they should be possible using the enter and >exit hooks provided (see HOOKS for details). These hooks will allow >the user to override the default behaviour of the client in creating a >/etc/resolv.conf file. Hope this helps.
I can certainly put a shell script in /etc/dhclient-enter-hooks that overrides the default behavior of overwriting /etc/resolv.conf. However, the reason I've filed this bug is to help Linux become more usable towards an ordinary user who doesn't know how to write shell scripts and/or such deep system level details. It'll be nice if such common ways to change the behavior of the dhclient-script are already provided.
The situation u describe is mentioned in the man page of dhclient-script as well, so maybe u can either help yourself using your skills or wait for a new version of dhclient-script. There is no point in filing this bug which is even mentioned in the man page, is there? dhclient-script BUGS If more than one interface is being used, there's no obvious way to void clashes between server-supplied configuration parameters - for example, the stock dhclient-script rewrites /etc/resolv.conf. If more than one interface is being configured, /etc/resolv.conf will be repeatedly initialized to the values provided by one server, and then the other. Assuming the information provided by both servers is valid, this shouldn't cause any real problems, but it could be confusing.
It might be true that the man page of dhclient-script mentions the bug. However, unless someone reports problems, it is not going to be fixed at a high priority. In addition, the man page is biased in thinking thatit won't "cause any real problems". The issue is, for people using VPN over a dhcp interface, this is a real problem. Many more people are likely to be using VPN over an interface than two separate interfaces.I don't think the man page recognizes that. I'll appreciate if this bug can be left open so it is fixed at a higher priority than otherwise. Please recognize that it is bugs such as these that prevent Linux from becoming more accessible to non-geeks.
The reason why I spent my time with your problem was that you gave the impression of being lost: >So everytime my Redhat linux box renews its dhcp lease, I have to >manually edit /etc/resolv.conf That's why I mentioned how you can configure dhclient-script to match your needs. Sorry for not having realized immediately that you were an expert trying to save the non geeks.
With dhclient-3.0.1-+ (current version) you can add this line to /etc/dhclient-${interface}.conf (eg. /etc/dhclient-eth0.conf if the interface being configured with DHCP is eth0) : ' prepend domain-name-servers ns1.myvpn.com ns2.myvpn.com; ' This will add the nameservers ns1.myvpn.com ns2.myvpn.com to the beginning of the list of nameservers retrieved from DHCP - or ' append domain-name-servers ns1.myvpn.com ns2.myvpn.com; ' to add them at the end; or ' supersede domain-name-servers ns1.myvpn.com ns2.myvpn.com; ' to replace the nameservers supplied by DHCP server entirely. I hope this helps.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-566.html