From owner-freebsd-stable Wed Oct 16 14:30:57 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEBFA37B401 for ; Wed, 16 Oct 2002 14:30:55 -0700 (PDT) Received: from alcanet.com.au (mail2.alcanet.com.au [203.62.196.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B37243E88 for ; Wed, 16 Oct 2002 14:30:54 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from sydsmtp01.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1]) by alcanet.com.au (8.12.4/8.12.4/Alcanet1.3) with ESMTP id g9GLUdUf032472; Thu, 17 Oct 2002 07:30:40 +1000 Received: from gsmx07.alcatel.com.au ([139.188.20.247]) by sydsmtp01.alcatel.com.au (Lotus Domino Release 5.0.11) with ESMTP id 2002101707303840:60856 ; Thu, 17 Oct 2002 07:30:38 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.5/8.12.5) with ESMTP id g9GLUceT035727; Thu, 17 Oct 2002 07:30:38 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.5/8.12.5/Submit) id g9GLUcfM035726; Thu, 17 Oct 2002 07:30:38 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Date: Thu, 17 Oct 2002 07:30:38 +1000 From: Peter Jeremy To: Juergen Unger Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Mergemaster [was: Re: Ifconfig config of gif tunnels] Message-ID: <20021016213038.GH32705@gsmx07.alcatel.com.au> Mail-Followup-To: Juergen Unger , freebsd-stable@FreeBSD.ORG References: <004401c2742a$d6169d90$6501a8c0@VAIO650> <3DAC0045.4060201@Kernick.org> <3DAC163D.1060701@inode.at> <20021016193422.A51167@raven.addict.de> Mime-Version: 1.0 In-Reply-To: <20021016193422.A51167@raven.addict.de> User-Agent: Mutt/1.4i X-MIMETrack: Itemize by SMTP Server on SYDSMTP01/AlcatelAustralia(Release 5.0.11 |July 24, 2002) at 17/10/2002 07:30:38 AM, Serialize by Router on SYDSMTP01/AlcatelAustralia(Release 5.0.11 |July 24, 2002) at 17/10/2002 07:30:40 AM, Serialize complete at 17/10/2002 07:30:40 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-Oct-16 19:34:22 +0200, Juergen Unger 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