似乎几乎每天都有新一轮由 AI 引发的 CVE。你必须时刻关注补丁、更新和升级。那种你可以设置一台 Linux 机器然后享受数月正常运行时间的日子已经一去不复返了，除非它的所有网络接口都被拔掉。
幸运的是，Debian 通过 unattended-upgrades 包让获取持续不断的升级变得容易。它是我为新的 VM 进行 Ansible 自动化配置的一部分，但有一天我注意到了一些令人不安的事情。
我有一个已经运行了一段时间的 Debian 13 (Trixie) 系统，出于好奇，我运行了 apt update：
……什么？！？！
怎么会这样？在你问之前，这不是那种那天早上刚刚发布了 30 个包的情况。它们都是非安全更新吗？不：
是否安装了 unattended-upgrades？是的：
是否启用了？是的：
那么发生了什么？
我做了一些研究，发现了一些有趣的事情：
啊哈！所以在安装时，unattended-upgrades 被安装了，但没有启用。你可以测试这一点。如果 /etc/apt/apt.conf.d/20auto-upgrades 不存在，那么该包已安装，但从未被配置。
快速修复方法是 dpkg-reconfigure unattended-upgrades：
但为什么？
我很好奇，所以我创建了一个全新的 Debian VM（从 ISO 安装）。首次启动时，unattended-upgrades 未启用。该包尚未安装。
在运行 apt update 和 apt install unattended-upgrades 之后，dpkg-reconfigure 没有自动触发。系统仍然显示：
嗯。这是一个 bug 吗？
不，这是设计使然。Debian 的安装程序使用 pkgsql，其中有这样的代码：
所以这是设计使然。但我不认为我同意这个设计。apt 应该要么自动启用，要么至少通过触发 dpkg-reconfigure 来询问你是否要启用。
unattended-upgrades 包本身用以下内容定义其 debconf 问题：
所以它自己的默认值是 true。但是 debconf 已经有一个由 Debian 安装程序留下的显式 false 值。该包的配置脚本以低优先级询问这个问题：
然后 postinst 检索该值：
简而言之，发生的事情是：
Debian 安装程序预设了 enable_auto_updates=false；你运行 apt install unattended-upgrades；包默认值为 true；但 false 已被预设；问题为低优先级，因此你不会被询问重新配置；enable_auto_updates 保持为 false。
然而，dpkg-reconfigure 会显示低优先级问题。根据手册页：“dpkg-reconfigure 通常会显示低优先级问题，无论你的默认优先级是什么。” 所以当它运行时，它会询问你是否要启用。
嗯。好吧，现在我明白我们是怎么走到这一步的了，但这并没有改变我的看法。我想 unattended-upgrades 类似于你安装但还需要启用的服务。不过，我认为如果用户明确安装了该包，它就应该被启用，因为很有可能用户希望启用它。一个包默认启用，如果用户确实想要，可以在安装后禁用的流程对我来说更有意义。
Ansible
就我个人而言，我用 Ansible 设置我所有的 VM。仅仅将 unattended-upgrades 添加到你的 apt 包列表中并不会启用它，但首先设置 debconf 策略则会：
在外面注意安全！