Quoth Darren.Reed at sun.com on Thu, Oct 26, 2006 at 07:54:16PM -0700: > David Bustos wrote: > >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" ?
The SMF group (or maybe just me) doesn't want the service to enter maintenance because it is better to front-load these errors than to silently accept the enable even though we can tell it will fail. > What does "svcs nfs/server" show when it is in the above state? > offline? *offline? or something else? In this case, when the nfs/server sevice is presumably disabled, the state would be disabled. But the important thing to note is that this proposal doesn't affect the state machine at all. It merely restricts the ability of general-purpose tools to modify properties. > 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. Sure, "locked" might not be the most user-friendly terminology. I think the most accurate thing to say would be that the general/enabled property is private / not public, but that seems worse. In any case, I'd like to debate the terminology after the core concept. > 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. That's the point! > > $ 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 point of this is that the locking mechanism is abided by svccfg as well. I'm not sure whether it should be enforced only be svcadm & svccfg because they are general purpose tools, or whether the mechanism should be driven down into the repository. The question in the latter case is how the repository should distinguish from svccfg trying to set properties and share(1M) trying to set properties. The Enhanced Profiles project may help 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? ... I'm pretty sure altering the state machine is out of the question here. > >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? :) Indeed, this does smell a lot like access control. But I think the key distinction is stability. svcadm goes around changing properties, even if the developer intends for the service to be private. > >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? Well I don't recall all of the details of the NFS services, but for the purposes of this argument, today I believe nfs/server would disable itself after you enabled it. share(1M) would then enable it along with its companion services. After reboot, I believe the NFS services would be started (because share(1M) enabled them), but they would discover that there are no shares (because you modified dfstab), and would disable themselves. With the locking feature, if you tried to enable nfs/server, svcadm would fail and say you should use share(1M). I think ideally the same would happen when you tried to edit dfstab, but I'm sure putting this feature into the filesystem is rife with landmines. Anyway, after reboot I would expect the NFS services to start but fall into maintenance, since them being enabled but no lines being in dfstab should be considered an inconsistent configuration, since share(1M) would never have done that. > 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.) Right. Again, this is really more about stability than access control. David
