> SMF users and developers, > > What would you think about something like this: > > $ svcadm enable nfs/server > Error: svc:/network/nfs/server:default is locked. > Use share(1M) to administer this service. > $ echo $? > 1 > $ > > $ svccfg -s nfs/server:default > svc:/network/nfs/server:default> setprop general/enabled = true > Error: The general/enabled property is locked. > Use share(1M) to administer this service. > svc:/network/nfs/server> exit > $ > > The idea is that the NFS developers want to enforce NFS-specific > consistency between the general/enabled properties of the NFS services
I'm not in favor of this without a more explicit discussion about NFS's problems and how else they might be solved. I don't like this for the following reasons: - I'm concerned about it getting used everywhere as a way for not properly supporting smf semantics, e.g. not doing templates, not factoring properly - One of the major goals of SMF is to provide a programmatic and/or scriptable interface to higher-level frameworks: if anything can declare itself locked, then how is an admin script, profile, or higher-level framework supposed to operate on it at all? (i.e. the share(1M) command isn't scriptable in the same way, in that it doesn't support use at install/upgrade-time, etc) - There are two kinds of coordinated changes: interrelated properties, and interrelated services. Interrelated properties need to be handled by the service itself, its method, or constrained by the future templating features. Interrelated services are indeed tricky, but often if something is wrong here it suggests that perhaps the factoring hasn't been done right. So before we go add this, I'd like to see a detailed discussion of exactly what issue NFS is having and let's apply first principles to that. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
