摘要

  • RIPE Atlas 在 9 月 8 日宣布，计划于下一周初开始定期提醒旧版软件探针的托管者升级。
  • 公告提到今后可能要求使用较新版本，但没有公布执行日期、最低版本或例外安排，不能写成已经实施的淘汰政策。

给探针托管者发一封提醒，能把一项长期搁置的维护工作重新摆上日程，却不能替他决定从哪里取得适配的软件包。RIPE Atlas 的新公告把近期动作放在通知上，较后的版本要求仍未具体化。这个先后顺序，比把消息概括成“强制升级”更准确。

公告也不是执行结果。发信功能是否已经启用、多少用户收到了通知、哪些安装随后更新，均不能仅凭这份计划认定。眼下可以分析的，是提醒如何变成用户实际能够完成的工作。

先辨认安装来源

软件探针并不等于一批由中心统一维护的专用硬件。RIPE Atlas 文档说明，它可以运行在托管者自行维护的基础设施上，并列出由 RIPE NCC、社区或厂商支持的不同路径。一个版本号相同的提示，落到不同环境里，下一步可能完全不同。

固定版本的上游说明进一步解释了责任为何分散：从 5080 起，软件包不再自行更新，托管者可以另外安排操作系统的自动更新。5090 及以后的官方包可走系统包管理器，较老安装则涉及迁移，并有保留密钥与配置的特别提醒。

因此，提醒准确地找到了旧版用户，不代表它已经给出适合该用户的操作路径。维护入口错了，通知仍然可能被收到、被理解，却难以直接执行。这不证明托管者拒绝维护，也不意味着所有旧版都有同一种成因。

自动更新也有自己的分发边界

Turris 的探针安装文档从 reForis 的软件包选项开始；其系统更新文档则说明自动更新以及延迟、审批等控制。用户可以处在厂商的自动更新体系中，而不是直接从 RIPE NCC 的二进制仓库获取每一次更新。

这两份材料只能证明路径不同，不能证明某台 Turris 当前缺少新版探针包，也不能证明某位用户关闭了更新。可用软件包、用户批准和实际安装状态，仍应分别确认。把它们统统算作“用户没有升级”，会让维护责任的判断失去精度。

新计划值得跟踪的地方，是它开始主动触达旧版本的托管者。接下来的判断应落在通知能否对接真实维护入口，而不是提前宣布升级成功，或把尚未公布的准入规则当成既定事实。