On Thu, Feb 05, 2009 at 09:35:05AM -0500, James Carlson wrote: > Renee Danson writes: > > I've tried to capture the discussions we've had today about how to handle > > nameservice discovery. The two central problems we hit today were: > > > > * if there are multiple interfaces up, from which one should we get the > > name service configuration data? > > Why "one?" > > On a multi-homed system, it's not unusual to find that you have useful > information on multiple interfaces. For example, being connected to > two subnets on the SWAN should give you access to multiple servers of > various sources (DNS, NIS, NTP). If you can't make use of redundant > information (in the cases where it's meaningful to do so), then you > lose out on some of your network resilience story.
The main concern we had about getting name service config info from multiple sources was how to merge the information in the case of NIS; we were not aware that you could bind to multiple servers. We still have the problem of deciding which server to make the default; but I think there the important thing is to be consistent. We'll likely use the ordering of IP NCUs, making the first NISdmain value we find on that list the default; the NCU ordering will be consistent across reboot, so the behavior will be deterministic (to the extent that the network data we get is deterministic!). > > * nameservice_discover/boolean: if true, nwam should apply ns config learned > > via dhcp > > I'm probably picking a nit, but I'm not sure I like the word > "discover" here. > > DHCP is an explicit configuration mechanism. The administrator sets > up the server with the names and addresses of network services, and > you're free to use them. You don't have to "discover" anything other > than the DHCP server itself, and that's not what this controls. > > To me, "discovery" means going out and looking for individual services > using some method peculiar to that service, rather than being told by > configuration where they are. Yes, I see your point (and yes, I do think it's a bit of a nit :-) ). The property goes away in my revised proposal below, so we'll simply avoid the issue... > > * nameservices/enum list: identifies name service(s) that should be > > configured. > > If discover is true, will only configure services that appear on this > > list, > > even if others have config info available. If nothing is specified, and > > discover is true, only one nameservice will be configured: whichever of > > nis, > > dns has info available via dhcp (in that priority order). > > I think there are multiple dimensions here. > > First, there's the issue of authoritative sources of configuration > information -- not just name services, but all things that can be > configured, such as print servers, time servers, and the like. It > seems likely to me that users will want to have control over where > configuration information comes from, without focussing narrowly on > each service. > > Today, that mechanism is the (in my opinion inadequate) "primary" > interface flag in dhcpagent. We should be able to do better. > > Then there's the issue of per-service controls, where policies might > be things like "ignore configuration; use service-specific discovery > mechanism" or "merge all configuration sources [useful for DNS]." > > Even if the first implementation of Phase 1 supports service > configuration for name services only, I think that the plan should > encompass all services that are configured in this way. (The list of > known DHCP options is a fairly good starting point.) I've revised the proposal to have per-nameservice properties like the address source properties in an IP NCU; thus the user can be very explicit about sources of configuration information for each nameservice they want set up. I think this is more aligned with what you're suggesting? I think it is more flexible for future additions, and is a scheme that could expand beyond name service config, as well. > > * if only one if is active, get ns info associated with that interface; > > else if nameservices_ifs is non-empty, try to get ns info from each if on > > that list in turn; else fail > > Please get information from all interfaces in parallel -- or, better > yet, as soon as the interface is configured. There shouldn't be any > serialized behavior in NWAM; it's a major failing in the old > (pre-NWAM) system. That was the plan in my earlier proposal (it specified a DHCPINFO exchange for each IP NCU when it was brought up), and remains the plan moving forward. This new proposal is based on both Jim's comments and some I received offline from a few security-conscious folks, who were concerned about NIS being automatically configured based on information received from the DHCP server. Please let me know what you think. -renee nameservice configuration properties: * nameservices/enum list: identifies name service(s) that should be configured. * nameservices_config_file/string: specifies the file to be used for nsswitch.conf. Must be specified if nameservices includes more than one service. * [dns|nis|ldap]_nameservice_configsrc/enum list: possible values are DHCP and MANUAL for dns and nis; only MANUAL for ldap. If (and only if) this property includes the value MANUAL, the next 2(3 for dns) properties will be used to configure the relevant name service. If this property includes the value DHCP, any configuration information received from DHCP will be used to configure the name service. If information is specified and received from multiple sources, it will be merged. * [dns|nis|ldap]_nameservice_domain/string list: domainname for the specified name service. Optional for dns; required for nis and ldap. * [dns|nis|ldap]_nameservice_servers/string list of ip address(es): address of the server for the specified name service. Required for dns and ldap; optional for nis. * dns_nameservice_search/string list: optional string values for the dns search property. plan: When an interface (ip ncu) is being plumbed, nwamd will do a DHCPINFORM transaction for all the ns properties (DNSdmain, DNSserv, NISdmain, NISservs). dhcpagent will cache this info. On location activation, for each nameservice specified in the nameservices property, the relevant configsrc property will be checked. If MANUAL is set, the relevant properties will be used; if DHCP is set, dhcpagent will be queried for relevant info which will be used. If information is obtained from more than one place (or if multiple values are received from DHCP), it will be merged (multiple search entries in resolv.conf, binds to multiple nis domains). The Automatic location will use dns, with configuration obtained from DHCP; this will be specified by the following property values: nameservices=DNS nameservices_config_file=/etc/nsswitch.dns dns_nameservice_configsrc=DHCP
