From owner-dev-commits-src-main@freebsd.org Thu Dec 31 23:10:05 2020 Return-Path: Delivered-To: dev-commits-src-main@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D19264D4318; Thu, 31 Dec 2020 23:10:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6P4s5Lmrz4WHj; Thu, 31 Dec 2020 23:10:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:6d91:ae61:b3ec:ca03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 93F0D241FE; Thu, 31 Dec 2020 23:10:04 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: git: 70e64ba44941 - main - release.sh: Update GITROOT URL To: rgrimes@freebsd.org, Benjamin Kaduk Cc: Ryan Libby , Warner Losh , Glen Barber , Kyle Evans , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202012312240.0BVMehp3088202@gndrsh.dnsmgr.net> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <35f3f84a-5397-9ea7-38ed-d488610cd583@FreeBSD.org> Date: Thu, 31 Dec 2020 15:10:02 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <202012312240.0BVMehp3088202@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: dev-commits-src-main@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for the main branch of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 23:10:05 -0000 On 12/31/20 2:40 PM, Rodney W. Grimes wrote: >> On Thu, Dec 31, 2020 at 10:25 AM John Baldwin 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