Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 May 2016 10:22:04 -0700
From:      John Baldwin <jhb@freebsd.org>
To:        Glen Barber <gjb@freebsd.org>
Cc:        freebsd-current@freebsd.org, Thomas Zander <riggs@freebsd.org>, "O. Hartmann" <ohartman@zedat.fu-berlin.de>, current@freebsd.org
Subject:   Re: HEADS-UP: installworld on r299292 through r299317 will replace master.passwd, passwd, and group files
Message-ID:  <3902262.K6dzkzNhik@ralph.baldwin.cx>
In-Reply-To: <20160510171228.GI47527@FreeBSD.org>
References:  <20160510055341.GA47527@FreeBSD.org> <1791715.DtjAh9y9tb@ralph.baldwin.cx> <20160510171228.GI47527@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--nextPart29927799.R8sSNE5dgU
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

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 <ohartman@zedat.fu-berlin.=
de> wrote:
> > > >=20
> > > > > I haven't figured out so far how far this goes. Lucky for tho=
se having
> > > > > recent /etc/ backups. A pity FreeBSD doens't backup this by d=
efault.
> > > >=20
> > > > After having shot myself in the foot some time ago, "zfs snapsh=
ot" has
> > > > become a part of my standard upgrade procedures :-)
> > > >=20
> > >=20
> > > No argument that this is valuable, but we cannot rely on filesyst=
em
> > > specific solutions.  Similar topic came up a few days ago followi=
ng
> > > lunch.  It got me thinking of a better way to ensure this kind of=
 thing
> > > does not require home-grown foot protection from cannons.
> > >=20
> > > It should be fairly trivial to automatically backup /etc (and rel=
ated)
> > > when 'distribution' is run, either intentionally or accidentally =
(or by
> > > commit mistakes, such as this).
> >=20
> > Saving the output of 'etcupdate diff' nightly might not be a bad fi=
rst step.
> >=20
>=20
> 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.p=
asswd,
group, and aliases files in /var/backups.  You can then at least use th=
at 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.

As far as what to do in runtime packages, presumably there isn't a sing=
le
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 co=
nf
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-w=
ay
merge of the old package and new package then that will serve to reimpl=
ement
etcupdate as part of 'pkg upgrade'.  Having a 'pkg confdiff' or some su=
ch to
output diffs made to conf files would be the equivalent of 'etcupdate d=
iff'
in that case (and would be nice as it would apply to conf files in port=
s as
well).

=2D-=20
John Baldwin
--nextPart29927799.R8sSNE5dgU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit


--nextPart29927799.R8sSNE5dgU--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3902262.K6dzkzNhik>