Overwriting policy in upgrading

[Takeshi NISHIMURA]

Thanks, Scott.

As we have to support lots of installations with various upgrade histories and we want to reduce troubleshooting efforts, I want to recommend to always make their configurations up to date, in order to minimize variations of configurations.

I also imagined the feasibility of a script. It should:
1. update unmodified configuration files
2. remove unnecessary unmodified configuration files
3. suggest distribution changes for modified configuration files
4. suggest removal of unnecessary modified configuration files

The concrete source for distribution changes varies according to when the script runs: 
a) /opt/shibboleth-idp/old-XXX/ and /opt/shibboleth-idp/dist/ for post-upgrade,
b) /opt/shibboleth-idp/dist/ and INSTALLERDIR/dist/ for pre-upgrade.

In this investigation, I found it needs another information to check distribution changes for configuration files in webapp/, e.g. web.xml. Of course I can compare current settings (in edit-webapp/) and new distribution default (in INSTALLER/webapp/), but it is not enough to merge customization and distribution change.

In short, I think (old) distribution defaults should exist in dist/webapp/.

Sincerely,
Takeshi

> 2016/12/17 3:53、Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> On 12/16/16, 1:47 PM, "users on behalf of Takeshi NISHIMURA" <users-bounces at shibboleth.net on behalf of takeshi at nii.ac.jp> wrote:
> 
>> I saw the upgrade process never overwriting unmodified configuration files too, e.g. services.xml.
>>   Is it intended? Isn't it safe to overwrite such files mechanically?
> 
> It's safe, but this isn't an RPM package, we have no way to do it. And it doesn't change what we can do since we can't ever count on it actually happening, so it doesn't affect any of our decisions or strategies for making changes.
> 
> If there's an ant hook for doing this automatically we could probably look at it, but it's a lot of work in a fragile area of the system for little benefit. It would probably be more likely we could cook up a shell script that could run diffs and do some of this after updating for people that wanted it. Or maybe somebody else has one already.
> 
> -- Scott