On Tuesday 01 April 2008 23:37:38 L. Gabriel Somlo wrote:
On Wed, Apr 02, 2008 at 12:14:14AM +0200, Denys Vlasenko wrote:
Imagine that I have *two* interfaces, both sit on DHCP configured
networks (*different* networks).
Here one deconfig-ed iface will happily nuke /etc/resolv.conf
On Wednesday 02 April 2008 02:58, L. Gabriel Somlo wrote:
I am thinking - maybe we should just junk the idea of default
options to ask for? We can ask user to always provide explicit
list of -O OPTs to ask. What do you think?
I agree. Although others might yell at us if we change default
L. Gabriel Somlo schrieb:
I am thinking - maybe we should just junk the idea of default
options to ask for? We can ask user to always provide explicit
list of -O OPTs to ask. What do you think?
I agree. Although others might yell at us if we change default
behavior :)
Please take a look
On Tuesday 01 April 2008 23:09, L. Gabriel Somlo wrote:
Last, but not least, a slightly more complex sample udhcpc.script,
which attempts to react to changes in parameters returned by the dhcp
server in a minimal-effort sort of way (i.e. don't reconfigure the
interface if the only change was
On Wed, Apr 02, 2008 at 12:14:14AM +0200, Denys Vlasenko wrote:
On Tuesday 01 April 2008 23:09, L. Gabriel Somlo wrote:
Last, but not least, a slightly more complex sample udhcpc.script,
which attempts to react to changes in parameters returned by the dhcp
server in a minimal-effort sort of
On Wednesday 02 April 2008 00:37, L. Gabriel Somlo wrote:
I agree with your no_ifup blurb in principle. However, this is not
about ifupdown at all (adding a way to pass no-default-options to
udhcpc from ifupdown was an afterthought since I happen to use
ifupdown, but totally unrelated to the
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
On Tuesday 01 April 2008 23:09, L. Gabriel Somlo wrote:
Denys All,
I noticed that udhcpc sends a default list of options in its request
(i.e., all options listed with flag OPTION_REQ in options.c)
That's bad, at least when used with some versions of isc dhcpd, which
will only include the
I am thinking - maybe we should just junk the idea of default
options to ask for? We can ask user to always provide explicit
list of -O OPTs to ask. What do you think?
I agree. Although others might yell at us if we change default
behavior :)
Please take a look at attached patch - will this
