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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]