From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: It would be nice if the network configuration gui would allow users to configure their nameserver / domain search path options with the dhcp-options 'prepend', 'append', or 'supersede' in /etc/dhclient-${interface}.conf - ie. /etc/dhclient-eth0.conf if eth0 is being configured with DHCP. Using these options, users can: 1. Change the search order for domains received from DHCP : ie. : 'prepend domain-name "devel.redhat.com ";' will add "devel.redhat.com" to the domain-name list received from DHCP at the start of the "search" path in /etc/resolv.conf when the dhclient-script writes it; while 'append domain-name " devel.redhat.com";' would add it at the end, and 'supersede domain-name "devel.redhat.com";' would replace the domain-name option received from the DHCP server entirely. 2. Change the domain-name-server list received from DHCP : ie. : 'prepend domain-name-server 127.0.0.1;' would make 127.0.0.1 be queried before nameservers recieved from DHCP. 'append domain-name-server 127.0.0.1;' would make 127.0.0.1 be queried after nameservers recieved from DHCP; and 'supersede domain-name-server 127.0.0.1;' replaces the nameservers returned by DHCP with 127.0.0.1. This would be very useful for users wishing to run a caching nameserver, or for those users who get DHCP from a public ISP but then need to connect to a VPN with private nameservers, or anyone who gets DHCP settings that conflict with local preferences. This would remove a source of many DHCP bugs and user confusion - eg. bug #126637, bug #106275, bug #111208 ... (more!). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Set your nameserver or search options in /etc/resolv.conf to your local preferences 2. Bring a up DHCP interface Actual Results: Your nameserver and search options in /etc/resolv.conf have been wiped out! Expected Results: If those local preferences had been specified in /etc/dhclient-${IF}.conf, they would have been retained. Additional info:
With an initscripts-7.66+ fix, dhclient will now use the generic /etc/dhclient.conf (non-interface specific) if /etc/dhclient-${IF}.conf is non-existent or empty - the generic /etc/dhclient.conf might be a more suitable place to put the prepend, append, supersede statements.
*** Bug 99464 has been marked as a duplicate of this bug. ***
Changing version to correct one. (test1 -> fc3test1, and some were filed as test3 accidentally instead; but clearly must be fc3test1 given the date of filing.)
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Fedora Core 3 and Fedora Core 4 are no longer supported. If you could retest this issue on a current release or on the latest development / test version, we would appreciate that. Otherwise, this bug will be marked as CANTFIX one month from now. Thanks for your help and for your patience.
On FC6 the config line: PEERDNS=no added to the relavent ifcfg- file prevents overwrite of /etc/resolv.conf. There is still a problem relating to default routes though as there is no similar mechanism relating to those. I can override the DHCP supplied route, but what I really want to do is just tell dhclient-script not to touch my current default route. Perhaps we might add a PEERDEFAULT=no option too? In fact, I think it can be argued that the behaviour is also wrong because I set my default route up as a static route and I can see no reason why the dhclient-script should touch it at all. If dhclient would have its own rtproto number then it could be designed to only remove or replace routes which have an rtproto of "kernel" or its own number. That would mean that it would play nicely with any other dymanic/static routing which might be in use. Should I start another bz or bump this one to FC6? I'm less worried about the GUI side of things (I always edit the config files directly), but there ought to be a suitable config option in the ifcfg file at least and the issue appears to be the same.
https://hosted.fedoraproject.org/projects/system-config-network/ticket/48