Re: Late to the party - multiple search domains on the network.

[Peter Jones <pjones redhat com>]

On Mon, 2005-04-11 at 13:53 +0100, Simon Kelley wrote:

> . Query a configuration setting from the DHCP server. (using DHCPINFORM, 
> and cached.)

I think NM (or, rather, any program in the position of asking for a new
lease to be requested by the dhcp client, etc) should be the part doing
the caching here.

Only it can know which configuration settings should be queried, and
only it knows the semantics of how those config settings are used.  So
your dbus-aware dhcp client needs to either have a bunch of cache
manipulation functions, which aren't really important to dhcp but matter
to NM, or it can simply let the program with the logic do the caching.

> It will be the responsibility of the user of this interface to pass the 
> configuration information to the system, and act on it by setting 
> default routes, etc.

OK, that's good.

> The only part of the kernel's state which will be directly manipulated
> by the DHCP client will be interface address and up/down status. (This
> is because the client has to be sure that the interface will come down
> at the end of a lease, to keep the network stable.)

Is there a compelling reason it needs to be doing this management?  I
can think of scenarios where it would be useful and acceptable to have
the "UI" component doing this role as well -- in particular, failover
setups and VPNs.  NM doesn't do that stuff yet, but it will eventually
(hopefully) know how to handle VPNs.

It isn't very dangerous to let the dhcp client really _only_ do the dhcp
protocol speaking, and there are several cases where you really want it
not to change interface state _at all_.

-- 
        Peter