Red Hat Bugzilla – Bug 75344
RFE: /var/log/rpmpkgs should show changes to RPM installs/updates/deletes
Last modified: 2008-05-01 11:38:04 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):
Steps to Reproduce:
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...
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.
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
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.
rpm -qa assumes that you have a functional database,
the cron job is for disaster recovery when you don't
have a database.
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.
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.
Well, will the limits of my ignorance ever be fully charted? ;-)
Thanks for enlightening
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.
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.