Kacheong Poon writes: > James Carlson wrote: > > > Perhaps I'm lost here, but I thought that milestone/single-user > > depends on milestone/network. Hence, if one of those things is > > waiting for a long time, the system just plain hangs. There's little > > useful work that can be done here. > > > I think this was changed in Jan's proposal as NWAM > is supposed to work in single user mode and milestone/ > network is not required.
OK. > > I'm still uncomfortable with having SMF states that can hang waiting > > on activity that's outside of the local system. It makes some sense > > in some very narrow cases (e.g., no sense proceeding if you can't > > mount /usr because it's on a SAN and the interfaces for the SAN aren't > > running), but seems incorrect in general. > > > Well, if "network is the computer :-)" waiting for > the network seems natural ;-) Maybe in future, > all storage will be NAS. The problem is that not *all* instances of Solaris are enslaved to the network. It's common on the SWAN, but the SWAN is an unusual environment in many regards. (Resolving host names through NIS is a nice touch, I think.) This is thus a configuration issue, not an underlying dependency issue. > >> No, I don't believe the intention of milestone/network is > >> about plumbing interface. It is about outside IP connectivity. > > > > OK, then, "plumbed and somehow configured." > > > I guess no. I don't think "plumbed and somehow > configured" implies external IP network connectivity. Then what does? > > Nope. xntpd works fine with attached local clocks. > > > I suppose this is not what most customers expect xntpd > to work... It depends on the customer, then. xntpd does work that way, whether "most" customers understand it or not. > > You know this precisely when you receive packets from those nodes that > > are in response to packets you've sent. You don't know it at any > > other time. > > > This is why I said NWAM can detect "simple external IP > network connectivity." No, it _can't_. There's just no good way for NWAM to know whether (say) "mount -F nfs foobar:/ /foobar" is going to work in the future. The only way to know is to try it out. The services you need in order to do whatever it is you're trying to do may not necessarily be "simple." By "simple," I think you're assuming that if we get Ethernet link up, and we're able to get a static or DHCP-supplied address, and perhaps even a magic "default route" from somewhere, then everything is fine. Right? That's just not the case. Having a route doesn't mean that the router you're pointing to is actually functioning. Knowing the server address that you need doesn't indicate that the server itself is reachable or running the service you need. Having the Ethernet link up doesn't mean that the local switch is done with STP and now passing packets. In fact, none of these tests really works, so I don't see why we're trying to make them. > > I think diagnosis of networking faults is a separate topic from the > > matter of configuring and using network interfaces. > > > I guess diagnosing network problem is probably a super set > of detecting network connectivity (well, simple network > connectivity in the sense that the machine can talk to > locally connected peers). I'm not so sure that's true, but ok. > But we are not concerned about > diagnosing network problems in general. Agreed. > > - User needs to have some routes, but doesn't know how to make the > > system add them. User can reach some hosts, but not others. > > > But will customers expect milestone/network to mean that there > is no such issue? I can't tell. If you're expecting milestone/network to mean that you can reach the servers you need to reach, then yes, this is a problem. If you're expecting it to just mean that you can send packets that are dropped because either the local system is misconfigured (bad next hop on the route) or the rest of the network isn't running, then that'd be fine. Except that such a milestone seems unusable to me. > But I don't see why the above issues are related to the > current problem we are discussing. We need to define the > meaning of milestone/network and then decide if it is > actually a useful state for a machine. Agreed; they're unrelated. I mentioned them because you brought up diagnosing network problems, not because I wanted to talk about it. > >> I guess the basic question is whether external IP connectivity > >> is a useful state of the machine such that we need to make it > >> a milestone for other network services to depend on, both for > >> backward compatibility and for future usage. Comment? > > > > Given that it's something that I don't think we can in fact assert to > > be true, I don't think we should have such a state. > > > Suppose a machine can ping a router, and ping a host in > the same sub network, is it sufficient for most customers > that the machine has external IP connectivity? It sounds like a meaningless question to me. Suppose you can ping your NFS server, but the mount command hangs. Are you going to complain that ping didn't give you the answer you wanted? What exactly is true when ping is able to return success that wasn't true before? Why is it important to keep some service (any service) from running before ping <some-arbitrary-address> succeeds? -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
