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

[Dan Williams <dcbw redhat com>]

On Mon, 2005-04-11 at 16:29 +0100, Simon Kelley wrote:
> Dan Williams wrote:

BTW, Jason's email is jvdias redhat com, I'm cc-ing him here.

> . The DHCP client needs the interface to be up during the configuration 
> process so that it can send and receive packets. NM can't start with a 
> downed interface and ask the DHCP client to get it an address.

NM keeps _all_ interfaces up all the time, since unless the device is up
you cannot (a) detect link-change events via netlink sockets for wired
cards, and (b) perform wireless scans for wireless cards.  NM enforces
security on devices that are not the "active" device my ensuring that
those "inactive" devices have no IP address and do not show up in the
routing table.  So obviously, when NM requested the DHCP client to
perform a DHCP transaction, the interface would be up.

However, I don't think its unreasonable to ensure the device is "up"
before you perform the DHCP transaction, since the DHCP client would be
responding to a request to perform that exact transaction, either from
NetworkManager, some other daemon, or the command-line client.

> . Hosts which obtain a DHCP lease are making a strong promise to the 
> DHCP server that before the lease period expires, unless it's renewed, 
> they _will_ stop using the lease address. It makes me happier if the 
> DHCP client has sole responsibility for that - less to go wrong.

So the suggestion here is to broadcast a "LeaseExpiring" signal or
something 30s before the lease actually expires, let services like
NetworkManager do their own thing with the information, and if the
device is still up when the lease _actually_ expires, forcefully down
the device.  But you're still not going to be able to deal with
something else (even the user) who comes along and "ifup"s the device at
any time.  I guess the point is that you can _try_ to control the
device, but you have no guarantee that you actually get the results you
hope for.  This seems to be on of those perfectly valid situations where
the DHCP client needs to enforce policy (lease expires so you can't use
the address any more) and NetworkManager needs to enforce policy (can't
have arbitrary daemons up/down-ing devices without making NM aware of
the fact).

> Of course, ceasing to use a leased address and downing the interface are 
> two different things. Consider an interface which has two IP addresses, 
> one from DHCP and one locally allocated. If the DHCP lease expires, it's 
> necessary to remove the DHCP-allocated address, but the interface can 
> stay up and continue to use the locally allocated address.

In this case, a signal telling the bus that the DHCP configuration has
changed for some reason (ie renewal, rebind, lease-expiration, lease-
acquisition) would be the right thing to do.  In this case, when NM gets
that signal, it can re-read the device config data from the DHCP client,
and do what it needs to do (ie set up the device again, set nameservers,
etc).

One thing that Jason is going to do is to modify bind's caching
nameserver functionality to use dbus, so that apps won't have to fight
over /etc/resolv.conf any more.

> Probably the best approach would be that the DHCP client expects that 
> the interface is up when it gets asked to obtain a lease, and just 
> returns the address, without inserting it into the interface. If a DHCP 
> lease expires without being renewed,  the DHCP client should remove the 
> address from the interface (just to make _sure_ that it happened) and 
> signal NM that the address is no longer valid.

That would be best.  Remember, there are multiple "services" that need
to set information on the card, PPP clients, VPN clients, DHCP clients,
etc.  These should all be _independent_ of the actual service that sets
the hardware up, since they should in no way need explicit knowledge of
each other.  If they all talk to one independent service (ie
NetworkManager or something like that) then they do not need to care
about stepping on each other's toes.

(for example, you have a PPP connection that you then run a VPN client
on, they both technically need to modify /etc/resolv.conf, they both can
provide Proxy settings, etc.  A mess if they all try to do it
themselves).

> Does NetworkManager have a model for network connection-related 
> information? My take is that there should be a place on the D-bus where 
> anything running on the host can come to find out the address of the DNS 
> server, the NIS server, the NTP server, the HTTP proxy. All that 
> information is available (or soon will be) via DHCP, and it should be 
> possible to configure a machine to say

What NetworkManager currently does is provide a "DHCP Options" API via
dbus:

In python:
-----------------------
svc = 'org.freedesktop.NetworkManager'
op = "/org/freedesktop/NetworkManager/DhcpOptions"
ifc = "org.freedesktop.NetworkManager.DhcpOptions"

bus = dbus.Bus (dbus.Bus.TYPE_SYSTEM)
nm_service = bus.get_service (svc)
dhcpOptions = nm_service.get_object (op, ifc)
type = dhcpOptions.getType("NTP Servers")
ntp_servers = dhcpOptions.getInteger("NTP Servers")
-----------------------

You now end up with a python List of 32-bit integers representing the
IPv4 addresses of the NTP servers that the DHCP server passed back to
you.  (note: I tried it out and it looks like string matching is broken,
so you can use 42 in place of "NTP Servers" and get the correct result).

Something like this would be required, where clients can ask the DHCP
service/client for arbitrary options, and the DHCP service/client would
signal the bus that options were available.  For example, you can
imagine the following interaction:

NetworkManager->DHCP Service: "start transaction on eth0"
DHCP Service->NetworkManager: "transaction started with ID 34"
DHCP Service->System Bus (broadcast): "transaction 34 successful, lease
ID 34 acquired"
NetworkManager->DHCP Service: "give me IP address, nameservers, netmask"
NetworkManager: configures device and DNS information
<time passes>
DHCP Service->System Bus (broadcast): "T1 Renew failed"
<time passes>
DHCP Service->System Bus (broadcast): "T2 Rebind failed"
<time passes>
DHCP Service->System Bus (broadcast): "lease ID 34 about to expire"
NetworkManager->DHCP Service: "cancel lease ID 34"
DHCP Service: release address
DHCP Service->NetworkManager: "lease ID 34 cancelled"
NetworkManager: removes device config info, device routing table entries
NetworkManager->DHCP Service: "start transaction on eth1"
....

Something like that perhaps?  A mix of requests against the DHCP service
by NetworkManager, and general signals on the bus that shouldn't require
knowledge of the DHCP service's clients.

Dan