在本教程中，我们将探讨yum和dnf命令回滚更新和补丁的能力。

相信我，当我说时，yum和dnf的功能可以在企业中拯救生命，我将向我们解释为什么。

什么是yum history命令？

• 在企业级别，我们会不定期执行安全更新并应用补丁程序，以确保解决所有安全漏洞。

• 通常，这是通过使用YUM或者DNF的联机或者脱机存储库执行的

• 现在想象一下，作为补丁程序的一部分，服务器损坏了，或者我们可能希望恢复到上次安装的环境。在生产中，假设某件事失败，始终有一个后备或者备份选项非常重要。

• 在这种情况下，如果我们有备份，则可以从备份中恢复，但是我们不是在谈论文件，而是在讨论rpm，因此备份和恢复其中没有帮助。

• 这是yum history来进行救援的地方。

• YUM或者DNF维护并存储有关每个交易的信息的sqlite数据库。

• 历史记录是交易ID的组织术语，每次yum交易影响系统的程序包配置时都会更新。

• 通常，该数据库可以在/var/lib/yum/history /目录中找到。

• 因此，" yum history"提供了一个回滚到以前成功交易的选项，而我们不必担心降级单个软件包的麻烦。

如果可以使用yum降级，为什么还要使用yum历史记录

• 是的，这是一个有效的问题。

• 在最近的Linux发行版中，yum映射到了dnf，与处理降级的早期版本相比，它更加稳定和健壮，但是在某些情况下，我们仍然会遇到问题。

• 例如，在更新X rpm时，yum将作为依赖项的一部分安装某些rpm，但在降级X rpm时，它将无法删除那些额外安装的依赖软件包。

• 我们可以参考官方的yum Wiki，以了解有关降级问题的更多信息

• 使用yum history，我们可以将此处理留给yum来确保它会还原所有交易。

使用yum历史记录的任何风险，何时应使用yum历史记录回滚

• 坏消息来了，" yum history rollback"和历史相关的论点确实存在一些风险。

• 不支持将" selinux"，" selinux-policy- *"，"内核"，" glibc"(例如gcc的glibc的依赖项)软件包回滚到旧版本。

• 因此，不建议将系统降级为次要版本，因为这可能会使系统处于不希望的状态。

• 我们应将"历史记录历史记录"选项用于"仅小更新回滚"。

• 当yum rollback无法还原事务时，我个人遇到过selinux的问题。尽管系统仍将处于可用状态，因为除非满足所有依赖条件，否则yum不会继续进行。

警告：

使用撤消和回滚之类的历史记录选项时，请务必小心。
Yum会尽力做到这一点，但是它无法还原配置，并且如果我们编辑了配置文件，它将不会还原以前版本的配置文件。
如果我们没有任何备份，则这不是故障安全选项。
其次，如果我们使用rpm命令添加/删除/修改任何rpm，则这些事务在yum历史记录中将不可见，并且在尝试对yum执行撤消，重做或者回滚操作时也会引起冲突。

如此多的理论解释，让我们跳入实际的例子。

1.列出所有的Yum交易

使用不带任何其他参数的yum history命令来列出所有交易

# yum history

Yum历史

• "第一列"包含每笔交易的ID。我们将使用这些ID来执行任何带有yum历史记录的操作

• 第二列显示了在终端上用yum或者dnf执行的命令

• "第三列"提供了执行相应命令时的日期和时间信息

• "第四列"提供了与yum或者dnf一起使用的操作。 " I，U"表示安装和更新均已完成。在那行中，我执行了yum install kernel，但是yum内部决定也升级一些依赖于内核的软件包

• 第五列显示已更改的rpm数，即已安装/移除/修改的rpm

2.获取在单个事务中安装或者删除的软件包的列表

现在上面的输出是简短的，因为我们知道在事务ID为38的情况下，更改了3 rpm，但要获取有关这些rpm和执行的操作的更多信息，我们将使用：

# yum history info <transaction id>

Yum历史信息

因此，其中我们了解有关此事务和已更改的程序包的更多详细信息。

3.获取单个rpm的yum交易历史记录

如果我们希望在更改特定程序包时获取交易ID列表，则可以使用

# yum history info <pkg_name>

这将为我们提供所有交易历史记录的列表，以及来自相应交易的其他相关详细信息。
例如，其中我想获取更改内核软件包时的事务ID列表。

Yum历史信息内核

要仅获取事务ID，我们可以在此命令中添加grep，如下所示：

从yum历史记录中获取交易ID

4.撤销Yum交易

现在回到过去是不可能的，但是在yum和dnf中是可能的

yum history undo将需要访问所有以前的RPM版本；因此，需要确保较早的RPM版本对系统可用。
建议在进行更新之前，仔细检查" package-cleanup --orphans"的输出，以了解当前已安装的RPM在启用的存储库中不再可用。

我已经安装了ID为42的abrt软件包。

42 | install abrt             | 2017-08-22 14:04 | Install        |   18

现在，我不再需要它了，所以让我撤消此事务：

# yum history undo 42

Yum历史撤消

因此，将还原/删除作为事务ID 42的一部分安装的所有软件包。

5. YUM重做交易

该命令将重新执行特定事务(由事务ID定义)，如下所示：

# yum history redo 42

因此，在此命令中，我们将重新执行与交易ID 42相同的操作，即安装abrt及其所有依赖包

6. YUM回滚到历史上的某笔交易

现在，此命令非常有用且同样危险，因为它会将所有与yum相关的事务还原为我们提供给YUM的ID。
在此示例中，我们将Linux服务器恢复为事务ID 45的状态，在该状态中我将python3-bind降级了。
如果尝试回滚到非常旧的事务，则由于一个或者另一个依赖关系，回滚也可能永远不会进行。

因此，我将尝试回滚到最近的yum事务：

45 | downgrade python3-bind-9 | 2017-08-22 14:13 | Downgrade      |    5

在此示例中，我将回滚到事务ID 45，

# yum history rollback 45

如我们所见，yum即将进行5次升级，21次降级，并将通过此回滚删除31个其他软件包。

当我尝试对更多先前的事务执行" yum rollback"操作时，出现以下错误：

Yum历史回滚失败