Bug 20177
| Summary: | rpm to keep log of it's doings | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Pekka Savola <pekkas> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | aleksey, dag, george, redhat |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-12-09 09:53:53 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Request seconded. if you wnat to have just the output of a command, run the 'script file' before the particular command and you will have a log in the 'file'. I will also chime in my support for this enhancement. I'd like to see it ASAP. I agree, this would be extremely useful. I wanted something like this for ages and was thinking of putting it in Bugzilla just now. If you're administering lots of computers with a small team, one thing you need is a logbook of all changes. We've got a policy of only installing RPM-packages but there was no real way to track changes to the RPM database. (We use check-packages, but the output s*cks and the fact that it mails the output and you loose actions if things are reverted makes it sometimes useless) Another feature I'd like to see implemented (and will add here if not already so) is: + A way to lock a package so rpm won't upgrade it automatically (even won't force it) unless it is explicitely unlocked. (Maybe locking is not possible from within the RPM-package itself to avoid 'sticking' packages that you cannot uninstall or something). See it as a flag so you can tell other administrators that this package has some 'importance' attached to it. Like you could lock the kernel-package on a certain system to draw the attention that it is a custom package, or you can lock production-application to avoid they get updated by you r new colleague administrator. While I understand the need, I believe this is a system administration, not an rpm, problem. For starters, periodically saving the output of rpm -qa | sort > per-machine-manifest gets you most of what you want, i.e. package x changed at time period y on machine z. If you want/desire more specific info, you can use --queryformat to extract other information from the installed package database. 'Tain't hard, I've used a cron driven cvs checkin to watch the rot in Red Hat build tree's in the past, worked quite well IMHO. Looking at the periodic reports tells you what was removed when, try using "diff". Now for logging in rpm. If I were to implement logging, I believe that I would almost instantly get dozens of request for this or that format, I can't possibly devise a format that keeps even a plurality of people happy. Furthermore, since rpm has --root i.e. must be able to run in empty chroot's etc, logging must be able to be disabled/configured/etc, I don't believe that I can ever devise a sufficiently general and well understood reporting mechanism to be useful. In fact, using popt aliases, there's literally no reason why a disciplined system administrator can't figger a new rpm command line option to re-execute rpm within a script to log whatever information (i.e. login user/tty, date, command line options that was used, etc.) is desired for "logging". while installing/upgrading packages without changing rpm. OK, time to put on the flak suit :-). I'm gonna close this bug "WONTFIX". I think you're wrong ;-) No offense though ;-) First of all, I cannot log all changes to the RPM database as a lot of programs use libraries (either through perl, python or c) and therefor my rpm-wrapper (which I have written) is of limited use. Secondly, your first argument (that it is a system administration problem) makes no sense as rpm was there to facilitate the system administrators job. So it fits right into rpm's purpose. Finally, your second argument (that the log-format wouldn't make everyone happy) is not a real argument. This argument could be used by virtually everybody who has to implement logging. It makes no sense that you won't do it because you cannot make everybody happy with the format. Then you suggest to use something that diff's, which I'm using on all systems. It's called check-packages and is sending me a bunch of mails foor every machine every day and it can only capture changes from one day to another. There's no way I can see whether it had been uninstalled first and then reinstalled by a newer. (Which makes a huge difference than upgrading). Things like that I cannot possibly know (certainly not when applications like autodld or autorpm use libraries). The problem with the chroot and stuff can easily be fixed (log on chroot if log exists there). You could even apply that logic always (so I can touch the file to make it start logging). So, is it possible to discuss this with other RPM-developers or sysadmins inside Red Hat ? It would be greatly appreciated, even if the verdict is negative. Thanks ! |
This is, IMO, a high priority enhancement request. RPM should keep log of all changes in RPM database. This is because those funky warnings about .rpm{save,orig,new} etc. usually scroll off way too fast when upgrading a lot of packages, or are generally ignored/forgotten when something happens. Also, this serves as a very good change history and is good for debugging problems with packages. FWIW, AutoRPM records the following: --- Thu Oct 12 23:25:59 EEST 2000 - tmpwatch-2.2-1 -> tmpwatch-2.6.2-1 --- The log, logged to e.g. /var/log/rpm.log should consist of at least the following: - Upgrades and installations - Removals of packages, including those caused by Obsoletion - If anything was output, that would have to be saved in the file in a meaningful form - with --nodeps, --force, --oldpackage or the like were used, record it was used and what were the problems without the command. Some of these can be done with external programs too, but IMO, this really should be an integral feature of RPM. I'm not sure if Debian packaging system does some of this, it might be worth a look for ideas.