RFC: etcupdate tool in base?

John Baldwin jhb at freebsd.org
Tue Jun 15 14:07:22 UTC 2010


On Monday 14 June 2010 5:22:32 pm Garrett Cooper wrote:
> On Thu, Jun 10, 2010 at 10:46 AM, John Baldwin <jhb at freebsd.org> wrote:
> > I've had several folks ask me recently about importing etcupdate
> > (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an 
alternate
> > tool for updating /etc during upgrades.  Do folks have any strong 
objections
> > to doing so?  More details about how it works and an HTML version of the
> > manpage can be found at the URL above.
> 
> Finally got around to looking at this.
> 
> Some comments:
> 
> 1. Script doesn't check to see whether or not it has write access (and
> doesn't catch some errors):
> 
> $ etcupdate
> mkdir: /var/db/etcupdate: Permission denied
> /usr/sbin/etcupdate: cannot create /var/db/etcupdate/log: No such file
> or directory
> 
> Eventually it stops though, so maybe it's not really a big issue...

It does actually check, but it does so after it opens the log file. :-/

> 2. Some messages are a bit misleading:
> 
> $ etcupdate
> /usr/sbin/etcupdate: cannot create /var/db/etcupdate/log: Permission denied
> $ ls -l /var/db/etcupdate/log
> -rw-r--r--  1 root  wheel  0 Jun 14 14:06 /var/db/etcupdate/log
> $ whoami
> garrcoop

That is the shell complaining due to this:

                exec 3>$LOGFILE

Arguably the shell is emitting the correct message since it is attempting to 
recreate the file.

> 3. Workflow comments.
> 
> i. Ok... I know I'm doing a downgrade, but what now?
> 
> $ sudo etcupdate
> No previous tree to compare against, a sane comparison is not possible.
> 
> ii. Did a bit more reading, and I think that `etcupdate build' is what
> I want... but it wasn't happy when I did that:

Did you read this part of the manpage:

EXAMPLES
     If the source tree matches the currently installed world, then the fol-
     lowing can be used to bootstrap etcupdate so that it can be used for
     future upgrades:

           etcupdate extract

     To merge changes after an upgrade via the buildworld and installworld
     process:

           etcupdate

     To resolve any conflicts generated during a merge:

           etcupdate resolve


Also, the README file at http://www.FreeBSD.org/~jhb/etcupdate/ may be useful.

> $ sudo etcupdate build
> Missing required tarball.
> 
> usage: etcupdate [-nBF] [-d workdir] [-r | -s source | -t tarball] [-A 
patterns]
>                  [-D destdir] [-I patterns] [-L logfile] [-M options]
>        etcupdate build [-B] [-d workdir] [-s source] [-L logfile] [-M 
options]
>                  <tarball>
>        etcupdate diff [-d workdir] [-D destdir] [-I patterns] [-L logfile]
>        etcupdate extract [-B] [-d workdir] [-s source | -t tarball] [-L 
logfile]
>                  [-M options]
>        etcupdate resolve [-d workdir] [-D destdir] [-L logfile]
>        etcupdate status [-d workdir]
> 
> So uh... ok? Manpage and usage were a bit confusing (but not too bad).
> After I fixed my arguments, here's what I came up with:
> 
> $ sudo etcupdate build -s /data/scratch/src/stable/8/
> /root/etcupdate-stable8.tbz
> $ sudo etcupdate extract -t /root/etcupdate-stable8.tbz
> $

You could just do 'etcupdate extract -s /data/scratch/src/stable/8' in this 
case. :)  However, when you do an extract, you are doing a one-time bootstrap.  
This step needs to be pointed at a source tree that matches what you already 
have installed.  You can do an 'etcupdate diff' after the extract to see what 
local differences you have and make sure those look sane.  Once you have done 
this, then you can use etcupdate for future upgrades by just running 
'etcupdate'.

-- 
John Baldwin


More information about the freebsd-current mailing list