Who installed that?
Yum is more than just a way to install applications – it can do all sorts of interesting stuff.
Alot of Red Hat users never get beyond yum install tmux -y or basic package installation. However, when things go wrong, there is a golden Yum
parameter switch that may help save the day. And Yum is also useful for seeing who did what and when!
The Yum command has a history parameter that is useful for troubleshooting. On an RHEL/Rocky/
RH server, it enables administrators to see who ran what command, the issues, the operation with packages and even what the system did during the configuration. Was a package installed, removed, upgraded or removed? Yum history can tell you.
Unfortunately, yum history or dnf history functionality is unique to Yum-based servers. There is no similar functionality in Apt package management systems. Apt has some commands such as apt list but nothing quite as good. A lot of the history of what was installed and when is available in /var/log/apt/history.log
if needed, but be aware that this log may get rotated, so long-term install information may be lost.
As a real-world example, a few weeks ago we had a scenario where a package on a system was being upgraded but not fully completed, but we didn’t know what was causing the issue. Using the yum history
command, we were able to locate what was going on and could address the issue. It turned out that it was erasing a package but not completing the replacement of said package.
By itself, the yum history command shows what has been happening and the number of changes
Yum implemented. A fresh VM with just an Apache2
installation is shown below. Using sudo yum history
gives a useful tabular output. Sometimes the output truncates to a single letter or series of letters depending on what the Yum command did: I is install, U is upgraded, E is erased, R is reinstalled and D is downgraded.
Each ID represents the output of some Yum
command interaction. The ID field is important as many of the commands need a transaction ID to work against.
If you want to dive in deeper than just the command line and date and time, there is a new parameter to use: info. To see the changes made in the initial system update, for example, we can use yum history info 2 to give us all the details of packages that were upgraded, installed or removed, as well as the completion status.
Notice the User field – on a properly configured RHbased system, it has the value of who ran the command.
Now that the basics of the yum history command are out there, let’s talk about the real magic. As part of the Yum system, it is possible to roll back a transaction. This doesn’t remove the need for a backup but it can be useful if something suddenly doesn’t work. To initiate a rollback is quite straightforward: just use yum history undo 3 in our case to remove Apache2. That operation generates a transaction ID that you could use for the
Yum history info. A word of caution, however…
This isn’t guaranteed to work in every scenario. When looking to undo standard package installations, there should be no issue. We wouldn’t dream of undoing (reverting) after a Yum update command, though, because there are too many moving parts and potentially significant changes. That kind of scenario is where VM snapshots come into play and make a revert to the previous working state easy.
As with most commands, a full breakdown of the command (and the other useful commands) can be found using man yum .
As a parting gift, another useful Yum command is yum downgrade . As the name suggests, this enables an administrator to downgrade the current version of a package to a lower version if required.
There are many save-my-backside tools built into
Yum/DNF. It’s just a case of knowing what is there and how it can be used effectively.