Quoth Darren Reed on Fri, Dec 07, 2007 at 05:24:47PM +1100: > So if I understand this proposal correctly, the default > profile (with no services enabled) would not result in > rpc/bind being enabled. But when you choose a profile > that contains a more visible service (such as NFS or NIS), > the profile's definition requires that rpc/bind is turned on. > > From a macro perspective, this works but I'm not sure > if it really addresses the problem.
I suspect you didn't understand correctly. Enhanced SMF profiles are more than today's profiles. They will be used to organize and prioritize configuration information inside the SCF repository. I was saying that if rpc/bind has the "on-demand" property set, then when the framework noticed that a service which depends on rpc/bind is enabled, it would automatically enable rpc/bind. I proposed that it do so by setting the general/enabled property to true, in a profile (prioritization layer, if that helps) which is designated for system-dictated configuration. If the user wishes to override that choice, he may do so in a user-dicated profile, which always overrides the system profile. > I don't know if there are any other services that have the > same properties as rpc/bind here...as if I think about this > some more, I'd also like to see rpc/bind stopped if all of > its dependencies are also stopped - but that might be a > tad too "surprising" for an administrator . I don't think it's necessarily true that that would be surprising, as long as it was automatically enabled and the administrator hadn't expressed an override. The library/daemon paradigm is pretty common. libscf/svc.configd and libnsl/nscd come to mind. We don't have to worry about auto-starting the former because we do our best to keep it on all the time. I think that if we had auto-starting capability, nscd would use it, because if there are no name-service consumers, there's probably not much sense in devoting resources to nscd. Of course, svc.configd is usually a name-service consumer, so the point may be moot. > Does it make sense for the manifest of a service to have > a property that says "always do a recursive enable for > me if I get enabled"? (the "-t" option would need to be > propogated, if present.) Or does that defeat the purpopse > of being able to control recursion on the command line for > svcadm? I don't think that's the right way to solve this problem. The fact that rpcbind should be started if another service uses it is something decided by the rpcbind developers, since they chose to implement the library's functionality in a daemon. I think the real question is if we start taking this approach, how can we ensure that administrators don't mistakenly end up enabling services with undesirable security or other characteristics? Should this be left to higher-level interfaces? David
