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

[Simon Kelley <simon thekelleys org uk>]

Peter Jones wrote:
> 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.

Think of the configuration settings in the DHCP server as a read-only 
database, and the DHCP client doing queries on that database on behalf 
of NM and others. All I plan to do is for the DHCP client to keep a 
record that "I already asked the server for the value of <foo>, so I 
don't need to ask it again, I'll just return the same answer." This is a 
bit of protection for the DHCP server (a network shared resource) 
against abusive clients which ask for the same thing repeatedly. It's 
completely transparent to the users of the DHCP client. A little 
optimisation.

The cache would be flushed when DHCP leases are renewed, to avoid stale 
data, since the configuration might not be _completely_ imutable.

> > 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_.

I think later in the thread, we came to the conclusion that interface 
manipulation could be left to NM, with the exception of a fail-safe to 
ensure that an address is removed by the DHCP client when a lease 
expires and is not renewed.


Cheers,

Simon.