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

Dan Williams wrote:
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.

Ok, that's fine. Whatever invokes the DHCP client ensures that the interface is up first.

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

Check. More agreement.

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,

Yep, looks fine.

BTW, does NM keep persistent (over reboot) state about interfaces? The DHCP client needs to know the last address it got for an interface and the time the lease expires. It would be nice to delegate that to NM.

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.

This is my chance to evangelise dnsmasq again. Please consider it for this role, it's just what it's designed for and I'll add dbus support ASAP. Did I mention that dnsmasq would be perfect for this?

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

OK again.

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

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

That's a great start: a few random thoughts on how it might be better.

. Best to decouple the option space from the DHCP spec, and especially the DHCP option numbers. There are probably configuration items which don't map to DHCP well, and some DHCP options which don't have single option numbers. (for instance, the proposed DHCP spec for proxies lumps FTP, HTTP, SSL, SOCKS etc proxies under a single option number.) Also some configuration might come from other sources (PPP can supply DNS servers and default route, at least)

. An ideal system would accomodate DHCP "vendor specific options", basically private option spaces.

. There needs to a signal system to flag changes.

. A simple tag,value system might work best. There would be some "well known" tags for things like DNS servers which NM knows, but new tags would be usable without any changes to NM.

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.

We're thinking along very similar lines.........



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