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

[John Baldwin]

On 12/31/20 2:40 PM, Rodney W. Grimes wrote:
>> 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.
> 
> And that works GREAT when people are disaplined enough to follow
> it, it all fails misserable when you have not so experienced people
> setting up a bunch of systems... that then leave or are dismissed
> and you end up called in to to try and pick up the pieces.  This
> is when that FreeBSD string is a total ass saver.
> 
> If you have ever had to go into and clean up after some one
> makes a mess you'll know what I am talking about if you have
> not done this type of work.. well you just probably not going
> to get it.

The id strings do not solve all problems.  In the case of a total
tire fire, you can't trust the strings anyway.  People are free
to merge in the other changes to files without updating the strings,
etc.  Binaries are harder to munge in that fashion, but it's quite
easy to avoid updating the FreeBSD string in an /etc file (e.g. if
someone incorrectly assumed the values meant something and had to
be preserved to not "break the system" which is the kind of thing
I've run into in past tire fires).  At that point you are best left
with doing a bisect of a source tree to line up which source tree
is closest to the files you have in /etc.

-- 
John Baldwin