On Thu, Feb 12, 2009 at 08:01:31AM -0500, James Carlson wrote: > 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."
That's what I thought, too. But I've been told that you can actually bind to multiple domains. You must identify one domain as the default (shades of dhcp's primary interface), and that's the one all the libnsl lookup functions use; but the ypfoo commands all take a domain parameter (using the default if one is not specified). It's still quite likely that there could be cases where this is not the desired configuration. But--given the goal of automatic configuration-- it seems better to make do with what we're given that to say 'sorry, this doesn't make sense, I'm not going to do anything'. I would also like to think that we can improve on this in the future. As you suggest, an indicator in the UI that multiple domains were specified, and a way to select the desired one, would be excellent enhancements. > > 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. ;-} We're talking about nameservices in particular because that's a big thing people missed in phase 0/0.5. There's a seemingly infinite number of things that nwam can help configure; but we have to start somewhere. > > * [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. Yep, we should. But we can't in phase 1. > 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. Yes, I'd noticed that. So we'll either do normal DHCP lease acquisition, or a DHCPINFORM transaction. Question: In looking at these transactions in snoop, I see that dhcpagent asks for a list of parameters that does *not* include NISdmain or NISservs (on a solaris box with the default PARAM_REQUEST_LIST); but when I'm on swan, I still get those parameters from the DHCP server. Is it a case of "I'll give you at least what you ask for, and maybe more" from the server? -renee > > -- > 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
