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