git: 70e64ba44941 - main - release.sh: Update GITROOT URL

[Benjamin Kaduk]

On Thu, Dec 31, 2020 at 10:25 AM John Baldwin <jhb at freebsd.org> wrote:

> On 12/30/20 1:18 PM, Rodney W. Grimes wrote:
> > Take for example all the files in /etc, these files can easily
> > at present often be tracked back to exactly what release installed
> > them cause the $FreeBSD$ points you at it.  These files are often
> > modified by local administrators, and with out knowing what version
> > they started out it is a crap shoot to ever figure it out unless
> > the local mods are minor and you get lucky.
> >
> > Contractors are some times hired to go in and upgrade or clean up
> > after someone else did work, and not having this information and
> > telling them to go dig in git to try and figure out the state of
> > there system is pretty much a non-started, well at least it is for
> > me.
>
> Have you seen 'etcupdate diff'?  With pkgbase I'm hopeful we will
> have a similar 'pkg confdiff' type functionality (for ports as well as
> base) where packages keep stock config files around while installed
> that existing ones can be compared against (and that can be used for
> 3 way merges during upgrades similar to what etcupdate does).
>
> (etcupdate diff is explicitly designed due to experience in sysadmin
> mode and etcupdate in general is designed with the goal of rolling
> out new snapshots to fleets of machines requiring minimal user
> intervention)
>
>
More generally I would make the analogy to keeping metadata about
a given data object in-band with the data vs. separately tracked.
Generally, the in-band data cannot be authenticated very well and
can be malleable, letting the metadata get out of sync with the data
both when the data is modified and when the metadata is modified.
It's generally easier to build robust and secure systems when the
metadata is tracked separately from the data itself.  This is the general
model that etcupdate fits into (keeping a pristine copy of the file along
with versioning/identification information), as well as puppet and similar
fleet-management tools.  In the latter case the expected configuration
and versioning is tracked and authenticated centrally, and any local
modifications or deviations from the expected state can be flagged for
follow-up.

-Ben