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

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.

Chet