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

[Ignacio Marambio Catán]

tim foster explains how this particular thing works with IPS
http://timsfoster.wordpress.com/2011/11/09/ips-self-assembly-part-1-overlays/
Also, check the IPS developer guide

On Thu, Jan 17, 2013 at 11:01 AM, Jim Klimov <jimklimov at cos.ru> wrote:

> 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
>
>
>
> ______________________________**_________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@**openindiana.org<OpenIndiana-discuss at openindiana.org>
> http://openindiana.org/**mailman/listinfo/openindiana-**discuss<http://openindiana.org/mailman/listinfo/openindiana-discuss>
>