Currently, when upgrading the ThinLinc server packages, the existing modified configuration is moved to .rpmsave and .dpkg-old files. The new defaults for the new version are put in place instead. I think we should consider changing this. RPM: change %config to %config(noreplace) in the .spec.in files for each configuration file we install DPKG: change the --force-confnew flag to --force-confold in our installer The changes above, would solve the following: 1. It's difficult to present simple choices for what should happen with the configuration during an upgrade in tl-setup (see the work being done on bug 1760). It's easier to understand the choices if the files are in a state where nothing has happened yet. For example, a "do-nothing" choice would mean that the files are left completely untouched. 2. Due to bug 5376 (some configuration is active instantly) an administrator who leaves his ThinLinc system available after upgrading the packages will see parts of his system not working temporarily due to the fact that his configuration has been reset. A better starting point would be to leave the configuration be until the administrator makes a choice (especially if we want to move the task of merging/preparing new configuration to tl-setup).
Due to the work being done in bug 1760 for the upcoming release, I believe now is the best time to make this change as well.
The main drawback of noreplace/force-confold would be that if we introduce new values and comments, those would not by default end up in the active files. The fact that we don't get new values is however mitigated by the fact that ThinLinc works without (most) configuration files. We hard-code default values into the code.
Our RPM packages now use 'noreplace' and the installer runs '--force-confold' for DEB packages. Seems to work well. Tested upgrading using both RPM (rhel8) and DEB (ubuntu 18.04): * Only local change => built-in RPM/DEB migration * Only upgrade change => built-in RPM/DEB migration * Both changed => .rpmnew / .dpkg-dist * tl-setup parameters/old/ignore afterwards all works as expected
Package upgrade needs to be tested on both RPM and DEB systems: * When conf has been changed only in the new version you should get the new files. * When conf has been changed only in the existing files you should keep the existing files. * When conf has been changed in both the existing files AND in the new version you should no longer get .rpmsave or .dpkg-old files. You should now get .rpmnew and .dpkg-dist files that contain the new default values. * The configuration migration step in tl-setup should still work.
Upgraded from 4.8.1 to 4.10.1post on RPM (rhel7) and DEB (Ubuntu 18.04). To test this I followed the steps in comment #7: > > * When conf has been changed only in the new version you should get the new > files. > In version 4.8.1, 'display_min' was set to 1 and in newer versions it is set to 10. To test this step I checked that the value had been updated from 1 to 10. > > * When conf has been changed only in the existing files you should keep the > existing files. > Here I just added some variable (e.g. test=test) in nearest.hconf and checked that it was still there after the upgrade. > * When conf has been changed in both the existing files AND in the new version > you should no longer get .rpmsave or .dpkg-old files. You should now get > .rpmnew and .dpkg-dist files that contain the new default values. > I changed agent_hostname=test in vsmagent.hconf and verified that I got .rpnnew for rhel7 and .dpkg-dist for DEB. > > * The configuration migration step in tl-setup should still work. > The migration step consists of three options: 1) Use the new configuration files and migrate the parameters and values from the old files. To test this option, I changed agent_hostname= and checked that it had migrated to the new version and checked that my comments disappeared. 2) Use all old configuration files. Here, I removed agent_hostname in the old conf file and checked that it was removed in the new version. 3)Ignore old configuration and use the new files. I also removed agent_hostname here and checked that it reappear in the new version.
