Darren.Reed at Sun.COM wrote: > 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. > > 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. I also don't see any fundamental problem in attempting to start the service if there are no shares. Going back to disabled makes more sense to me than maintenance. Temporarily disabling of the NFS service is also something that needs to be done at times. While we will be adding the ability to do this via NFS related commands, there shouldn't be an issue with using svcadm to do it either since we still need boot time startup and shutdown to work. > > 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. > > 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. NFS doesn't have any problems with the current management of the state of the service. I'm not sure where this came from. What seemed potentially useful to us was if we could lock properties that were operational properties like the actual path to use since there are checks that must be done in order to have everything work correctly. There are also value ranges on properties that could inadvertantly be set to an inconsistent value if someone just changed them arbitrarily.
Doug
