Quoth Darren.Reed at sun.com on Fri, Oct 27, 2006 at 04:04:14PM -0700: > David Bustos wrote: > >Quoth Darren.Reed at sun.com on Thu, Oct 26, 2006 at 07:54:16PM -0700: > >>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! > > I'm not sure I buy that and after getting used to using svcadm > to manage everything (there is a nice amount of symmetry there), > it doesn't seem at all right to have some services (or eventually > all of them?) defacto-managed by the other tools.
The point is not to obsolete svcadm, but to allow the developer to avoid presenting an accidental user interface when it doesn't make sense. > Regardless of whether or not there are shares defined in the > /etc/dfs/dfstab file, "svcadm disable nfs/server" should still > turn off NFS file serving - preferably without altering the > contents of that file. To be required to use unshare is not > at all admin friendly. I agree that that would be ideal. But the SMF framework doesn't support that model right now. And the NFS team has chosen to stop their daemons when there are no shares. Saying that SMF shouldn't accommodate such a model is fine, but it doesn't address the broader issue of configuration consistency. > >I'm pretty sure altering the state machine is out of the question here. > > Is it fixed for good or are there possibilities it could be > expanded upon in the future? > > Or more to the point, why not alter the state machine to try > and better fit the model for services? > > It kind of feels like the design was modeled around services > being either "black" (disabled) or "white" (enabled), ignoring > the "grey" areas inbetween, so we're stuck trying to make > everything "black" or "white" rather than trying to find more > colour and depth in investigating the "grey" areas. The state machine is limited to avoid forcing complexity onto clients that just want to know whether a service is ready. We do provide a mechanism to express more information about a particular state via "auxiliary state". That's how svcs -x knows how/why a service failed. Use of auxiliary state is pretty limited right now, though. > >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. > > If it gets into the maintenance state via this path then it > should also be going that way if I do "svcadm enable nfs/server" > without having any active lines prepared by share(1M). I don't > see the two states as being any different. Sure they are: one was the result of the invocation of a commmand, where we have an opportunity to stop the administrator and help him. The other was a configuration error lying in wait that we discover during boot, so all we can do is put the service in maintenance and let the administrator try to debug it when he finds that NFS isn't working. > If I had any argument with respect to nfs/server, I'd say that > the NFS group are not heading in the right direction here. > > The work flow I expect to have when enabling NFS shares is: > - enable service > - verify service is enabled/running > - share some filesystems > - verify filesystems are exported correctly > > With SMF it has become: > - share some filesystems > - verify service is enabled/running > - verify filesystems are exported correctly > > The subtle difference here is that the NFS server is not > a single daemon, but a combination of both exporting the > filesystem and performing the I/O operations. Maybe I'm > just old fashioned in wanting to confirm that daemons are > up and running and configured properly before starting > to share filesystems. I agree with you, and I think the alternative model would probably have been easier to support (or at least a more natural fit) with SMF. But I don't think that's an argument for developers never wanting to enforce consistency in configuration, so we should come up with a generic way & administrator-friendly way to support that. David
