Date: Thu, 17 Oct 2002 07:30:38 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Juergen Unger <j.unger@addict.de> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Mergemaster [was: Re: Ifconfig config of gif tunnels] Message-ID: <20021016213038.GH32705@gsmx07.alcatel.com.au> In-Reply-To: <20021016193422.A51167@raven.addict.de> References: <004401c2742a$d6169d90$6501a8c0@VAIO650> <3DAC0045.4060201@Kernick.org> <3DAC163D.1060701@inode.at> <20021016193422.A51167@raven.addict.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-Oct-16 19:34:22 +0200, Juergen Unger <j.unger@addict.de> wrote: >it like this idea but I do have another suggestion wich can >be implemented additionally: If the version of a file changed >let mergemaster look if the old existing file was modified at >all. This can be done for example with a lookup of the original >file via cvs. >If the old existing file was never modified by an admin then >let mergemaster silently install the new version. >So all such files like /etc/periodic/*, /etc/mtree/*, /etc/default/* This is unlikely to cause a problem for /etc/mtree. It's probably OK for /etc/periodic but is definitely dangerous for /etc/default. In the recent past, there have been changes to /etc/default/rc.conf which inverted the run state of inetd (twice), significantly changed the behaviour of the sendmail and changed the parameter meaning for log_in_vain. These all potentially require corresponding changes to /etc/rc.conf. Two mechanisms are usually proposed to allieviate the need to read changes to /etc/defaults/rc.conf: 1) Read UPDATING 2) Explicitly include the wanted status of relevant variables (on or off) in /etc/rc.conf. Neither of these worked for the log_in_vain change - it wasn't mentioned in UPDATING and since the actual parameter format changed, just having 'log_in_vain="NO"' or 'log_in_vain="YES"' in your /etc/rc.conf wasn't adequate protection. Likewise, the sendmail changes meant you had to change /etc/rc.conf if any part of your sendmail configuration was not as per the defaults. >If a file is then mentioned in /etc/defaults/mergemaster.conf or >/etc/mergemaster.conf the file is processed like defined there. >If the file it is not listed in a .../mergemaster.conf then >check the cvs if the old file was modified, if not install the >new version. If modified ask the updating admin what to do... This does sound like a good idea but how do you handle the case where the person doesn't have a CVS repository? I gather a lot of people CVSup /usr/src, not /usr/ncvs. Even those who do have /usr/ncvs locally might not export it to client machines when doing remote installs. Peter 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?20021016213038.GH32705>