Renee Danson writes: > On Thu, Feb 05, 2009 at 09:35:05AM -0500, James Carlson wrote: > > 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.
You can certainly list multiple server addresses for ypbind to use, and more is *definitely* better than less. It'll choose working ones from the list. (They're listed, one per line, in /var/yp/binding/$DOMAINNAME/ypservers.) What you can't do (currently) is operate in more than one NIS domain at a time, but I doubt that's very often an important consideration. In fact, it's probably closer to "mistake." > We still have the problem of deciding which server to make the default; > but I think there the important thing is to be consistent. Maybe. In many cases, when faced with multiple redundant servers, I don't actually care about either the default *or* about consistency. In fact, a little inconsistency is a good thing, as it increases the odds that in a busy network I'll end up using a lightly-loaded server. When I set up a system here, I don't really care whether I get mf-ubur-01.east or mf-ubur-02.east as my NIS server. They're equivalent. But it would be "bad" if every system I set up gets them listed in exactly the same order, because odds are that they'll all end up using the first one on the list. > 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!). Yes, the NIS domainname is a separate matter from the server. You can only have one NIS domain, and it does need to be somehow "consistent." If there's a GUI involved here, I'd suggest that seeing multiple domains offered would be a good reason to warn the user that something unusual is going on. > 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 guess. I'm still a little confused about why we're talking about "nameservices" in particular rather than more generally about "applications." DHCP configures a whole bunch of things, not just name services. But I guess I can stay this way. ;-} > I think > it is more flexible for future additions, and is a scheme that could expand > beyond name service config, as well. OK. > * [dns|nis|ldap]_nameservice_configsrc/enum list: possible values are DHCP and > MANUAL for dns and nis; only MANUAL for ldap. If we care about LDAP, we should probably be doing better here. There's a draft that describes how to do LDAP configuration with DHCP, but it's rotting away from inattention: http://www.ietf.org/internet-drafts/draft-gpaterno-dhcp-ldap-03.txt (Probably not your problem, but still ...) > 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. Tiny nit: DHCPINFORM is needed only if you have a static address. You shouldn't _ordinarily_ need to do that for interfaces that actually get their addresses from DHCP. -- 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
