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
(nfsd, statd, lockd, mountd, etc.) and with configuration outside the
repository (sharetab). Since the repository doesn't provide hooks for
the developer to execute code when a property changes (not that I'm
saying it should), the NFS developers provide the share(1M) command
which knows how to make coordinated changes. However, one of the
benefits of SMF is actually a problem here -- a standard way to enable
and disable services (svcadm) allows the user to make uncoordinated
changes, which could put the system into an unsupported configuration,
which not only might cause problems, but might cause problems that he
won't discover until later. So this would allow the NFS developers to
specify that the nfs/server service should be locked and to supply text
which user tools would print if a change is attempted (the bit about
share(1M), here).
I believe this is also a better way to solve the problem that
6245225 RFE: SMF_EXIT_DISABLE and SMF_EXIT_DISABLE_TEMPORARILY
was filed for. That is, if the developer knows that a service shouldn't
be enabled, then rather than having the enable operation succeed and the
service magically disable itself, the user should be prevented from
enabling it in the first place and redirected to the appropriate
interface.
One concern I have with this approach is that developers will be tempted
to declare their service as locked in the enabled state and not provide
an interface through which the administrator can disable the service.
This suggests that there should be a way to really override properties,
though it may require extra work (like a -f flag, or extra svccfg
commands).
A detail which isn't clear to me is the granularity at which this
mechanism should operate. Should the developer be allowed to lock
certain properties, but not others? Or does it only make sense to lock
an entire service? It seems that the latter would force an untenable
maintenance problem on the developer, since he would have to add ways to
change all of the properties of the service to the system-specific
interface, including SMF framework properties (like the privileges for
a method), which might grow in the future.
David
