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. > * 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. > * 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.) > * nameservices_config_file/string: specifies the file to be used for > nsswitch.conf. Must be specified if nameservices includes more than one > service. It makes a lot more sense to me to have policy applied here. For example, if I have a NIS server available to me, then I want "files nis" for most of the entries (except hosts and ipnodes). If I have DNS available, then I want to use "files dns" for hosts and ipnodes. Both, either, or neither might be active at any given time. (It'd be really nice if the name service switch were more robust and "just worked" when multiple things were configured, but this unfortunately does need to be managed today if the user is to avoid annoying and lengthy hangs when resolving through down services.) > * 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. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
