From owner-freebsd-current@freebsd.org Tue May 10 18:21:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE814B36BDB; Tue, 10 May 2016 18:21:08 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9F4E1731; Tue, 10 May 2016 18:21:08 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: by mail.lifanov.com (Postfix, from userid 58) id 35692239428; Tue, 10 May 2016 14:11:16 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.lifanov.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.1 Received: from [127.0.0.1] (vnat600.ejoco.com [166.108.32.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id C12A8239424; Tue, 10 May 2016 14:11:13 -0400 (EDT) Subject: Re: HEADS-UP: installworld on r299292 through r299317 will replace master.passwd, passwd, and group files To: John Baldwin , Glen Barber References: <20160510055341.GA47527@FreeBSD.org> <1791715.DtjAh9y9tb@ralph.baldwin.cx> <20160510171228.GI47527@FreeBSD.org> <3902262.K6dzkzNhik@ralph.baldwin.cx> Cc: freebsd-current@freebsd.org, Thomas Zander , "O. Hartmann" , current@freebsd.org From: Nikolai Lifanov Message-ID: <5dfd561f-6add-e1b5-01a8-dbc117c47d6b@mail.lifanov.com> Date: Tue, 10 May 2016 14:11:11 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <3902262.K6dzkzNhik@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 18:21:08 -0000 On 05/10/2016 13:22, John Baldwin wrote: > On Tuesday, May 10, 2016 05:12:28 PM Glen Barber wrote: >> On Tue, May 10, 2016 at 10:04:47AM -0700, John Baldwin wrote: >>> On Tuesday, May 10, 2016 06:32:29 AM Glen Barber wrote: >>>> On Tue, May 10, 2016 at 08:25:22AM +0200, Thomas Zander wrote: >>>>> On 10 May 2016 at 08:18, O. Hartmann wrote: >>>>> >>>>>> I haven't figured out so far how far this goes. Lucky for those having >>>>>> recent /etc/ backups. A pity FreeBSD doens't backup this by default. >>>>> >>>>> After having shot myself in the foot some time ago, "zfs snapshot" has >>>>> become a part of my standard upgrade procedures :-) >>>>> >>>> >>>> No argument that this is valuable, but we cannot rely on filesystem >>>> specific solutions. Similar topic came up a few days ago following >>>> lunch. It got me thinking of a better way to ensure this kind of thing >>>> does not require home-grown foot protection from cannons. >>>> >>>> It should be fairly trivial to automatically backup /etc (and related) >>>> when 'distribution' is run, either intentionally or accidentally (or by >>>> commit mistakes, such as this). >>> >>> Saving the output of 'etcupdate diff' nightly might not be a bad first step. >>> >> >> This is also a good way to alleviate such things, however I am unsure >> how to handle cases where 'etcupdate' would inadvertently run into >> a conflict. This was my concern with implementing an "automatic" >> etcupdate run in the runtime package. > > I mean as part of the nightly jobs we could add one that stores > 'etcupdate diff' in /var the same as we do with backups of the master.passwd, > group, and aliases files in /var/backups. You can then at least use that to > reconstruct altered /etc files by applying the diffs. This isn't meant to be > an automated update run, but just saving a diff as part of the nightly jobs. > That's what I do. The periodic "etcupdate diff" dumps, which I was already taking despite boot environments helped me work through various pkgbase issues. > As far as what to do in runtime packages, presumably there isn't a single > package with all of etc, but etc files can be split up (ppp.conf in the ppp > package, etc.) and pkg needs to do its own 3-way merge of changes to conf > files when upgrading. (This would be nice for conf files for ports in > /usr/local/etc as well.) You still need to figure out how to handle > conflicts, but if pkg manages /etc files as config files and does a 3-way > merge of the old package and new package then that will serve to reimplement > etcupdate as part of 'pkg upgrade'. Having a 'pkg confdiff' or some such to > output diffs made to conf files would be the equivalent of 'etcupdate diff' > in that case (and would be nice as it would apply to conf files in ports as > well). > Having "pkg confdiff" would be wonderful, for both base and ports. - Nikolai Lifanov