Another tool for updating /etc

Garrett Cooper yanefbsd at gmail.com
Tue Mar 23 17:00:38 UTC 2010


On Tue, Mar 23, 2010 at 8:08 AM, John Baldwin <jhb at freebsd.org> wrote:
> I have tried a few approaches (and looked at another) for updating /etc after
> world upgrades over the past several years.  All of these approaches have
> various tradeoffs of pros and cons.  However, none of them fully fit what I
> wanted:
>
> 1) Using a set of manual steps first outlined in the handbook in the pre-
> mergemaster days.  This involved building a new etc tree after each world
> install and using a script to compare this tree to the previous tree.  I
> would then merge changes to /etc on the main machine by hand.
>
> Some downsides here are that the actual merging was tedious and completely
> manual.  On the upside, the the necessary data was present to do a full 3-way
> merge and to notice cases like a file becoming a directory, or a file being
> removed.
>
> 2) Using mergemaster as described in the handbook, etc.
>
> Some downsides here are that the process is not automated but requires manual
> intervention.  Using '-iFU' helps some, but you can't reliably do scripted
> installs easily.  MM also does not keep as much state around.  The mtree db
> will let you know if a file is "stock", but it doesn't have enough context to
> do a 3-way merge.
>
> 3) etcmerge from ports.  I have not actually used it, just read the
> documentation, etc.  In general this looks like it DTRT and is fairly
> automated.  The one caveat I see though is that it updates a separate /etc
> tree that then has to be copied back only after any conflicts are resolved.
>
> Some of the primary things I was looking for was a tool that met the
> following:
>
> 1) Automated: is able to automate as much of the merging/etc. as possibly
> using 3-way merges from the old and new versions of files, doing a best effort
> and only requiring manual intervention for a conflict that could not be
> resolved automatically.  I want the ability to update 100's of machines via
> scripts without having to answer prompts on each one, then getting a summary
> at the end of any outstanding conflicts.
>
> 2) Best effort merge into /etc: I want the update to update as many files
> directly in /etc as possible and only leave conflicts for manual resolution.
>
> 3) Doing a full 3-way merge: I want something equivalent to doing an 'svn up'
> or 'cvs up'.  If the local changes I made do not conflict, then just merge the
> changes automatically (e.g. enabling a serial console in /etc/ttys should not
> conflict with $FreeBSD$ changing when moving from 7.2 to 7.3).
>
> To that end, I wrote a new tool that I think does a decent job of solving
> these goals.  It does not force you to read the diffs of any files updated in
> /etc, but there are other tools available for that.  However, if you are ok
> with reading UPDATING, commit logs, and/or release notes for that sort of
> info, then this tool may work for you.
>
> It also has a nice feature in that you can generate a 'diff' of your current
> /etc tree against the "stock" tree allowing you to easily see what local
> changes you have made.  I have already found this feature to be far more
> useful than I first expected.
>
> The UI is (hopefully) minimalist.  The default output looks like the output of
> 'svn up' or 'cvs up'.
>
> If you'd like to give it a shot, you can find the script and manpage at
> http://www.FreeBSD.org/~jhb/etcupdate/  There is a README file that gives a
> brief overview and instructions on how to bootstrap the needed metadata before
> the first update.  There is also an HTML version of the manpage.

    Hmmm... looks pretty complete. The only [minor] concern I have is
that a lot of the variables aren't quoted, so paths with spaces will
fail (I'm not sure if this is a non-defacto standard way of installing
things in the project, but it'd be nice if these items were fixed).
    I'll give it a run sometime in the near future :)...
Cheers!
-Garrett


More information about the freebsd-hackers mailing list