Quoth Darren Reed on Mon, Dec 03, 2007 at 10:59:40PM -0800: > The service here in question is svc:/network/rpc/bind. Ideally > that service should never need to run *unless* there is something > that uses SunRPC. > > So upon booting, the service would be "offline" and there would > be no explicit node in the SMF dependency tree that pointed to > it being enabled. Only when SMF went to start something like > svc:/network/rpc/keyserv, it would look at the list of things that > this wanted, notice that svc:/network/rpc/bind was not online and > bring that online. > > I suppose that kind of implicit knowledge being placed in services > and not easily visible could be a dangerous thing and make it > harder to diagnose faults (among other things.) Are there other > caveats I'm missing here?
- Should the administrator be allowed to enable or disable rpc/bind explicitly? If so, how? Presuming 'yes', I think this and the visibility issue can be addressed by the functionality proposed by the enhanced SMF profiles project. That is, implicit enable of rpc/bind:default can be represented by a profile which enables the service in the "system" precedence level. The SMF tools should allow the administrator to determine that the service had been enabled in the "system" precedence level, and also to override that setting by placing a customization in the "admin" precedence level. I imagine that the profile would be maintained by the framework, in response to an "on-demand" property in rpc/bind. It could create a corresponding condition signifying "rpc/bind should be enabled", which would allow the administrator to predict the configuration change, and override it under particular conditions. - svc:/milestone/multi-user:default depends on rpc/bind. Presumably this dependency should be distinguished so as not to trigger on-demand behavior. Perhaps the fact that the dependency is of type "optional_all" is sufficient. David
