Date: Tue, 13 Feb 2001 21:51:47 -0800 From: Doug Barton <DougB@gorean.org> To: Brian Behlendorf <brian@collab.net> Cc: Greg Troxel <gdt@fnord.ir.bbn.com>, freebsd-stable@FreeBSD.ORG, Kris Kennaway <kris@obsecurity.org> Subject: Upgrading config files (Was: Re: sshd in 4.2-STABLE) Message-ID: <3A8A1CF3.264A5C70@gorean.org> References: <Pine.BSF.4.31.0102130807430.863-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Behlendorf wrote: > > On 13 Feb 2001, Greg Troxel wrote: > > The Debian package system does something like this, and I found it > > very helpful for the brief time I ran a GNU/Linux system. IIRC, > > packages distinguished between regular files (that weren't expected to > > change) and configuration files. When upgrading to a new version of a > > package, the rule was that if a config file was unchanged (same md5) > > from the installed package, it was replaced by the new version. If > > changed, the user was asked to merge/cope. Also, config files were > > left on pkg_delete (well, dpkg --remove), unless one asked to have > > them removed. My mm hacking time has been taken up recently by the more urgent nature of the BIND mess which has taken up extra work and "free(bsd)" time. However I've given a lot of thought to this MD5 scenario that you and a few others have suggested in the past. As much as I loathe the concept of automatically updating files without the user looking at the changes first, the request comes up so often that it's probably going to have to happen in one form or another. My preferred method of automatic updates is some sort of cvs-related system, however I think an MD5 based system will be (marginally) easier to implement (once a few hurdles are overcome) and will help more users. > I have to agree - many of the changes mergemaster makes are to files that > no one would recommend editing directly in regular use, like MAKEDEV and > /etc/rc.network and all the stuff in /etc/defaults. Modifying mergemaster > to only ask to merge files that have been changed sounds like a good idea > to me... Well, it definitely sounds like the easy way out. Whether it's a good idea or not is a whole other question. There are 4 corners to the equation... automatic upgrade or not, and force the users to see and approve the changes or not. Mergemaster takes the most paranoid approach by default, that of not automatically upgrading, AND forcing the user to see and approve of the changes. I made that decision because I felt strongly that the sysadmin SHOULD be looking at the changes before they go into the system. You can feel free to repeat the "tools not policy" mantra, but mm is my tool. My feeling was that if someone wanted to create another tool that did automatic upgrades, they should feel free to do that. (Small, lightweight tools, etc. etc.) However, in some measure to my chagrin (although much to my gratification) mm is now seen as "the" way to upgrade your config files. So, the question now is, does upgrading by default without forcing the user to see the changes unload the gun, or just point it at a different foot? My feeling is that all we're doing is replacing one set of problems with another, and losing the opportunity to educate the users in the process. I have long been an advocate of both making "The Right Thing" easier to understand and to accomplish, but at some level you just can't make unix system administration any easier. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A8A1CF3.264A5C70>