nia <nia%NetBSD.org@localhost> writes: > On Fri, Apr 15, 2022 at 08:05:54AM -0400, Greg Troxel wrote: >> To me, the right behavior is to know if each file in etc has been put >> there as a copy of a file that appeared in etc.tgz, and to change it to >> the new version without prompting if so, and if not, to note to the user >> that it might need attention. Perhaps sysupgrade/etcupdate does this, >> and if so great. >> > > -a etcupdate can automatically update files which have not > been modified locally. The -a flag instructs etcupdate to > store MD5 checksums in /var/etcupdate and use these > checksums to determine if there have been any local > modifications. Seems like that should be the default. > -l Automatically skip files with unchanged RCS IDs. This has > the effect of leaving alone files that have been altered > locally but which have not been changed in the reference > files. Since this works using RCS IDs, files without RCS > IDs will not be skipped even if only modified locally. > This flag may be used together with the -a flag described > above. Use of RCS IDs seems fragile/unsound in that you can't conclude from matching IDs that the files match, or really the other way around, given people storing sources in !cvs with local modes, local builds, etc. (Not saying doing local things in !cvs is bad, just that the RCS ID match assumption assumes more than is true.) Seems like this should be based on a database of hashes of the old upstream and the new upstream, as well as the previous version in /etc, and perhaps have a way to record that the admin has agreed to the current contents of a file in /etc. > Downside: this doesn't work for modified files without RCS IDs, which > of course means that etcupdate prompts about /etc/passwd (etc.) > every single time. The other thing I should have said is that etcmanage never prompts: it is totally non-interactive which means it can be run as a batch job to ssh to 20 machines and update them all and then reboot them. That's why it got written (in 2004, when perl was ok). It got spiffed up in 2010/2011 for a testbed of 50 machines (that would get a full system update pretty often). Yes, I know that's technically dangerous, but being able to see diffs and reduce them when you want to pay attention, and have it be on autopilot the rest of the time, has been in practice very reliable. And having the admin do it by hand is also dangerous, for an admin that is not infallible. And there's only one of those, and they do things other than sysadmin most of the time :-) Perhaps I might figure out to improve etcupdate so it can do what I want. It seems like it is reasonably close.
Attachment:
signature.asc
Description: PGP signature