On Thu, 28 Jun 2007 11:06:37 -0400 James Carlson <[EMAIL PROTECTED]> wrote:
> Michael Hunter writes: > > http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/cmd-inet/usr.lib/inetd/inetd-upgrade.xml > > The fix is simple ... but I'm still pretty wary of the whole design. > > It seems wrong to me to have SMF dependencies that effectively stretch > outside the box, and that's exactly what the "name-service" dependency > does -- it tries to guarantee the impossible by saying that name > services are somehow "known" to be available for future requests. Yeap. As I noted on the bug (sadly the eval isn't public) nis is willing to slurp up a lot of bogus config and claim success when its just in the background "-broadcast". The whole concept of network services building long term assumptions based on initial SMF dependencies is seriously broken. > > What I think _should_ be happening here is something like this: > > - Inetd attempts to do each name resolution in some non-blocking > manner. In other words, either completion of the service itself > doesn't depend on finishing resolution, or, better yet, the > "attempting to resolve service name" state is reflected in the > state of each of the individual services -- rather than any > composite "I'm upgrading everything" service. > > - If name resolution for any service fails, then (after whatever > retries are appropriate) the specific service itself (rather than > "inetd-upgrade") is placed into maintenance state. > > - Somehow, we figure out how applications that are dependent on > external name resolution can and should keep up with external > changes. It shouldn't be necessary to restart the world in order > to deal with reconfiguration of the name server. What you suggest here is that we move the solution into the application. That seems heavy handed to me. The first part (non blocking name resolution) might be something that a small number of name resolution users want to use but to push that type of asycronous API onto everybody doesn't seem reasonable to me. Instead you could have a local name server that understand the policies used to choose type of name service to use, etc. All the local applications see this local name server as the only thing that exists and continue to survive as name services are changed, etc. I think something that the user could sit poll() blocked on would be my choice as it gets rid of the need for a special non-blocking API. But anything we could wrap an API around would work. > > I think we need a refactoring. This is wider then just name service although that is a big part of it. Unix code tends to swill away all kinds of information about the node its on, interfaces, etc. that is _usually_ stable. The socket API wasn't exactly designed to discourage this. But then when users try to build highly reliable system on top of this they are surprised when things break? But I don't think that type of refactoring is demanded by this bug. This is inetd-upgrade. It should run less often then the number of software installations that contain it. Its a conversion step from the old world into the new. Solving the bigger name service problem seems like a big hammer to demand to make this work a little better. mph > > -- > James Carlson, Solaris Networking <[EMAIL PROTECTED]> > 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 > _______________________________________________ > networking-discuss mailing list > [email protected] _______________________________________________ networking-discuss mailing list [email protected]
