David Bustos wrote: >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 > $ >
I think I share some of your concerns about the way to fully enable the service being outside of SMF. Is there a reason why the NFS group doesn't want nfs/server to enter into "maintenance" mode or is that implied by it being "locked" ? What does "svcs nfs/server" show when it is in the above state? offline? *offline? or something else? Mt gut instinct on seeing "default is locked" is to search for a "svcadm unlock" (or "share unlock" or similar) command... the message and requirement to use "share(1M)" given that message doesn't seem intuitive. The term "locked" also implies that until that problem is fixed that you can't do anything with the service - which may be a bridge too far. For example, if part of fixing the service was to use svccfg to change some property, that would seriously clash with what I'd consider intuitive when it says the service is "locked". Oh and the message as given could also be taken to mean that you're not meant to use svcadm, at all, with nfs/server. > $ 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 > $ > This looks like an implementation detail (of the above) and is interesting by itself, but maybe it just needs to be presented in a better way by svcadm? >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. > Why not just have another state for the service such as pending? online = configured & running "properly" offline = turned off and not running *offline = tried to go online but there was an error pending = going online is pending missing details appearing ...call it SMF_EXIT_PENDING? I also like the name "pending" better than "locked" as it doesn't automatically imply any sort of verb to fix the situation. When I think of a message that says: Error: svc:/network/nfs/server:default is pending. my reaction is to ask "what is it pending" rather than to think "how do I make it unpending" or similar. >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? > Hmmm, read-only as well as read-write properties in SMF? That sounds juicey :) ACLs on those too? :) >Or does it only make sense to lock >an entire service? > I think the problem here is not the value of the property, per se, but rather the state of the service itself. Using the above, if I was to enable nfs/server, use share(1M) to share a filesystem, edit /etc/dfs/dfstab to remove the line added by share(1M) and then reboot, into what state does nfs/server return to? Or if I edit that file thus and restart the service? online, offline, maintainance mode or locked? An important point to remember here is that whatever privileges the developer might have or use in changing the service is going to be no greater than that of "root", so there is nothing they can do that root can't (except cause annoyance and swearing as the system admin tries to work out what's wrong at 3am when their pager has gone off and it is something they've never seen before.) Hope his helps? Darren
