From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 23 15:08:52 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44968106566B for ; Tue, 23 Mar 2010 15:08:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 02E638FC15 for ; Tue, 23 Mar 2010 15:08:52 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8ED8C46B8C for ; Tue, 23 Mar 2010 11:08:51 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id D14818A01F for ; Tue, 23 Mar 2010 11:08:47 -0400 (EDT) From: John Baldwin To: hackers@freebsd.org Date: Tue, 23 Mar 2010 11:08:45 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201003231108.45102.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 23 Mar 2010 11:08:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.7 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Another tool for updating /etc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 15:08:52 -0000 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