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

[Jason Vas Dias <jvdias redhat com>]

On Mon, 2005-04-11 at 12:07, 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.
> 
Thanks Dan!

> > . 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.
> 
Actually, the ISC DHCP client does not have this requirement -
it will manage DHCP sessions for interfaces that are unconfigured
and down - but it appears NM does:

> 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, 

This is not required by DHCP - dhclient only uses the ethernet address
to send DHCPDISCOVER packets, the IP address can be all zeros.

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

Here is an outline on what I am currently implementing -
comments / ideas / suggestions appreciated:

1. The 'com.redhat.dhcp' D-BUS service on the system bus, will implement
   the '/com/redhat/dhcp' object, and be provided by the dhcdbd 
   executable from the rpm of that name.

   This will manage all ISC dhclient sessions, and provide D-BUS objects
   representing all the DHCP options for each interface.

   It will provide "interface" objects representing all the interfaces,
   and objects for each dhcp option under these interfaces.

   The dhcp service will provide these D-BUS objects, interface
   interfaces and methods:

   Interface Up / Down Methods:

   Object:    /com/redhat/dhcp/{$IP_INTERFACE_NAME}
   Methods:   /{up,down}( IN integer flags )   
   Interface: com.redhat.dhcp.action
   
   So to initiate a dhcp session on eth0, you'd invoke the  
   "up" method on the "/com/redhat/dhcp/eth0" object with the 
   "com.redhat.dhcp.action" interface.

   If the interface object did not exist yet, it would be created
   if a matching interface name was found. If it did exist 
   (implying a session had already been initiated), the "down"
   method would be implied, meaning that any existing dhclient 
   session would be shutdown before a new one was initiated.
   The "down" method would shutdown the dhclient session and
   remove all options explicitly. 

   The up and down methods would accept one integer argument
   have these flags, currently implemented by corresponding
   option variables in network-scripts:
    1: PERSISTENT - dhclient should not give up trying to 
                    contact a DHCP server that does not respond, 
	            but should retry after a sleep interval
    2: RELEASE -    a down() should release the lease 

   dhcpdbd would then send signals from the 
   /com/redhat/dhcp/{$IP_INTERFACE_NAME} object with the
   "com.redhat.dhcp.state" interface for each dhclient 
   state change. 
   Each '/com/redhat/dhcp/{$IP_INTERFACE_NAME}/state' signal would     
   contain tstate code (integer) and name (string) parameters :
   { "PREINIT",    1 }, /* initial state: configuration session started - no options valid    */
   { "BOUND",      2 }, /* lease obtained - options valid  */
   { "RENEW",      3 }, /* lease renewed  - options valid  */
   { "REBOOT",     4 }, /* have valid lease, but now obtained a different one  - options valid */
   { "REBIND",     5 }, /* new, different lease  - options valid  */
   { "STOP"  ,     6 }, /* remove old lease  - only "old/" options valid */
   { "MEDIUM",     7 }, /* media selection begun - (unused)- no options valid */
   { "TIMEOUT",    8 }, /* timed out contacting DHCP server - no options valid  */
   { "FAIL",       9 }, /* all attempts to contact server timed out, sleeping - no options valid   */
   { "EXPIRE",    10 }, /* lease has expired, renewing  - only 'old/' options valid  */
   { "RELEASE",   11 }, /* releasing lease  - only 'old/' options valid */
   { "REVERT",    12 }  /* After TIMEOUT, settings reverted to last valid lease - options valid*/
     
   The dhcdbd service would try to guarantee that a PREINIT or FAIL signal
   will be generated within 1 second of a up/down request being received.
 
   Options methods:
  
   Common "Option Definition" structure:
       { uint8t universe;    // option space ID
         uint8t code;        // code unique within option space
         string name;        // option name
         string type;        // DHCP or D-BUS type string
       };

   Users can define new option spaces, or redefine / declare new
   options in existing option spaces in dhcp configuration files,
   so different options  may be implemented at different sites.

   Objects: /com/redhat/dhcp          // Interface list on Get interface
	    /com/redhat/dhcp/options  // Global Options Definitions
	    /com/redhat/dhcp/${IP INTERFACE NAME}/{$OPTION NAME}
                                      // current option set for interface
            /com/redhat/dhcp/${IP INTERFACE NAME}/old/{$OPTION NAME}
	                              // previous set of options for interface

   /com/redhat/dhcp/options        // Global Options Definitions methods:
   Methods: Option get ( void );   // returns array of all 
                                   // known options
	    Option get( string option_name ); 
                                   // returns named option 
                                   // (universe names can prefix option 
                                   // names separated by '.'.
	    Option get( uint8_t universe; uint8_t option_code ) ; 
                                   // returns option with option_code in universe 
            
            
   Option Interfaces:
            com.redhat.dhcp.binary:
               gets / sets data from / to binary structures
            com.redhat.dhcp.text:
               gets / sets data from / to text strings
            com.redhat.dhcp.dbus.text:
            com.redhat.dhcp.dbus.binary:
               translates DHCP option type strings into 
               D-BUS type strings   
   
   So, for example, the calls:

       ( Object:    /com/redhat/dhcp/options
         Method:    get
         interface: com.redhat.dhcp.dbus.binary
	 arguments: none
       ) 
       would return all option definitions known to the system
       with type strings in dbus format.
  
       ( Object:   /com/redhat/dhcp
         Method:   Get
         interface:com.redhat.dhcp.text
	 arguments: none
       ) 
       would return a list of all interface names currently configured 
       with DHCP.
 
       ( Object:   /com/redhat/dhcp/${IP_INTERFACE_NAME}
         Method:   Get
         interface:com.redhat.dhcp.text
	 arguments: none
       )
       would return an array of all options for interface
       with all values converted to text - ie. an array
       of structures:
       { string universe; string code; string name; string type; string value;}
       
       ( Object:   /com/redhat/dhcp/${IP_INTERFACE_NAME}
         Method:   Get
         interface:com.redhat.dhcp.binary
	 arguments: none
       )
       would return an array of all options for interface
       with all values in binary format
       { uint8_t universe; uint8_t code; string name; string type; uint8_t value[n]; }
       where "uint8_t value[n]" is the unique binary structure 
       corresponding to the type string.

       ( Object:   /com/redhat/dhcp/${IP_INTERFACE_NAME}/${OPTION}
         Method:   Get
         interface:com.redhat.dhcp.binary
	 arguments: none
       )
       would return the binary value corresponding to option named 
       ${OPTION} for the interface ${IP_INTERFACE_NAME}.
  
       ( Object:   /com/redhat/dhcp/${IP_INTERFACE_NAME}/${OPTION}
         Method:   Get
         interface:com.redhat.dhcp.text
	 arguments: none
       )
       would return the text string corresponding to option named 
       ${OPTION} for the interface ${IP_INTERFACE_NAME}.
       
  The options would be set by the program executed for each state change
  by the ISC dhclient (currently /sbin/dhclient-script, using dbus-send),
  using an authentication mechanism that guaranteed that only that program,
  a direct child of the dhclient process that is a direct child of dhcdbd,
  would be allowed to make the setting. No options would become valid 
  (the state change signal sent) until ALL options settings were sent and
  processed. 
 
  The initial version of dhcdbd will be complete in a few days and ready 
  to submit by the end of this week.
    

2. BIND D-BUS extensions :
  A subpackage of BIND, 'named_dbd', will contain a version of the named
  daemon of that name, compiled with extensions to support configuration of
  "forwarding zones" providing the 'com.redhat.bind' service on the D-BUS
  system bus.

  named_dbd would start up using its normal $ROOTDIR/etc/named.conf configuration
  file, by default consisting of a caching-only nameserver but also optionally
  containing authoritative zones - this file would not be changed automatically
  by any software (except system-config-bind).

  Forwarding zones could be created ONLY via a D-BUS interface by authorised
  processes acting on these objects:
  /com/redhat/bind/${ORIGIN}
  /com/redhat/bind/${ORIGIN}/forwarders
  /com/redhat/bind/${ORIGIN}/search
  where $ORIGIN is a forward (eg. 'redhat.com.') or reverse 
  ( eg. '80.16.172.in-addr.arpa.', 'd.a.e.d.1.0.0.2.ip6.arpa.') 
  DNS zone origin name .
  There would be "get" and "set" methods for each of the above objects; only
  certain authorized processes would be allowed to use the set methods.

  The D-BUS interface would be provided by a separate thread in named, so
  query performance should not suffer, except when processing a set, when
  mutual exclusive access to the configuration for forwarding zones will have 
  to be implemented.

  Each forwarding zone will consist of a domain name (forward or reverse) and 
  a list of "forwarder" name server IPv4 or IPv6 addresses to which queries
  for that zone will be addressed. 
  
  For forward "forwarding" zones (ONLY!), a  search list could also be specified
  that would be applied to all queries of that zone in the same way the resolver
  library applies to all queries.
	
  Thus resolv.conf should be completely empty - the resolver library would append '.' 
  to every name. Named would append each member of the search search list to the name,
  and return the first positive result for the name suffixed with the lowest ordered
  member of the search list. 

  This named extension I hope to complete by the end of next week.