> Alan Maguire writes: > > to support keep smf services/properties in sync with ndd variables, > > we'd need to ensure that ndd set writes the intended value to the smf > > property (in this case the general/enabled property i guess), as well as > > setting the kernel variable. > > Or it just means that it's high time we torched that bit of ndd > bogosity.
And all the rest of it, too :) Another comment here for this thread: Remember: SMF properties = administrator *intent*. They do *not* represent the actual state of the underlying objects as managed by whatever thing (e.g. the kernel) truly controls them. In other words, if I have a property in SMF which says "forwarding = disabled", that semantically means that when this service is started or refreshed, the administrator would like it to disable forwarding. It does *not* mean forwarding is actually, at this moment, disabled. You can always have some way of changing the actual abstraction without going through SMF. For example, I can whack the variable with mdb -kw ... and that surely isn't going to affect SMF. This is no different than the idea that, say, a service can be online from an SMF perspective, but pstop(1)'d from the kernel's perspective, and therefore not doing what it is supposed to be doing. So don't think of ndd and smf as the same thing -- ndd is conceptually syntactic sugar for mdb -kw, and is also a way of implementing the SMF methods. The SMF property set is a way of expressing intent as to how something should be configured according to admin intent and all the stuff that comes with that (persistence, security, upgrade), none of which were ever part of ndd. The issue with ndd as a command, which is an orthogonal issue, is that since it predated SMF, people think of it as the way to express admin intent because it was the only way to do so. My view is that problem is much more easily solved either by clear documentation or by removing ndd entirely. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
