PATCH: udhcpc -- don't request set of options by default

[Denys Vlasenko]

On Wednesday 02 April 2008 00:37, L. Gabriel Somlo wrote:
> In my udhcpc.script sample I declare an interface to be the "owner" of
> resolv.conf (e.g. PEERDNS_IF=eth0), and only when eth0 goes down does
> resolv.conf get nuked. Deconfig-ing eth1 doesn't do anything to
> resolv.conf.
> 
> This does have its own drawbacks, for sure, but we first need to have
> a rule about what what happens in this scenario:
> 
> - eth0 comes up
> - we request a dhcp lease, and receive back a bunch of stuff (e.g.
>   nameservers)
> - we populate /etc/resolv.conf with these nameservers
> - now, while eth0 stays up, eth1 comes up also
> - we request a dhcp lease for eth1, and receive back a bunch of stuff
>   (including a *different* set of nameservers)
> - ???
> 
> Do we overwrite resolv.conf, or do we add the new nameservers to the
> list (and if we add them, where, at the front or back of the list ?)
> 
> If we add them to the front, it's almost like we overwrote resolv.conf
> (the new nameserver gets queried for *everything* with precendence).
> If we add to the back, it's like we didn't overwrite resolv.conf at
> all (eth0's nameserver gets queried for *everything* with precedence).
> 
> So, what I'm trying to say, this is not really an ifupdown is
> bad/good/ugly problem, but rather "how do we reconcile information
> received via dhcp on multiple interfaces?"; My (yes, possibly flawed)
> answer was "hardcode a winner", but what's the right thing to do ?

To completely rewrite /etc/resolv.conf when either of eth0/1/99
changes state, taking in consideration the state of all links.
No appending, prependind or parsing of /etc/resolv.conf
is necessary. Just regenerate it. It should be possible,
because you have all necessary data to decide.

How to break ties is an admin task, and it's usually easy:
"I prefer eth3" or "I prefer ppp0".

However I can imagine some people will even want to set up
multipath routing if many links are up.
--
vda