[OpenIndiana-discuss] preserve configuration files on image-update - how?

[Jim Klimov]

On 2013-01-17 12:59, Stefan Müller-Wilken wrote:
> Dear all,
>
> while updating from OI 151a_5 to 151a_7 worked smoothly for me, " pfexec pkg image-update -v" overwrote (at least) my dovecot configuration files  without backing up the existing ones (e.g. as rpm would with .rpmsave files). Yet another time I was happy to use OpenIndiana with its boot environments and snapshots. :-)
>
> Is there a pkg command line argument to influence that behavior and have pkg save those files? Or is it entirely up to the respective package to trigger that in its spec file? What's the best practice in that case? Mount the old boot environment and then manually copy config files to the new boot environment? But how would I know what to look at?
>
> Would be great if someone could point me at some best practices. TIA!

Well, not that my answer is immediately relevant, but back in the
days of Solaris, SVR4 packages (where config files were marked as
"editable" or "volatile" FS object type, and/or had some "class"
assigned to them to trigger update/merge scripts), the LiveUpgrade
system copied the old files to something like hosts.~10 and then
replaced or intellectually merged them with those in the update.
In the end of the upgrade process it warned about the 30 or so
files (as well as packages whose updates generated warnings) that
should be revised by the admin to validate that nothing was broken,
before activating the new BE. For us it was usually the sendmail
config that might need tweaks returned...

As for IPS - I don't really know yet, how it plays around such
rough edges. However, many programs converge toward a "config.dir"
approach so that the packaged master config can automatically
include your custom snippets and have no update conflicts...

Overall, it may be wrong to just take your old configs and copy
over the updates - the newer programs might include new features
and keywords which you may want to retain from the new default
config or even customize. Notorious for that are the PAM files
that may include hooks for newer programs or features that are
integrated by default in the newer release of an OS.

I usually make a practice of copying the original configs with
a backup suffix, then making modifications, and then when an
upgrade comes with a new baseline packaged config file - some
sort of 3-way diff (manual or automated) can be applied to
promote my modifications over the new default config.

For you, perhaps, "zfs diff A B | grep '\.conf'" might be helpful
to find any changed files which match the pattern. When you do,
"diff" them couple by couple to see if the changes are trivial
(i.e. comments updated) or some more work is needed from you.

HTH,
//Jim