当前位置：首页 > 文章列表 > 文章 > linux > Linux自动更新设置：yum与apt配置教程

Linux自动更新设置：yum与apt配置教程

2025-07-22 12:54:28 0浏览收藏

文章不知道大家是否熟悉？今天我将给大家介绍《Linux自动更新设置：yum与apt配置详解》，这篇文章主要会讲到等等知识点，如果你在看完本篇文章后，有更好的建议或者发现哪里有问题，希望大家都能积极评论指出，谢谢！希望我们能一起加油进步！

Linux系统设置自动更新策略需根据环境权衡利弊，生产环境应谨慎对待。1. 对于Debian/Ubuntu系统，使用 unattended-upgrades 包实现自动更新，配置 /etc/apt/apt.conf.d/50unattended-upgrades 文件，指定允许更新的源、黑名单包、是否移除无用依赖、是否自动重启及时间；2. 启用自动执行通过 dpkg-reconfigure 命令生成周期任务配置文件；3. 对于RHEL/CentOS/Fedora系统，使用 dnf-automatic 或 yum-cron，配置 automatic.conf 文件，设置更新类型、通知方式、是否自动重启；4. 自动更新适合非关键系统，提升安全性并降低维护成本，但生产环境存在破坏性更新、不可预测停机、回滚困难等风险；5. 为确保可靠性，建议限制更新范围、设置合理重启策略、建立通知机制、定期检查日志、实施快照与备份、测试环境先行；6. 其他更新策略包括计划性手动更新、补丁管理工具、容器化部署、内核热补丁及安全审计，选择策略应基于业务需求与风险承受能力。

Linux如何设置系统自动更新策略？_Linuxyum和apt自动升级配置

Linux系统设置自动更新策略，主要是通过配置包管理器（如Debian/Ubuntu的APT或RHEL/CentOS的YUM/DNF）的自动化工具来实现。这通常是为了及时获取安全补丁和错误修复，但对于生产环境，我个人觉得这事儿吧，得特别小心，权衡利弊。

解决方案

对于Debian/Ubuntu系统 (使用APT)

核心是使用 unattended-upgrades 包。

安装 unattended-upgrades：

sudo apt update
sudo apt install unattended-upgrades

配置自动升级选项： 编辑 /etc/apt/apt.conf.d/50unattended-upgrades 文件。这个文件里有很多注释，很详细。你需要关注几个关键点：
- Unattended-Upgrade::AllowedOrigins: 确保它包含了你想要自动更新的源，通常是安全更新（${distro_id}:${distro_codename}-security）和常规更新（${distro_id}:${distro_codename}-updates）。我通常会把 updates 也打开，除非有特殊需求。
- Unattended-Upgrade::Package-Blacklist: 如果有你绝对不想自动更新的包，可以在这里列出来。
- Unattended-Upgrade::Remove-Unused-Dependencies: 设置为 "true" 可以自动移除不再需要的依赖包，保持系统整洁。
- Unattended-Upgrade::Automatic-Reboot: 如果内核更新了，系统可能需要重启。设置为 "true" 会在必要时自动重启。Unattended-Upgrade::Automatic-Reboot-Time 可以指定重启时间，比如 "03:00"。我通常会设个半夜时间，减少影响。
一个简化的配置示例（你可能需要根据实际情况调整）：
```
// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::AllowedOrigins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        "${distro_id}:${distro_codename}-updates";
        // "${distro_id}:${distro_codename}-proposed";
        // "${distro_id}:${distro_codename}-backports";
};

// Do automatic removal of unused dependencies
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// Automatically reboot system if a reboot is required
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
```
启用自动执行： 运行以下命令，它会生成或修改 /etc/apt/apt.conf.d/20auto-upgrades 文件，告诉APT每天执行 unattended-upgrades。
```
sudo dpkg-reconfigure -plow unattended-upgrades
```
它会问你是否自动下载和安装更新，选择“是”。这会在 /etc/apt/apt.conf.d/20auto-upgrades 中写入类似：
```
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "1";
APT::Periodic::Unattended-Upgrade "1";
```
这些数字代表每天执行一次。

对于RHEL/CentOS/Fedora系统 (使用YUM/DNF)

核心是使用 dnf-automatic（对于DNF）或 yum-cron（对于YUM）。现在主流都是DNF了。

安装 dnf-automatic：
```
sudo dnf install dnf-automatic
```
或者对于旧版CentOS/RHEL 7及更早版本：
```
sudo yum install yum-cron
```
配置自动升级选项： 编辑 /etc/dnf/automatic.conf 文件（或 /etc/yum/yum-cron.conf）。
- apply_updates: 设置为 yes 来自动应用下载的更新。
- download_updates: 设置为 yes 来自动下载更新。
- upgrade_type: 可以是 default（所有更新）或 security（只更新安全补丁）。我个人建议生产环境先从 security 开始。
- emit_via: 设置通知方式，比如 email。
- email_to: 接收通知的邮箱地址。
- reboot: 如果内核更新需要重启，设置为 yes 会自动重启。
一个 dnf-automatic 的配置示例：
```
[commands]
apply_updates = yes
download_updates = yes
upgrade_type = default # 或者 security

[emitters]
emit_via = motd, email # 可以是 motd, email, stdio, json
email_to = your_email@example.com

[base]
# filter_rpms = kernel* # 示例：不自动更新内核
# debuglevel = 1

[automatic]
reboot = yes # 自动重启
```

启用并启动服务：dnf-automatic 通常通过 systemd 定时器运行。

sudo systemctl enable --now dnf-automatic.timer

对于 yum-cron：

sudo systemctl enable --now yum-cron.service

自动更新真的好吗？何时应该慎重考虑？

说实话，自动更新这东西，在桌面系统或者一些非核心的测试服务器上，我个人觉得是挺好的，省心省力，还能及时堵住安全漏洞。但一旦涉及到生产环境，特别是那些对稳定性、可用性要求极高的业务系统，就得非常非常慎重了。

它的优点显而易见：

安全性提升： 及时打上最新的安全补丁，能有效抵御已知漏洞的攻击。
维护成本降低： 不需要人工频繁登录服务器执行更新操作。
系统健康： 修复各种bug，提升系统整体性能和稳定性（理论上）。

然而，它的缺点也同样致命：

潜在的破坏性： 新的软件包版本可能会引入新的bug，或者与现有应用产生依赖冲突，导致服务中断。我见过太多因为自动更新导致应用崩溃的案例了。
不可预测的停机： 内核更新通常需要重启系统才能生效。如果设置了自动重启，那半夜突然的服务中断可能会让你措手不及。
回滚困难： 如果更新后出现问题，回滚到之前的状态可能会非常复杂，特别是对于没有快照或良好备份策略的系统。
缺乏控制： 你无法预先知道这次更新具体包含了哪些内容，可能更新了你不希望更新的组件。

何时应该慎重考虑甚至避免自动更新？

生产服务器： 任何承载关键业务、需要高可用性的生产系统，自动更新都是高风险操作。
有复杂依赖的应用： 如果你的应用对特定库或组件的版本有严格要求，自动更新可能轻易打破这种平衡。
自定义编译或非标准部署： 那些经过大量定制或从源码编译的系统，自动更新可能会覆盖你的定制，或者导致编译环境不兼容。
缺乏监控和告警的系统： 如果更新失败了你都不知道，那风险就更大了。

我的建议是，对于生产环境，宁愿选择手动更新，或者至少采用“分批次、有计划、可回滚”的更新策略。

如何确保自动更新的可靠性与安全性？

即使你决定在某些场景下启用自动更新，也必须采取措施来降低风险，提升其可靠性和安全性。这不光是配置那么简单，更是一种运维哲学。

限制更新范围：
- 优先只开启“安全更新”。很多时候，系统最需要的是安全补丁，而不是所有软件包的最新版本。在 unattended-upgrades 中配置 security 源，在 dnf-automatic 中设置 upgrade_type = security。
- 对于关键服务或易受影响的包，考虑将其列入黑名单，手动管理。比如，我通常不会让数据库服务器自动更新其数据库软件。
设置合理的重启策略：
- 如果允许自动重启，务必设置一个“维护窗口”时间，比如深夜业务量最低的时段。
- 在重启前，确保有适当的通知机制，让相关人员知道系统即将重启。
- 更安全的做法是，只自动下载和安装更新，但由人工触发重启。
建立有效的通知机制：
- 配置邮件通知，无论更新成功、失败还是有警告，都应该发送邮件到管理员邮箱。这能让你第一时间知道发生了什么。
- 如果可能，集成到你的监控系统，当更新出现异常时能触发告警。
定期检查日志：
- unattended-upgrades 的日志通常在 /var/log/unattended-upgrades/ 目录下。
- dnf-automatic 或 yum-cron 的日志通常在 /var/log/dnf.log 或 /var/log/yum.log，或者通过 journalctl -u dnf-automatic.timer 查看。
- 定期查看这些日志，确认更新是否顺利，有没有错误或警告。这是一种主动发现问题的手段。
实施快照和备份策略：
- 在虚拟机环境下，在启用自动更新前，最好为VM创建一个快照。如果更新出问题，可以快速回滚。
- 对于物理机或无法快照的环境，确保有最新的系统备份和数据备份。这是最后的防线。
灰度发布/测试环境先行：
- 理想情况下，你有一个与生产环境高度相似的测试环境。所有自动更新的配置和流程，都应该先在测试环境跑一遍，确认没有问题后再推广到生产。
- 对于大型集群，可以考虑“金丝雀部署”或“分批次更新”，先更新一小部分机器，观察几天没问题后再扩大范围。

这些措施能大大降低自动更新带来的风险，但完全消除风险是不可能的。所以，理解并接受这种权衡很重要。

除了自动更新，还有哪些值得关注的更新策略？

自动更新固然方便，但并非万能药。在实际的运维工作中，特别是面对复杂的IT环境，我们往往会结合多种策略来确保系统的更新与安全。

计划性手动更新（Scheduled Manual Updates）： 这是最常见也最稳妥的方式。
- 定期维护窗口： 设定每周、每月或每季度固定的维护窗口，在此期间执行系统更新。这让团队有时间准备，并能预留回滚时间。
- 严格的审批流程： 在更新前，明确更新内容、可能影响的服务，并获得相关负责人审批。
- 预测试： 在非生产环境（开发、测试、预发布环境）先进行更新测试，验证兼容性和稳定性。
- 分阶段部署： 对于大型集群，可以采取分批次更新的策略，比如先更新20%的机器，观察一段时间无异常后再更新剩余的。
补丁管理工具（Patch Management Tools）： 对于管理大量服务器的场景，手动登录每台机器更新显然不现实。这时，专业的补丁管理工具就显得尤为重要。
- 配置管理工具： Ansible、Puppet、Chef、SaltStack 等自动化工具，可以编写Playbook或Manifest来统一管理服务器的更新。你可以精确控制哪些包更新、何时更新，甚至在更新后执行自定义的验证脚本。这提供了极大的灵活性和可重复性。
- 专用补丁管理平台： 某些企业级Linux发行版（如Red Hat Satellite）或第三方工具提供更专业的补丁管理功能，包括补丁分发、合规性扫描、报告等。
容器化与不可变基础设施（Containerization & Immutable Infrastructure）： 这是一种更现代的更新理念。
- 容器（Docker、Kubernetes）： 应用运行在容器中，操作系统更新与应用解耦。当需要更新操作系统时，可以构建一个新的基础镜像，然后重新部署应用容器，而不是在运行中的容器或宿主机上打补丁。
- 不可变基础设施： 服务器一旦部署完成就不再修改。如果需要更新，不是在现有服务器上打补丁，而是构建一个新的、已打好补丁的镜像，然后用新镜像替换旧服务器。这种方式能最大程度地保证环境的一致性和可预测性。
内核热补丁（Live Kernel Patching）： 对于那些极度追求高可用性、无法承受哪怕几秒钟停机时间的系统（例如，金融交易系统、电信核心网），内核热补丁技术（如Red Hat Kpatch、SUSE Live Patching、Ubuntu Livepatch）允许在不重启系统的情况下应用内核安全补丁。这虽然很酷，但通常只针对关键的安全漏洞，且有其局限性。
安全审计与漏洞扫描： 更新策略是防御的一部分，但主动的安全审计和漏洞扫描同样重要。定期使用Nessus、OpenVAS等工具扫描系统，发现未知的漏洞或未打的补丁，可以作为更新策略的补充和验证。