构建你自己的 FreeBSD 更新服务器
警告
本文中的说明涉及较旧版本的 FreeBSD，可能无法在较新的操作系统版本中正常工作。随着 pkgbase 的出现，freebsd-update 工具预计将在未来从 FreeBSD 中移除。当这种情况发生时，本文将更新为反映新的程序，或者完全删除。
摘要
本文介绍了构建内部 FreeBSD 更新服务器的过程。freebsd-update-server 由 FreeBSD 安全官员荣誉成员 Colin Percival 编写。对于那些认为从官方更新服务器更新系统较为方便的用户，构建自己的 FreeBSD 更新服务器可以通过支持手动调整的 FreeBSD 版本，或通过提供一个本地镜像来帮助加速多个机器的更新，从而扩展其功能。
1. 致谢
本文随后在 BSD Magazine 上印刷发布。
2. 介绍
有经验的用户或管理员通常负责多个机器或环境。他们理解维持这种基础设施的困难要求和挑战。运行 FreeBSD 更新服务器可以更容易地将安全性和软件补丁部署到选定的测试机器上，再推广到生产环境中。它还意味着多个系统可以通过本地网络而不是可能较慢的互联网连接来更新。本文概述了创建内部 FreeBSD 更新服务器的步骤。
3. 前提条件
要构建内部 FreeBSD 更新服务器，需满足一些要求。
一个正在运行的 FreeBSD 系统。
注意
至少，更新需要在一个大于或等于目标发布版本的 FreeBSD 版本上构建。
至少 4 GB 可用空间的用户账户。这能创建 7.1 和 7.2 的更新，但确切的空间要求可能会根据版本的不同而有所变化。
一个 ssh(1) 账户，用于上传分发更新。
一台 Web 服务器，比如 Apache，其空间要求至少为构建所需空间的一半。例如，7.1 和 7.2 的测试构建总共消耗 4 GB，分发这些更新所需的 Web 服务器空间为 2.6 GB。
基本的 Bourne shell 脚本知识，sh(1)。
4. 配置：安装与设置
通过安装 devel/git 和 security/ca_root_nss，下载 freebsd-update-server 软件，并执行：
适当地更新 scripts/build.conf 文件。该文件在所有构建操作中都会被引用。
以下是默认的 build.conf，应根据你的环境进行修改。
考虑的参数包括：
① 这是从中下载 ISO 镜像的位置（由 scripts/build.subr 中的
fetchiso()子程序处理）。配置的地址不限于 FTP URI，任何由标准的 fetch(1) 工具支持的 URI 方案都应当能正常工作。可以通过将默认的 build.subr 脚本复制到发布和架构特定的目录（即 scripts/RELEASE/ARCHITECTURE/build.subr）并进行本地更改来安装fetchiso()代码的自定义。② 构建主机的名称。当更新系统时，执行
% uname -v时会显示此信息。③用于上传文件到更新服务器的 SSH 密钥。可以通过输入
ssh-keygen -t dsa来创建密钥对。此参数是可选的；当未定义SSHKEY时，将使用标准的密码身份验证作为备用身份验证方法。有关 SSH 和创建与使用密钥的详细信息，参见 ssh-keygen(1) 手册。④ 用于上传文件到更新服务器的账户。
⑤ 更新服务器中上传文件的目录。
默认的 build.conf 文件适用于构建 FreeBSD 的 i386 版本。作为构建其他架构更新服务器的示例，以下步骤概述了为 amd64 配置所需的更改：
为 amd64 创建构建环境：
在新创建的构建目录中安装 build.conf 文件。FreeBSD 7.2-RELEASE 版本在 amd64 上的构建配置选项应类似于：
② 要生成 build.conf 中的“生命周期结束”值，请参考 FreeBSD 安全网站 上发布的“预估 EOL”日期。
EOL的值可以通过使用 date(1) 工具从网站上列出的日期生成，例如：
5. 构建更新代码
第一步是运行 scripts/make.sh。这将构建一些二进制文件，创建目录，并生成用于批准构建的 RSA 签名密钥。在此步骤中，最终创建签名密钥时需要提供一个密码短语。
注意
请记下生成的密钥指纹。该值在进行二进制更新时需要在 /etc/freebsd-update.conf 中使用。
此时，我们已准备好进行构建阶段。
接下来是 初始 构建运行的示例。
然后，世界（world）的构建将再次执行，并应用世界补丁。更详细的说明可以在 scripts/build.subr 中找到。
警告
在第二次构建周期中，网络时间协议守护进程 ntpd(8) 会被关闭。根据 FreeBSD 安全官员荣誉成员 Colin Percival 的说法，“freebsd-update-server 构建代码需要识别存储在文件中的时间戳，以便在比较构建时忽略这些时间戳，从而确定哪些文件需要更新。这一时间戳查找过程通过进行两次相隔 400 天的构建，并比较其结果来实现。”
最后，构建完成。
如果一切正确，则批准构建。有关如何确认这一点的更多信息，可以在分发的源文件 USAGE 中找到。按照指示执行 scripts/approve.sh，这将签署该发布，并将组件移动到适合上传的暂存区。
批准过程完成后，可以开始上传程序。
注意
如果需要重新上传更新代码，可以通过切换到目标发布的公共分发目录，并更新已上传文件的属性来完成此操作。
上传的文件需要位于 Web 服务器的文档根目录中，以便更新能够分发。具体的配置将根据使用的 Web 服务器有所不同。对于 Apache Web 服务器，请参考手册中的 Apache 服务器配置 部分。
更新客户端的 KeyPrint 和 ServerName 配置项在 /etc/freebsd-update.conf 中，并按照手册中 FreeBSD 更新 部分的说明进行更新。
重要
为了使 FreeBSD 更新服务器正常工作，需要为 当前 发布版本和 目标升级版本 构建更新。这对于确定不同版本之间的文件差异是必要的。例如，当将 FreeBSD 系统从 7.1-RELEASE 升级到 7.2-RELEASE 时，需要为这两个版本构建并上传更新到分发服务器。
作为参考，附上了整个 init.sh 运行过程。
6. 构建补丁
每次发布 安全公告 或 安全通知 时，都可以构建一个补丁更新。
在这个示例中，将使用 7.1-RELEASE。
以下是针对不同发布版本构建补丁的几个假设：
设置正确的目录结构以进行初始构建。
为 7.1-RELEASE 执行初始构建。
在 /usr/local/freebsd-update-server/patches/ 下创建相应发布版本的补丁目录。
作为示例，获取 named(8) 的补丁。阅读公告，并从 FreeBSD 安全公告 获取所需文件。有关如何解读公告的更多信息，可以参考 FreeBSD 手册。
在 安全简报 中，此公告被称为 SA-09:12.bind。下载文件后，需要将文件重命名为适当的补丁级别。建议与官方 FreeBSD 补丁级别保持一致，但文件名可以自由选择。对于此构建，遵循 FreeBSD 当前的做法，命名为 p7。重命名该文件：
注意
在运行补丁级别构建时，假定之前的补丁已经到位。当运行补丁构建时，它会运行补丁目录中包含的所有补丁。
可以向任何构建添加自定义补丁。使用数字零，或其他任何数字。
警告
FreeBSD 更新服务器的管理员有责任采取适当措施验证每个补丁的真实性。
此时，diff 已准备好进行构建。软件首先检查在运行差异构建之前，是否已经在相应的发布版本上运行过 scripts/init.sh。
接下来是 差异 构建运行的示例。
更新会被打印出来，并请求批准。
按照之前提到的相同流程来批准构建：
作为参考，已附上整个运行过程的 diff.sh 。
7. 提示
在 scripts/build.subr 脚本中的
buildworld和obj目标添加-j<span> NUMBER</span>标志，可以加速处理，具体取决于使用的硬件，但这不是必须的。不建议在其他目标中使用这些标志，因为它可能导致构建变得不可靠。为更新服务器创建一个适当的 DNS SRV 记录，并将其他服务器放置在其后，设置不同的权重。使用此功能可以提供更新镜像，但除非你希望提供冗余服务，否则此提示并非必需。
最后更新于