Re: RH tools and conf changes (was: Re: Vi backspace key problem)

[Dag Wieers <dag wieers com>]

On Thu, 21 Jul 2005, Chester R. Hosey wrote:

> On Thu, 2005-07-21 at 18:30 +0200, Dag Wieers wrote:
> > On Thu, 21 Jul 2005, Chester R. Hosey wrote:
> > 
> > You're very good in giving examples that look nice, but that are nowhere 
> > close to real life examples :) Again, I like the idea if only reality was 
> > clear-cut like this.
> 
> But it's not a contrived example. Even if the diff output is useless, so
> what? It's a code path that the software is hitting -- it likely knows
> what package it's working with, and it has to know which configuration
> files it's choosing to upgrade. There's code RIGHT NOW that makes
> the .orig file. It's in place. It's not hypothetical, and it would be
> possible to add code that calls a user-specified routine when that
> branch is chosen.

Sure. And if you think that is useful, ask for the feature. However you 
RPM already supplies you with enough information to do this already (given 
your system was in a certain state just before).


> How is that nowhere close to a real life example? Are you offended
> simply because my diff is contrived? Take out the diff. Just let me know
> which package and file were involved, and let me go from there.

It's the best case example. And it does not show any user changes. What 
you did only works if the user did not make any changes and the config 
file only has changes where it matters and is useful.

In most cases it's much less useful to do a diff simply because the 
(previous) original config file is no longer there and much more 
unimportant changes have been made to the new config file. (like comments)


> > I already made the case that this functionality is never/seldom required 
> > when you stay within RHEL3 or RHEL4 updates and that Red Hat does not 
> > support upgrades.
> 
> And I admitted ignorance with respect to upgrades not being supported.

Well, Ed seems to indicate upgrades using anaconda work and are supported 
:) Ignorance on my part perhaps ?

But even if it is supported, other than cleaning up the .rpmorig and 
.rpmsave files I don't see any pactical alternative.


> > Now, when this is most useful is when you go from RHEL3 -> RHEL4. I 
> > encourage you to diff config files from eg. Apache or other applications 
> > that have a new major release. In lots of cases there are fewer 
> > similarities than differences. Often comments or sections have been 
> > moved/removed, files being placed in another directory structure, ...
> 
> So your argument is that a diff isn't that useful? So take out the diff.
> Just tell me that my custom configuration was overwritten.

Well, it's not that simple. RPM only overwrites a config file in certain 
conditions. In most cases (where it matters) the file is not replaced.


> > So you can't do it automated or the results are not very useful if you do. 
> > And the user will have to manually go through the changes anyway to make 
> > sure things are adapted the way he wants. So an external tool that aids 
> > him doing that is probably easiest.
> 
> Sure, but let the user know which systems might need attention.

Well, if you do that some people might rely only on that information. And 
you'll have false positives and false negatives. (ie. stuff when you don't 
warn and do break or stuff where you warn and everything is ok)


> > Imagine a tool, that acts like:
> > 
> > 	# mytool --list
> > 	/etc/myapp.conf from package myapp has an updated config file		<- .rpmnew
> > 	/etc/yourapp.conf from package yourapp is a replaced config file	<- .rpmsave
> > 
> > And
> > 
> > 	# mytool --fix
> > 
> > would then go through each of the files, show a diff, allow you to edit 
> > (and show the diff again), allows to replace, delete, backup, ...
> > 
> > In that case you could (if you want) have cron run mytool --list every day 
> > (or whenever you update your system) and follow up on changes, have a 
> > backup of every change (and the original files) and better control of what 
> > happens to your system.
> > 
> > Add dconf to this and you also have revisions of all changes 
> > independently. Now, who wants to help ? :)
> 
> That's a great idea, and a wonderful solution.
> 
> Of course, it's totally unnecessary if RHN notifies admins when a well-
> defined code branch was executed that might do something the admin
> didn't anticipate.

Again, how would it know ? A change in config-file does not always reflect 
this or might give you the idea that something has changed when it has 
not. (false-negative, false-positive)


> As I see it, overwriting custom configuration is something that a tool
> should warn you about, even after the fact. RPM isn't meant to be
> informative or interactive? Fine! Roll it into a RHN somehow. It's a
> reasonable feature to ask for. If it weren't reasonable that you might
> expect automated notification of potential breakages, why did you ever
> envision a tool that would look for evidence of exactly this situation?

When the system overwrites a configuration file it often is ok :) It's the 
times it doesn't that are most likely the scary ones. But not all of them.

And that's the real problem, how to filter the signal from the noise. 
Packages need extra metadata for that and it's an afwul lot of manual work 
if you want to do it correctly.

If you'd require that extra work from me, I'd drop packaging instantly. 
And so will many others, I'm sure.

Kind regards,
--   dag wieers,  dag wieers com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]