Bug 135510 - [INVESTIGATE] Robust Configuration management across upgrades
Summary: [INVESTIGATE] Robust Configuration management across upgrades
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Warren Togami
QA Contact: Mike McLean
URL:
Whiteboard:
: 138970 (view as bug list)
Depends On:
Blocks: FC4Target
TreeView+ depends on / blocked
 
Reported: 2004-10-13 07:19 UTC by Warren Togami
Modified: 2007-11-30 22:10 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-03-29 07:47:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Warren Togami 2004-10-13 07:19:25 UTC
Description of problem:
gdm when upgraded always resets /etc/X11/gdm/gdm.conf back to
defaults.  RH's gdm package explicitly does not use %config(noreplace)
because in the past the gdm.conf file format or required keys changed.

This is a huge hassle for system administrators who need non-default
settings in gdm.conf.  For the long term we should work on some
mechanism for clean settings migration during upgrades.

Version-Release number of selected component (if applicable):
gdm-2.6.0.5-4

Comment 1 Ray Strode [halfline] 2004-10-13 07:52:41 UTC
For reference, noreplace was removed because of bug 71309.

What kind of mechanism do you have in mind?  The only sensible
mechanism I can think of would be to make sure newer GDM releases
support older config files.  

It's been 2 years since bug 71309.  We probably need to see if this is
still a real problem.  It seems quite conceivable to me that the
config format has stabilized and/or GDMs backward compatibility has
improved since then.

Comment 2 Warren Togami 2004-10-13 08:07:14 UTC
If we add %config(noreplace) back, it will keep the old gdm.conf
during an upgrade from ANY old version of gdm.conf will be retained. 
We totally have not tested old gdm.conf with our gdm, so the result
may be totally unexpected and difficutl to support.

http://www.courier-mta.org/sysconftool/
I had in something something like this used by courier and cone.

https://bugzilla.fedora.us/show_bug.cgi?id=1457#c13
Read this for a short description of what it does.

Perhaps Sam Varshavchik has ideas or could provide clarification?

Comment 3 Sam Varshavchik 2004-10-13 11:09:48 UTC
The proper place to add sysconftool support would be in the upstream
package, otherwise for each release you'll have to go through the
upstream configuration file, figure out what's changed, and manually
augment the configuration file with sysconftool's metadata.

Upstream will also have a better grasp on what's changed in the config
file; what's new; what's been obsoleted; and what has changed that's
not backwards compatible, and must be reset to the default.


Comment 4 Bill Nottingham 2004-10-13 20:17:48 UTC
It's a matter of which you want, really:

- do you want each upgrade to overwrite local config and start
  correctly with the wrong config?
- do you want an upgrade to a non-compatible version to immediately
  stop working, so you know that it needs fixed?

The second seems simpler, and is consistent with what we do for
many other packages (sendmail, vsftpd, etc.)

Comment 5 Sam Varshavchik 2004-10-13 23:01:50 UTC
A proper application of sysconftool; and a well-designed configuration
proper, gives you the best of both worlds.  You have control over each
individual configuration setting; the metadata will specify whether
each individual setting is to be left alone, or reset to a default. 
You will also indicate which settings have been removed, and which
settings are new and must be added to the configuration file.

sysconftool is logically equivalent to RPM's %config directive, except
that it's granularity is on a per-configuration setting basis.

Or, another way to put it, sysconftool places an arbitrary version tag
on each individual setting.  With sysconftool, each upgrade installs a
new configuration file, except that settings common to the old and the
new configuration file, and that carry the same version tag, are
carried forward.

Generally, when upgrading to a point minor release, speaking in a very
general sense, what - 90%? - of all configuration settings will remain
the same.


Comment 6 Warren Togami 2004-10-20 04:46:22 UTC
We should investigate sysconftool (and other approaches) as an option
to solve this and similar problems for hopefully FC4.  Reassigning to
distribution as this most likely would be useful for many other
packages too.

Comment 7 Bill Nottingham 2004-10-20 05:21:29 UTC
The correct way to fix this is to change the RPM algorithm.

Comment 8 Warren Togami 2004-10-21 10:43:21 UTC
I am in disagreement that changing the RPM algorithm is robust and
fine grained enough to do what is needed.  IMHO, what you suggest with
diff and merging is far too limited and error prone, but I am
interested to see study these existing implementations.  I wish to
investigate better options *like* sysconftool.  And of course whatever
is implemented would need to be accepted upstream, because it is too
much of a maintenance burden to manually generate configuration
metadata downstream.

Setting this as a FC4Target to keep it on the radar.

Comment 9 Warren Togami 2005-03-29 07:47:45 UTC
While gdm still sucks for wiping out its config file on upgrade, I have no time
to fix this.  If someone else cares they need to work with the upstream GNOME
Project.  WONTFIX


Comment 10 Ray Strode [halfline] 2005-04-12 21:27:26 UTC
*** Bug 138970 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.