要阻止linux系统中特定软件包更新，可针对不同发行版使用相应方法。对于rhel/centos系系统，可通过在/etc/yum.conf或.repo文件中添加exclude=包名来排除升级；对于debian/ubuntu系系统，则使用sudo apt-mark hold 包名命令锁定版本。这两种方式分别支持通配符与单包控制。锁定后，可通过查看配置文件或执行apt-mark showhold命令检查被锁定的包。长期锁定可能带来安全漏洞和依赖问题，因此应记录锁定原因、定期审查、最小化锁定范围，并考虑使用容器等高级方案以降低风险。
当你在Linux系统上运行服务或进行开发时，有时会遇到这样的情况：你希望系统保持更新以获取最新的安全补丁和功能，但又不希望某个特定的软件包被升级。这可能是因为新版本与你的应用不兼容，或者你需要一个特定的旧版本来维持稳定性。在这种情况下，你可以通过包管理器的排除机制来实现，对于RHEL/CentOS系系统，我们使用yum exclude（或dnf exclude），而对于Debian/Ubuntu系系统，则使用apt-mark hold。
要实现软件包的更新排除，我们主要依赖两种机制，分别对应Red Hat系和Debian系的包管理器。
对于基于RPM的系统（如CentOS, RHEL, Fedora，以及它们的新一代包管理器DNF），你可以通过编辑配置文件来排除特定软件包。最常见的方法是在/etc/yum.conf（或/etc/dnf/dnf.conf）中添加exclude指令。你也可以在特定的.repo文件中添加这个指令，这样就只对那个仓库生效。
比如，如果你想阻止nginx和所有以php-开头的包更新，你可以在/etc/yum.conf里这样写：
[main] # ...其他配置... exclude=nginx php-*
这行配置意味着，无论是你运行yum update还是dnf update，这些被列出的包都会被跳过。如果你只想对某个特定的软件源（比如EPEL）生效，你可以编辑/etc/yum.repos.d/epel.repo文件，在对应的[epel]部分下添加exclude。这种方式很强大，因为它能持久化，并且支持通配符。
而对于基于Debian的系统（如Ubuntu, Debian），机制就有所不同了，它更像是一个针对包状态的标记。apt-mark hold命令可以将一个软件包标记为“持有”（held）状态。一旦被标记，apt就不会自动升级、安装或移除这个包，除非你明确地用install或remove命令指定它。
要“锁定”一个包，比如apache2：
sudo apt-mark hold apache2
你会看到类似“apache2 set on hold.”的提示。想解除锁定，也很直接：
sudo apt-mark unhold apache2
这样，apache2又可以正常更新了。这种方式的好处是操作简单直接，不需要编辑配置文件，但它只针对单个包生效，不直接支持通配符。
为什么有时候需要阻止软件包更新？
我个人在运维实践中，遇到过不少次不得不“冻结”某个软件包版本的情况。最常见的原因，大概就是兼容性问题了。你可能有一个老旧的、但至关重要的应用程序，它就是依赖某个特定版本的库文件才能跑起来，一旦库升级了，整个应用就可能崩溃。这种痛点，我相信很多开发者和运维人员都深有体会。
还有就是稳定性考量。对于生产环境，我们追求的是极致的稳定。新的软件包版本固然带来了新特性和bug修复，但也可能引入新的、未知的bug。在没有经过充分测试之前，贸然升级风险太大。所以，暂时锁定版本，然后在独立的测试环境里跑一遍完整的回归测试，成了标准操作。
另外，自定义配置的冲突也是一个重要原因。有时候我们会对某个服务进行大量个性化配置，或者打了一些补丁。软件包升级时，这些配置或者补丁可能被覆盖，导致服务行为异常。为了避免这种“惊喜”，暂时阻止更新，然后手动处理升级后的配置合并，是更稳妥的做法。
排除更新后，如何检查和管理被锁定的软件包？
锁定了软件包，后续的管理和检查同样重要。毕竟，你不能锁了就忘了它。
对于yum或dnf，检查起来相对直观。你直接去查看你修改过的配置文件就行了：/etc/yum.conf或者/etc/dnf/dnf.conf，以及那些你可能添加了exclude指令的/etc/yum.repos.d/*.repo文件。用cat或者less命令快速浏览一下，就能知道哪些包被永久排除了。这其实也是一种自文档化的方式，因为配置就在那里。
cat /etc/yum.conf # 或者 grep -r "exclude" /etc/yum.repos.d/
解除排除也很简单，直接把对应的exclude行从配置文件里删除或者注释掉就行。
而apt-mark hold的检查方式就更直接了。apt提供了一个专门的命令来列出所有被“持有”的软件包：
apt-mark showhold
这个命令会清晰地列出所有当前处于hold状态的软件包名称。如果你想解除某个包的hold状态，前面也提到了，就是用apt-mark unhold <package_name></package_name>。这种方式的好处是，你不需要记住修改了哪个文件，apt自己会告诉你。
长期锁定软件包可能带来哪些风险和最佳实践？
虽然锁定软件包在特定场景下是必要的，但把它当作一个长期解决方案，可能会带来一些不容忽视的风险。
首当其冲的就是安全漏洞。软件包的更新往往包含了重要的安全补丁。如果你长期锁定一个版本，就意味着你的系统可能暴露在已知的安全漏洞之下，这对于任何生产环境来说都是非常危险的。我见过不少因为不及时更新而导致系统被入侵的案例，其中不乏因为某个关键服务被锁定而未能打上补丁的情况。
其次是依赖关系问题。随着时间的推移，其他软件包可能会升级，并开始依赖新版本的库或组件。如果你锁定的那个包迟迟不更新，最终可能会导致整个系统陷入“依赖地狱”，其他软件无法安装或升级，因为它们找不到所需的依赖。
那么，最佳实践是什么呢？
明确和记录锁定的原因。每一次锁定都应该有充分的理由，并且把这个理由记录下来。这有助于你和你的团队理解为什么这个包被锁，以及何时可以考虑解除锁定。
设定定期审查机制。锁定不是一劳永逸的。你应该定期（比如每月或每季度）审查所有被锁定的软件包，评估是否有必要解除锁定，或者是否有新的版本可以安全地升级。这通常涉及到在隔离的测试环境中进行升级和兼容性测试。
再者，优先考虑最小化锁定范围。只锁定那些确实会导致问题的核心包，而不是一股脑地锁定所有相关包。越是精细的控制，风险越小。
最后，考虑使用更高级的版本控制策略。对于某些关键应用，如果仅仅是简单的排除不足以满足需求，你可能需要考虑更复杂的版本管理工具，或者干脆将应用程序容器化（比如使用Docker），这样可以更精确地控制其运行环境和依赖版本，与宿主机的软件包更新解耦。锁定软件包，更多时候是一个权宜之计，而不是终极答案。
