Sowmini.Varadhan at Sun.COM wrote: > On (01/30/09 08:53), Darren Reed wrote: > >>> I'm not a networking person. I'm a systems administrator. I would humbly >>> suggest that involving systems administrators in these discussions would >>> be a good thing. >>> >>> So just for my own personal opinion, I do not want the model where >>> everything >>> I do is tagged as persistent. Non-persistent should be the default. If >>> I'm typing >>> commands, normally it's because I'm in experimental or debugging mode. If I >>> want to make persistent changes then I'll automate or script or just go >>> behind >>> the back of the commands and edit the config file. >>> >>> What *would* be really useful is a way of saying "hey, this is just >>> perfect, now >>> save the current configuration". >>> >>> >> +1 >> and the idea of being able to say "save the current config" is novel & new. >> > > The problem with "going behind the back of the commands and editing > config" restricts the interface presented by the command and the config > file itself. And it requires the sysadmin to frequently know more about > the underlying implementation(s) than they ever wanted to know. >
Do you have some research to support this statement that the sysadmin doesn't want to know about the underlying implementation? > The classic example here is ndd: the model presented was to > run /sbin/ndd on the running-config and then make the change persistent > by editing some /etc/rc*.d file. This is not a stable way of > making the change stick: some other /etc/rc*.d script added > at a later point could make the setting meaningless. > That's not the same. The problem with ndd and the rc*d files is that there is a way to tune TCP/IP (ndd) from the command line but there is no way to "store" that configuration for boot without modifying something that you really shouldn't. Thus people have been forced to modify existing or create their own new rc*.d files. Even with the rc.d model, there is nothing to say that a new rc.d file could be made (or an existing one modified) to parse in some data file and applie ndd settings. Now with SMF, there's nothing to say that in some large installation, they decide to add their own SMF service to Solaris that does all of their tuning for TCP/IP so they get an easy way to manage TCP/IP uniformly across their entire network. But if another SMF service that runs after that changes it, whether it is shipped by Sun or someone else, you're back to the rc.d problem you've got above. It is a fundamental property of the system being open and flexible that will always make it possible for someone or something to run after whatever you've normally used to apply system settings. Just because we decide to ship something in Solaris that supports storing TCP/IP tunables doesn't mean there won't be something that runs after it, either as part of SMF or rc.d. So everything you point out as being flawed with rc.d also applies to SMF. That is both simultaneously a strength and weakness of Solaris. Curiously, though, if someone has been using an rc.d script to store ndd things, that they are run after SMF will always give them priority over whatever services are delivered by Sun. Which is probably a good thing because it means customer systems won't stop behaving the way they want them to if/when they upgrade. Darren
