On Thu, Feb 9, 2012 at 8:13 PM, Dax Kelson <dkelson@xxxxxxxxxxxx> wrote: > > On Wed, Feb 8, 2012 at 4:55 PM, Andy Grover <agrover@xxxxxxxxxx> wrote: > > Hi Dax and all, > > > > Right now, if you reboot, you revert to last saved settings. If you > > didn't do "saveconfig" then everything goes away. > > > > What do you think about saving the settings every time the targetcli > > serviceunit is stopped, i.e. on shutdown? > > I don't think that is a good idea. It violates the principal of least > surprise [1]. I agree. This is why I implemented the way it is. If there is enough expressed need for this, than at the very least it should be an option. The idea initially was also to be able to test a new config, and just have to reboot to revert to the known good one in case the new one breaks too many things and the admin gets cornered. > > > It will be new behaviour to SAs and IT folks as it isn't the typical > Linux/UNIX style. > > There are many commands in Linux that change the /running/ > configuration, but don't modify the /persistent/ configuration. Some > examples of pairs of commands/config for doing run time changes versus > persistent changes. > > iptables > iptables-save > > sysctl -w > /etc/sysctl.conf > > service > chkconfig > > ifconfig > /etc/sysconfig/network-scripts/ifcfg-XXX > > exportfs -o > /etc/exports > > togglesebool > togglesebool -P > > fdisk > > Kernel auditing rules > > Shell and environment variables > > Even non-Linux/UNIX platforms such as Cisco IOS use this two step > procedure (ie with Cisco IOS or other IOS-like interfaces run time > changes aren't saved until you run 'wr mem' or 'copy running-config > saved-config'). > > Keep the current behavior of requiring an explicit 'saveconfig'. > However, you could warn on exit if there are unsaved changes -- that > would be a nice thing to do for SAs. > > Dax Kelson > > [1] http://www.faqs.org/docs/artu/ch11s01.html -- Jérôme Martin -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
