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

[Jason Vas Dias <jvdias redhat com>]

On Mon, 2005-04-11 at 15:27, Simon Kelley wrote:
> Jason Vas Dias wrote:
> 
> > 
> >>>. 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:
> > 
> > 
> 
> Maybe because ISC dhclient uses Linux Packet Filter for raw net access 
Yes, it does.
> then it can work with a down interface: using AF_PACKET needs the 
> interface up (but not configured with an IP address, even 0.0.0.0).
> 
> >>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.
> 
> Up, but with no IP address set is fine for all, I think.
> 
> 
> > 
> > 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.
> 
> How does this fit with Vendor-class options (DHCP option 43 and 60), 
> where the "option space ID" is a string?
> 
> > 
> >    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.
> 
> I forsee a problem with the "all options" calls: I think that setting 
> the "requested options" in a DHCP request to "everything" could easily 
> result in a reply which overflows a DHCP packet (they are only 500 bytes 
> or so) It might be better just to have the "get single option" methods, 
> and generate DHCPINFORM queries to get the values of options from the 
> DHCP server as and when needed.
> 

It is not intended to modify the DHCP-Server <-> DHCP-Client protocol 
at all.

The existing ISC dhclient will be used. dhclient encodes all options
into the environment of the program it executes with the '-s' option
to perform configuration actions on each state change.

> 
> > 
> >        ( 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.
> 
> 
> Please could I see that as soon as you feel happy to release it? I'm 
> currently struggling with the DBUS API (or rather the docs, incomplete, 
> out of date, yadda yadda) so ready done code that implements a defined 
> DBUS interface would really help me.
> 
Yes, I found it so, too. I'll be submitting the code to FC4 by the end
of this week - I'll copy you on the email when I do so.
> >     
> > 
> > 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.
> 
> 
> Again, given that code I should be able to produce a revision of dnsmasq 
> to do the same job in fairly short order.
> 
Yes, but I think ISC BIND has had far more extensive testing, and
includes far more features, such as DNSSEC and IPv6 support, than
dnsmasq.  We don't want to ship multiple code sets that do the 
same job, and we want to ship code to do a given job that has had
the most testing and is the most performant and feature-rich. 

Running a NetworkManager based system should not restrict what you can
do with the system, ie. you should be able to provide a full featured
DNS server as well as support dynamic configuration of name resolution
with DHCP (current resolver / resolv.conf + named capabilities).

Also I think moving towards hot-configuration of BIND with a D-BUS 
configuration interface is the right way to go for BIND, which
is burdened by an over-complex text-based configuration file. 

Regards,
Jason.

> 
> Cheers,
> 
> Simon.