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