[FUG-BR] Fwd: Another tool for updating /etc

Marcus Lahr marcus em iel.unicamp.br
Terça Março 23 18:15:56 BRT 2010


Senhores,

Não sei se grande parte da lista assina a freebsd hacks.
Segue abaixo uma nova ferramenta que pode ser utilizada no lugar do 
mergemaster.

Abraço,

Marcus Lahr
Administrador de Redes
SI IEL



-------- Mensagem original --------
Assunto: 	Another tool for updating /etc
Data: 	Tue, 23 Mar 2010 11:08:45 -0400
De: 	John Baldwin <jhb em freebsd.org>
Para: 	hackers em freebsd.org



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.

-- 
John Baldwin
_______________________________________________
freebsd-hackers em freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe em freebsd.org"




Mais detalhes sobre a lista de discussão freebsd