[Thinlinc-technical] Migrate configuration during ThinLinc upgrade

[Rob De Langhe]

  hi Peter,

very nice to hear your appreciation about operational stability during
upgrades !

You ask about personal preferences, so here is my strictly personal
preference:
- I hate defaults, when they are not visible : to my preference, all
possible parameters should be listed in config files, with their default
value commented or explicitly assigned; this way I know what parameters
exist, and by seeing their default values I can appreciate how to use them
; this dates from my stone-age era of learning programming via declarative
languages as Pascal (no surprises, all is declared and visible)
- so if an upgraded software suite has new parameters, or no longer
supports old parameters, I can easily run a 'diff' between old and new
config files to see the differences in parameters (their existence, as well
as their values)

Therefor, to me the option is always highly preferred to have a upgrade
install its new config files, backing-out my old config files (renaming,
obviously), and then telling me explicitly what diffs its finds between the
new and old config files so that I assess manually each and every parameter
change.

-> new defaults
-> new config will work with the new software
-> all new params are visible
-> I assess each and every parameter change

Curious to hear about other people's working preferences !

cheers, and keep up this good work with ThinLinc !
Rob

Citeren Peter Astrand <astrand at cendio.se>:

> Hi. We are thinking about improving the configuration handling during a
> ThinLinc upgrade, and wants to share our thoughts with you, in order to
> get some feedback.
>
> As you probably know, ThinLinc uses the "Hiveconf" configuration system,
> where parameter/value pairs are stored in an abstract folder-like
> namespace. In practice, parameters are stored in text files below
> /opt/thinlinc/etc/conf.d/. These files are marked as configuration
> files, in order to get some special attention by the package managers
> (RPM/DPKG). What happens during upgrade depends on if the file has been
> changed in the updated package and/or on disk. In most cases, the
> package manager can determine what to do. Only one case is problematic:
> If a particular file is changed both in the updated package and on disk
> (by the admin). When this happens, the package manager will install the
> new file from the updated package, and save the edited file in .rpmsave
> or .dpkg-old. (See
> http://www-uxsup.csx.cam.ac.uk/~jw35/docs/rpm_config.html and
>
https://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-managed-by-dpkg/
for
> details).
>
> Currently, the ThinLinc installer will not allow you to proceed with
> running "tl-setup" directly after an upgrade (regardless of whether any
> .rpmsave or .dpkg-old files were actually created), but instead advise
> you to check for such files and review them to make sure your system is
> correctly configured. You need to review the differences between the old
> and the new files, and add relevant statements from the old files to the
> new files, before proceeding with tl-setup. Depending on how much has
> changed, this task can range from very simple to mindboggling. It is
> possible to simply rename the saved files to .hconf and continue using
> the old files as-is, but there are a few problems with this approach as
> well (see below).
>
> We want to improve this situation, and perhaps provides 2-3 different
> options in tl-setup, but wants to get your feedback about which options
> to include, and perhaps if any of these should be marked as default.
> There are different pros and cons with all options. This includes:
>
> * If the existing configuration is preserved or not. If not, the
> administrator has to change all relevant parameters again, using the Web
> interface, tl-config, or edit the .hconf files manually.
>
> * If the configuration is guaranteed to work good with the new version.
> Although unlikely, it is possible that the old configuration does not
> work with the new version. For example, a certain parameter value is
> perhaps longer be supported.
>
> * If default values are taken from the new or old ThinLinc version. When
> we are changing a default value, you as a customer might either prefer
> the old or new value, depending on many things. Computer code cannot
> determine what is "best".
>
> * If comments and file structure (such as the order of parameters, or
> even the file name) is preserved or not. In some cases, you might want
> to stay as close to the shipped configuration files as possible. This
> makes is easier to use tools such as "diff" to compare changes. In other
> cases, the configuration files might have a custom structure, many
> customer specific comments etc.
>
> * If new parameters are available visible in the configuration files or
> not.
>
> The different options we are discussing now are:
>
> 1) Use the "new" files from the updated packages. This is how it works
> today, if you do not do anything between running install-server and
> tl-setup. This option has the following properties:
>
> Preserves existing configuration?: NO
> Conf. guaranteed to work with new version? YES
> Default values?: NEW
> Comments and file structure?: NEW
> New parameters visible?: YES
>
> 2) Use the "old" files. The .rpmsave/.dpkg-old files are simply renamed
> into place.
>
> Preserves existing configuration?: YES
> Conf. guaranteed to work with new version? NO
> Default values?: OLD
> Comments and file structure?: OLD
> New parameters visible?: NO
>
> 3) Base the configuration on the new files, but import values from the
> old file. I have written a tool that basically loops over the parameters
> in all .rpmsave/.dpkg-old and "imports" the parameter values into the
> active configuration (which is based on the new files). This means that
> the perceived configuration (say, for end users) is the same as before
> the upgrade.
>
> Preserves existing configuration?: YES
> Conf. guaranteed to work with new version? NO
> Default values?: OLD
> Comments and file structure?: NEW
> New parameters visible?: YES
>
> I'm personally quite fond of solution 3 (migrate), so my initial idea
> was to have that as the default option in tl-setup, but also make it
> possible to opt out for such a migration, which means solution 1 (new
> files) instead (since that is what the package manager gives you). It
> would also be possible to get solution 2 (old files) by exiting tl-setup
> and, say, manually renaming files.
>
> However, we are considering other alternatives as well. This includes
> but is not limited to: not having any default, providing an option for
> solution 2 (old files) as well etc. Or perhaps the current
> implementation is sufficient?
>
> Since it's somewhat difficult to describe all this in text, I'm
> attaching a screenshot of what it could look like.
>
> What do you think? Any feedback is appreciated.
>
> Regards, ---
> Peter Astrand                ThinLinc Chief Developer
> Cendio AB                https://cendio.com
> Teknikringen 8                https://twitter.com/ThinLinc
> 583 30 Linkoping        https://facebook.com/ThinLincPhone:
> +46-13-214600        https://google.com/+CendioThinLinc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cendio.se/pipermail/thinlinc-technical/attachments/20151210/6650546a/attachment-0003.html>