Disclaimer: I'm well aware that this thread is a year old, but I still wanted to re-visit it because I can't help but notice a lot of confusion happening above.
Especially about what
etcupdate actually does... but having said that: some things could have changed during the past year (and I'm too lazy to check Git's backlog
).
Having that out of the way => First you need to ask yourself if you really need
etcupdate, because it all depends on how you're updating your jail. If you rely on
freebsd-update (
as suggested by the handbook) then there's no need because that process also maintains your configuration files.
But if you're building from source.. then this is probably something to consider doing. Keep in mind though that there's a difference between building from inside the jail, or using the source tree from or on your host. In the first situation you can simply follow the given steps as suggested by
/usr/src/Makefile and rely on the automated ("Default") mode.
In my example I've got the source tree on the host, and I'm about to use the
installworld build target to update my jail, this jail is located in
/opt/jails/gamma.
Step 1
First thing we need is to get ourselves a current tree which
etcupdate will be able to compare against. Keep in mind: the current tree is extracted from the source tree (or ... a tarball that was created using the source tree) after which
etcupdate is going to compare the local files against this generated tree.
My point being: all
etcupdate needs is access to the local files as well as the (current) tree to work against. No more, no less. You can clearly see this if you check the SYNOPSIS section in
etcupdate(8).
So =>
# etcupdate extract -D /opt/jails/gamma.
The result should be
/opt/jails/gamma/var/db/etcupdate/current as well as a logfile.
Step 2
Perform the actual update. In my case:
# make DESTDIR=/opt/jails/gamma installworld.
Step 3
We could rely on the Default ("auto") mode from here on out, but within the context of having manually build the jail (and assumingly also customized it) this step seems very counter productive to me. Let's keep control over the situation.
So =>
# etcupdate diff -D /opt/jails/gamma.
Followed by verifying the current situation:
# etcupdate status -D /opt/jails/gamma.
With a casual phat ("thick") jail that hasn't been heavily customized I'm expecting everything to be handled fully automagically, in other words I think
status won't give you any feedback. Remember the Unix philosophy: no news = good news!
Step 4
Now it's time to clean up our mess, assuming of course that you changed stuff and our system needs a little culling =>
# /usr/bin/yes | make DESTDIR=/opt/jails/gamma delete-old, optionally followed by the
delete-old-libs build target.
And that's all she wrote:
Code:
root@bsd:/usr/src # mount | grep jails
zroot/opt/jails on /opt/jails (zfs, local, nosuid, nfsv4acls)
zroot/opt/jails/gamma on /opt/jails/gamma (zfs, local, nosuid, nfsv4acls)
zroot/opt/jails/psi on /opt/jails/psi (zfs, local, nosuid, nfsv4acls)
root@bsd:/usr/src # etcupdate status
Warnings:
Modified regular file remains: /etc/aliases
Modified regular file remains: /etc/mail/sendmail.cf
Modified regular file remains: /etc/mail/submit.cf
Non-empty directory remains: /etc/mail
root@bsd:/usr/src # etcupdate status -D /opt/jails/gamma/
root@bsd:/usr/src #
(guess who recently trashed the MTA/MDA's ("
WITHOUT_MAIL=") in his base system?
).
And there ya have it, the only 3.5 steps you need to sort everything out.
