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

["Chester R. Hosey" <Chester Hosey gianteagle com>]

On Thu, 2005-07-21 at 18:30 +0200, Dag Wieers wrote:
> On Thu, 21 Jul 2005, Chester R. Hosey wrote:
> 
> > On Thu, 2005-07-21 at 17:01 +0200, Dag Wieers wrote:
> > > On Thu, 21 Jul 2005, Chester R. Hosey wrote:
> > > 
> > > > On Thu, 2005-07-21 at 03:56 +0200, Dag Wieers wrote:
> > > > > On Wed, 20 Jul 2005, Chester R. Hosey wrote:
> > > > > 
> > > > > > On Wed, 2005-07-20 at 02:34 +0200, Dag Wieers wrote:
> > > > > > 
> > > > > > It's a nice feature. It would be nice if up2date-with-rpm did something
> > > > > > similar, or if RHN noted that an upgrade didn't include a configuration
> > > > > > file update due to user changes. I'd be really impressed if RHN went to
> > > > > > far as to provide a diff of the configuration files so the administrator
> > > > > > could evaluate the importance without having to log in and search
> > > > > > for .rpm{new|save|orig} files manually.
> > > > > 
> > > > > I don't think it belongs as part of RHN, besides I don't think you can 
> > > > > implement all the complexity correctly, which would only become a 
> > > > > liability to Red Hat if they have to support it.
> > > > 
> > > > I'm not asking for "all of the complexity". I'm asking for "RHN
> > > > (including the tools used to implement functionality) notifies me when
> > > > it makes a decision that may require further review." I provided an
> > > > example of one such solution that's worked well for me in the past. It's
> > > > a solution that specifically _doesn't_ make decisions for me. RPM is
> > > > meant to be unattended. I suppose I fail to see how this precludes
> > > > notifications when certain conditions arise, especially ones which are
> > > > associated with existing well-defined program behavior.
> > > 
> > > I fail to see when this system would notify you. When a keyword in a 
> > > config-file suddenly isn't valid anymore ? When a new keyword is 
> > > introduced ? When behaviour of a program changes ? When config files move 
> > > to other locations ? Are you going to check config-files to exclude false 
> > > positives ?
> > > 
> > > That's the complexity I was talking about. Luckily this never/seldom 
> > > happens within the same release. And when doing a distribution upgrade I 
> > > much rather have the sys-admin check all services and availability than 
> > > having him rely on a uncertain logic :)
> > 
> > Ouch! I'm not that ambitious! I'm talking only about the case that RPM
> > decides not to install a new (default) version of a configuration file.
> > My impression is that this can happen as a result of any local change to
> > the configuration file. This wouldn't be a change in behavior. It would
> > merely be a notification explaining what the software does now in the
> > event that something was done that might have affected a local change
> > made by the administrator.
> 
> In fact, RPM already tells you when it replaced (or didn't replace) a new 
> config file.
> 
> 
> > You could argue that many events _might_ be worthy of notification; RHN
> > already allows the option for daily emails upon certain events.
> > Administrators could choose which events they care about, and RHN would
> > tailor notification accordingly.
> >
> > Basically the notification would be in the form:
> > 
> > 
> > Hello from RHN!
> > 
> > During some an upgrade of the "meat" package on system hypothetical-
> > box-7.example.com, RPM noticed that some changes were made from the
> > original default settings in /etc/somefile.conf and Chet Hosey would be
> > much happier if we let you know about it. This file was updated to the
> > new default format. It would definitely be a good idea for you to log in
> > and take a look at the situation; the original was saved
> > as /etc/somefile.conf.orig in case you didn't have it memorized.
> > 
> > Here's a diff of the files:
> > 
> > --- somefile.conf.orig  2005-07-21 11:21:37.450497928 -0400
> > +++ somefile.conf       2005-07-21 11:21:35.179843120 -0400
> > @@ -2,7 +2,7 @@
> >  # meat version 3.0rc7
> > 
> >  ham=good
> > -bacon=great
> > +bacon=good
> >  canadianbacon=good
> >  steak=great
> >  swordfish=bad  # endangered
> > 
> > Thanks for using RHN!
> > 
> > 
> > It's my impression that this already describes what happens, but there
> > is no gratuitous attempt to please me by sending an explanation forward.
> 
> 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.

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.

> 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.

> 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.

> 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.

> 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.

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?

Chet