Bug 75344 - RFE: /var/log/rpmpkgs should show changes to RPM installs/updates/deletes
RFE: /var/log/rpmpkgs should show changes to RPM installs/updates/deletes
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-07 10:44 EDT by Tom Wood
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-10-10 16:51:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Wood 2002-10-07 10:44:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
It would be nice for the redhat-logviewer to not list only the existing
installed packages, but to show changes that have been made over time.

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


How reproducible:
Always

Steps to Reproduce:
1.Run redhat-logviewer.
2.Select RPM Packages
3.Notice nice, sorted list of apps.
4.Notice nothing about configuration file manipulations, warnings about
heavily changed configurations, etc.
5.Watch n00b admin scratch head wondering what's changed and how...
	

Additional info:

Automatic updates through RHN are sometimes problematic in the sense that
configuration files aren't easily dealt with.  I've done "up2date -u" before
when I shouldn't have, especially with infrastructure servers such as mail, web,
and DNS servers, where the new configuration schemas weren't compatible with the
existing configurations (bind 9 from a few months ago comes painfully to mind).
 It would be nice if the logviewer noted changes, especially those where configs
are radically altered.
Comment 1 Tammy Fox 2002-10-09 10:28:16 EDT
This is a nice RFE.  However, redhat-logviewer just read the /var/log/rpmpkgs
file generated by /etc/cron.daily/rpm from the rpm package. Changing to correct
component.
Comment 2 Tom Wood 2002-10-09 15:19:21 EDT
Why did someone bother with creating this daily cron job, when "rpm -qa" on the
fly (1) doesn't take that long to run and (2) is at least as correct if not more
so than "rpm -qa".  If you've had changes that day, you can't rely upon this
tool giving you the current status of your RPMs.

I would submit that redhat-config-logviewer needs to run "rpm -qa" and do away
with a static, potentially out-of-date file reference.
Comment 3 Jeff Johnson 2002-10-09 15:22:06 EDT
rpm -qa assumes that you have a functional database,
the cron job is for disaster recovery when you don't
have a database.
Comment 4 Tom Wood 2002-10-10 10:02:20 EDT
Please explain how the cron job is for disaster recovery.  It doesn't seem to
copy/backup the real rpm database.  Therefore, how can it be used in the case of
the rpm database being corrupted to the point of uselessness.

I for one would like to see more robustness vis a vis the rpm database.  On a RH
system, it's one of the most critical and most fragile parts of the distro.
Comment 5 Jeff Johnson 2002-10-10 10:08:30 EDT
The list of package names installed can be
used as a manifest to reconstruct the
database using --justdb.

IMHO, the rpmdb is neither critical or fragile,
but rather a pile of redundant and reconstructable
data given the installed package manifest.
Comment 6 Tom Wood 2002-10-10 16:51:07 EDT
Well, will the limits of my ignorance ever be fully charted? ;-)

Thanks for enlightening 
me.


Comment 7 Jeff Johnson 2002-10-25 15:23:24 EDT
The major issue for running an install (and erase, harder)
log is where to put the data, and how to maintain integrity
and accuracy when, say, there are multiple clients with
different versions of rpm all doing installs. There's no
easy answer here, so an implementation can't be attempted.

Running rpm -qa cron more frequently, and saving diffs
periodically is probably the best answer ATM.
Comment 8 Tom Wood 2002-10-29 12:38:44 EST
Please clarify what you mean when you say "there are multiple clients with
different versions of rpm all doing installs".  I don't see how this applies to
the normal case where you have a single version of rpm on a machine at a time.

Is it so hard to track configuration file changes in a semi-sane manner?  In the
last 4 versions or so, we've moved from usually (but not universally) replacing
config files and saving the old ones as *.rpmorig or some such, to not replacing
the config files and calling these *.rpmnew.

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