[Thinlinc-technical] Migrate configuration during ThinLinc upgrade

Peter Astrand astrand at cendio.se
Mon Dec 14 12:26:10 CET 2015 

Hi, comments inline:

On Fri, 11 Dec 2015, Carsten Rose wrote:

> Dear Peter
>
> IMHO:
>
> - using hiveconf is ok, but at least for me unsual. I know no other packages 
> which uses this library.

Correct. This project never gained any momentum outside ThinLinc. Some 
projects uses GConf, which uses XML files. GConf is deprecated though and 
GConf is now replaced by GSettings, which uses binary files.

Other project such as Samba, KDE etc uses text files similar to Hiveconf, 
but has their own backend implementation/API. Hiveconf also does not have 
any C backend (yet...) so only usable for Python and shell script 
projects.

We could consider migrating away from Hiveconf, but I have the impression 
that text based configuration files are appreciated by many admins 
(compared to XML or binary). Let us know if you think otherwise.


> - loosing all settings with every update is not state of the art (this is 
> probably why you discuss it now ;-) ). Copying back old configuration files 
> and manual search for differences is ... bad.
>
> - as an administrator, I would expect that tl-setup will do most of the job 
> for me:
> - respect my old settings,
> - warn me (and ask what to do), if there are conflicts.

Wrt conflicts: For the case when a parameter value has been changed both 
by you and by us, it would in principle be possible to provide a GUI that 
warns about this - one parameter at a time - but that would require 
additional work, and also requires that we first solve 
https://www.cendio.com/bugzilla/show_bug.cgi?id=5750 . I'm afraid it might 
be difficult to find the time to do this in a near future.


> - the suggested way (example image) would be an improvement against the 
> status quo, but maybe more is possible? For me, it looks like 'how can cendio 
> improve the situation by still using hiveconf'.

Glad to hear that you believe this is an improvement.


> - do not forget: unattended installation is a 'must have'. Unattended upgrade 
> would make this fantastic product 'thinlinc' even better.

We added an unattended mode to tl-setup in version 4.4, but it currently 
requires that you deal with config files manually.

If we would include the suggested support for config migration, the choice 
for migrating the configuration can be controlled by the tl-setup 
unattended "answer file".


Br,
Peter

>
>
> On 10.12.2015 14:41, Peter Astrand wrote:
>>
>>  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/ThinLinc
>>  Phone: +46-13-214600    https://google.com/+CendioThinLinc
>> 
>>
>>  _______________________________________________
>>  Thinlinc-technical mailing list
>>  Thinlinc-technical at lists.cendio.se
>>  Manage your subscription:
>>  http://lists.cendio.se/mailman/listinfo/thinlinc-technical
>> 
>
>
> -- 
> Carsten Rose
> IT Koordinator / Institut für Mathematik
>
> *****
> Universität Zürich
> Carsten Rose
> Institut für Mathematik, Y27-J40
> Winterthurerstrasse 190
> CH-8057 Zürich
>
> +41 44 635 58 47 Telefon
> +41 44 635 57 05 Telefax
>
> www.math.uzh.ch
> carsten.rose at math.uzh.ch
>
> "There are 10 kinds of people in the world, those
> that understand binary .. and those that don't"
> _______________________________________________
> Thinlinc-technical mailing list
> Thinlinc-technical at lists.cendio.se
> Manage your subscription:
> http://lists.cendio.se/mailman/listinfo/thinlinc-technical
>
>


---
Peter Astrand		ThinLinc Chief Developer
Cendio AB		https://cendio.com
Teknikringen 8		https://twitter.com/ThinLinc
583 30 Linkoping	https://facebook.com/ThinLinc
Phone: +46-13-214600	https://google.com/+CendioThinLinc

More information about the Thinlinc-technical mailing list