使软件更新和升级自动化有什么缺点吗?

Tim*_*Tim -1 cron ubuntu debian apt software-updates

在 Lubuntu 18.04 上,软件更新程序会不时通知我有可用更新。如果我碰巧有时间,我会手动运行sudo apt update; sudo apt upgrade.

我正在考虑是否自动进行更新和升级。使软件更新和升级自动化有什么缺点吗?方便会大于缺点吗?

在使软件更新和升级自动时,哪种方式更好:

  • 更改软件更新程序的设置,或
  • 创建 anacron 日常工作apt update; apt upgrade

谢谢。

Rui*_*iro 6

在生产系统中,根据您的服务/系统的关键程度以及您设置高可用性的方式,您可能不希望有计划的/无人值守的自动升级

多年来,由于人们进行自动升级,我看到了一些服务的服务中断:

  • 由于新升级的次要版本的语法略有不同,squid 退出了;
  • DNS 服务因动态路由守护进程在次要版本中停止支持 sysV 而退出;
  • 由于已经测试过的软件包中缺少磁盘空间,Apache 服务停止运行;
  • 由于更新重新创建默认文件,Apache 未重新启动...
  • Apache 重新启动,但更新用 Apache 默认页面替换了站点的主页;
  • 由于次要版本中的错误导致 DHCP 服务故障;
  • 由于有人将编译的二进制文件放在软件包的官方二进制文件的位置,netflow 服务停止了数天;
  • rsyslog 因 rsyslog 更改某些语法而下降,并且有人在不知道在做什么的情况下设置了反向移植存储库;
  • FreeRadius 服务在将未经测试的版本推送到本地存储库并且不知道有人设置了具有自动升级功能的 Radius 后出现故障。

此外,当盲目地进行主要版本升级时,您可能会遇到软件和版本之间的软件/应用程序不兼容问题。

正如@panki 也正确指出的那样,通常您不能盲目升级软件并在升级时引入更短或更长时间的中断,或者更糟的是,长时间中断直到有人纠正升级过程中发生的一些小(或大)问题。

虽然自动升级对于台式机/家庭服务器设置可能很有趣,但它给生产系统带来的不稳定性权衡并不值得使用它们。我认为这是其中一种,虽然它可以工作,但它似乎可以为您省去很多麻烦,但是当它失败时,它确实以不可预测的方式让您失望。

至于减轻/管理升级生命周期的方法,您可以采用多种策略,这也取决于您的正常运行时间要求/基础架构大小:

  • 只需手动完成:
  • 在有人监督过程中半自动地进行;
  • 监控所有服务和监督过程的人,修改所有升级日志后,密切关注监控服务;
  • 对哪些升级重要或不重要进行一些规划,而不是盲目地进行;
  • 在冗余系统中使用不同版本的 Linux(更多工作和更多可能出现的不同问题......);
  • 为服务使用冗余/测试平台并进行分阶段升级;
  • 例如,使用 yum 支持的时间点“书签”版本;
  • 将本地存储库/代理用于分布式受控/测试/批准的发行版,类似于基于 RH/CentOS 的系统的 Satellite/Katello/Spacewalk 或适用于 Debian 的Aptly
  • 将这些策略与 Ansible 等 DevOps 工具集成。

此外,在生产系统中,当管理不属于您自己的系统时,您可能还必须处理在更新系统之前征得所有者许可的官僚问题,因此您无法保持自动更新服务处于活动状态。

TDLR 操作系统升级生命周期的管理,在生产环境中绝非易事。操作系统升级生命周期有很多角度,操作性、系统性、版本控制、安全性、人性化、应用性等。

回到问题的特定部分,在需要高正常运行时间/高可靠性时使用自动程序可能不是最好的方案。

PS.related,用于 Debian

aptly是 Debian 存储库管理的瑞士军刀:它允许您镜像远程存储库、管理本地包存储库、拍摄快照、拉取新版本的软件包以及依赖项、发布为 Debian 存储库。