☰

升级程序

tag-icon • tag-icon freebsd openbsd
升级程序

我已经使用 FreeBSD 大约 5 年了 - 服务器/桌面 - 并且我倾向于将我的 apt-get/yum 升级所有习惯带到身边（我也管理 Debian/RHEL/Cent 机箱 - 我知道，我知道...无论平台如何都应该更加谨慎）。因此通常是：

portsnap fetch
portsnap update
portmanager -u

对于港口

有时后面还会跟着：

freebsd-update fetch
freebsd-update install

对于系统...等等。然后只要在发生任何混乱时清理它们...即可。

我意识到，这是相当过分的非 BSD 做法。您对 BSD 机器的理念是什么？您是否在仔细考虑后运行 portaudit/portversion -- 检查输出然后更新（make deinstall ...等）？

我承认，我对 OpenBSD 还很陌生。我发现自己会 cvsupping 端口树，运行“过时”的脚本，然后只升级关键端口 --- 但内核/二进制文件保持不变，每六个月才升级一次。您是否修补/重新编译/重建内核、二进制文件 --- 为什么？

在 BSD 机器上，对于关键服务（合理关键 - 这不是银行或医院）的保守方法是什么？您在 Linux 机器上使用类似的方法吗？我通常不会触碰任何服务器上的内核，除非安全警报让我感到恐惧。

是的，有很多文档和书籍——你们到底在做什么？假设我们知道基础知识——智慧是什么？用例/环境和场景各不相同，利害关系/利益相关者/用户也各不相同。书籍和手册页涵盖了工具和用途，但缺乏实际应用。如果您知道有一本书涵盖了这一点，请推荐一本！

谢谢阅读！

布布诺夫

结论 ~ 感谢花时间回答此帖的所有人。我现在的总体策略是关注两个 BSD 的邮件列表，并且比过去更加谨慎地选择更新。

FreeBSD ~ Portaudit 是个不错的选择。有了邮件列表和认真的审核，我认为它在这里会很有帮助。OpenBSD 和 FreeBSD 对端口的不同重视程度很有趣。

OpenBSD ~ 将关注邮件列表并在关键时使用软件包工具（ pkg_info 和 pkg_add -u ）。升级：看起来您至少需要每年升级一次。他们支持最新版本以及一个以前的版本 - 因此目前是 4.8 和 4.7。

再次感谢。

答案1

确保经常检查已安装的端口是否存在易受攻击的软件包：portaudit -Fda

答案2

我不确定是否有特定的“BSD 方式”来做这类事情。一切都归结为了解正在更新的内容和测试 - 通用系统管理员的东西。幸运的是，freebsd-更新和端口快照让“知道什么”变得相当简单。

但是，既然你问了具体细节，当我管理大量 FreeBSD 机器时，它们都是集群中的节点。独立机器与此并没有什么不同，但我想你可以将其模糊地设置为“devops”，就像你的生产服务一样。最后，拥有单独的测试和生产环境总是一个好主意。

在集群情况下：

  • 每台机器都安装/usr/src，/usr/obj， 和/usr/ports通过 NFS。
  • 根据您的预算，您可以拥有一台暂存/构建机器，或者指定一个集群节点作为暂存/构建节点。
  • 暂存节点有一个不同的副本/usr/ports
  • 暂存节点将更新源文件全部和全部端口通过简历每天晚上
  • 如果需要更新，暂存节点将不再轮换，并且建筑世界，安装世界， 和端口升级将会运行。
  • 暂存节点将会被彻底测试。
  • /usr/ports将在 NFS 主机上交换
  • 每个集群节点将轮流运行安装世界和端口升级，进行测试然后旋转回来。

显然，这是系统和端口更新的情况，但过程与仅更新软件包或系统非常相似。

如果使用两台机器完成此操作，则可以让每台机器轮流进行生产或准备，或者仅从准备阶段更新生产。

您可以从 cvs 日志中跟踪更改，并检查是否已获得特定更新/usr/src/更新和/usr/ports/更新，两者都会自动更新简历。

如果你不使用简历（而现在没有理由这么做）你只需要找到其他方法来跟踪你想要的更新。你可以将 freebsd-update 想要进行的更改列表邮寄给你自己，并关注安全勘误表页面。

答案3

OpenBSD 更新理念

这是我更新 OpenBSD 的方法

及时了解以下安全版本/补丁：

  • BASE（即 OpenBSD 开发团队在其源代码树中维护的内容）
  • 软件包/端口（即安装在 BASE 上的软件应用程序）

更新程序：

  • 相同的操作系统版本
  • 新操作系统版本

根据

a. 遵循相关邮件列表 - 我查看 squish.net 每日文摘，以及技术和杂项邮件列表上显示的总体方向。

b. 关注 Unix 相关的安全公告网站/邮件列表。

c. 保持使用 cvsync 进行本地 CVS 复制

d. 构建上述稳定版本

当安全更新发布时，我们会根据具有该版本操作系统/漏洞的机器的配置文件评估实际的安全问题。如果漏洞相关，我们将执行“相同版本升级程序”。

软件包/Ports

跟踪端口/软件包的安全更新更加困难，但如果它对我们的基础设施来说足够重要，那么它就足够重要，值得以类似于 BASE 的方式进行跟踪。

  • 加入特定应用程序的邮件列表（我们有责任关注上游变化，独立于 OpenBSD 项目。）

  • 加入 CERT 等安全网站的分发列表，发布有关应用程序等漏洞的调查结果。

升级程序

显然，在生产机器上执行安装过程之前，应在单独的硬件（或虚拟机）上构建和测试它。幸运的是，我们拥有许多冗余主机，因此可以在服务停机时间最短的情况下推出。由于 OpenBSD 支持广泛的硬件，我们可以为主要机器推出服务器级设备，并将低端台式机作为冗余主机（或者我们只是在更新周期内构建一个临时机箱来代替主要机器。）

我们的更新程序严重依赖于使用非 BASE 软件的 ports/packages 系统。我们从源代码安装软件的两台主机在操作系统版本更新之间很难更新。

相同的操作系统更新

对于基本操作系统，我们只需在旧二进制文件上安装新二进制文件即可继续成功。最好备份所有操作系统和应用程序配置/数据文件，格式化并重新安装修补后的操作系统并重新安装软件包（保留原始数据）

在我们部署的 OpenBSD 主机（30 台以上）和经验中，备份配置和数据并不困难。对于我们的防火墙，所有数据都在配置和日志文件中。

对于 Ports/Packages - 更改很简单，我们修改自己的端口并从中构建包。更新端口可简化上述过程。

新的操作系统更新

在操作系统发布之间，我们从草图安装所有内容。

我确信该过程有足够的文档，但本质上我们构建了一台与要“替换”的系统具有相同配置的参考机器。在部署主机之前，进行相同的测试。

我们从参考主机备份配置并在生产主机上安装 OpenBSD，在其上恢复“已验证”的配置（之后再次运行相同的验证测试。）

答案4

如果没有安全问题或功能障碍，那就不要管它。每 3-6 个月检查一次更新，这样你就不会落后太多，但除此之外就不要管它了。

如果它没坏，就不要修理它。

相关内容