> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20160102-xing-neng-tiao-you/this-month-in-freebsd.md). # FreeBSD 本月动态 * 原文：[This Month in FreeBSD](https://freebsdfoundation.org/wp-content/uploads/2016/03/This-Month-in-FreeBSD.pdf) * 作者：**Dru Lavigne** 接下来几期，我们将深入关注即将进入 2016 年发行版的一些新功能及其背后的开发者。 本月我们对话 **Allan Jude**。自 2014 年获得文档提交权限、2015 年获得源码提交权限以来，Allan 一直是高产的贡献者。他的几个项目将进入今年的 10.3 和 11 发行版。 ## 介绍一下你自己 **你是如何开始接触 FreeBSD 的？你目前参与 FreeBSD 项目的哪些工作？** 我在 1999 年开始成为 FreeBSD 用户，那时我想运行自己的 IRC 服务器。从互联网上下载软件之后，我发现压缩包里没有 .exe。问了一圈之后，得知我需要先有“shell 账号”才能运行这套软件。我找到了供应商，以每月约 10 美元的价格租给我 shell 账号。如今你花差不多同样的钱，甚至考虑这 16 多年来的通货膨胀，可以租到一台 RAM 翻四倍、CPU 也更强的虚拟机。 我对命令行颇为熟悉，但此前只用过 DOS 和 Windows，所以要学的东西很多。随着学习深入，我最终停止了租用 shell 账号，转而开始把它们卖给别人。2002 年，我创办了自己的公司，出租 IRC 服务器和 shell 账号，很快就能熟练保护自己的服务器免受恶意用户侵害。随着知识面拓宽，我也开始接一些咨询工作，为别人搭建像 Apache/MySQL/PHP 这样的 Web 托管栈，从源码定制编译。 上大学时，我有幸进了一所学校，那里同时教授 Linux 和 BSD。在那里我结识了其他 BSD 用户，并首次听说了 BSDCan 这一盛事。遗憾的是，我没能赶上 2006 年的首次 BSDCan，直到 2012 年才第一次参加。当我最终参加时，一切都变了。第一次 BSDCan 我并没有太多收获，除了空气中弥漫的那股兴奋与活力，以及见到了一些此前只在邮件列表上见过名字的人。我决定不仅要来年再来，还要投一份演讲提案，把自己的一些 BSD 系统管理经验分享给听众。为什么要等到第二年？于是我向 2012 年在波兰举办的 EuroBSDCon 投了提案并获接受。第一次做演讲令人难忘，但反响很好，听众提出了颇有见地的问题。从那以后，我几乎能参加的 BSD 大会都去了。 2013 年，在去 BSDCan 的路上，我觉得 FreeBSD 手册中关于 ZFS 的文档缺乏很多细节，于是开始动笔。我参加了首次文档冲刺，并掌握了如何为项目编写文档。2013 年 8 月，一位听众喜欢我的系统管理播客 TechSNAP.tv，问我是否愿意开办一档以 BSD 为主题的播客。一开始我觉得每周一期节目哪有那么多新闻可撑，但在观众 TJ（后来成为我们的第一位制作人）和我开始为几期节目撰写概述之后，我很快意识到自己错了。短暂物色之后，我选中 Kris Moore 做联合主持。几个月后，在飞往 2013 年马耳他 EuroBSDCon 的航班上，我开始思考如何让 FreeBSD 安装器更好地处理 ZFS。我的初稿很粗糙，错误百出，但一位非常热心的提交者与我合作，把它打磨成形。没过多久，它成为操作系统的一部分。2014 年 BSDCan 给了我一个大惊喜——我获得了文档提交权限。BSDCan 2015 之后不久，我又获得了源码提交权限。 如今，我在白天的工作单位 ScaleEngine.com（一家视频流公司）每天都使用 FreeBSD，只有周三例外，那天我会和 Kris Moore 一起录制 BSDNow\.tv 播客。晚上的时间我则投入各种项目，从文档，到统一各工具的配置文件，到改进 ZFS 的命令行界面，再到为 FreeBSD 启动代码和 loader 增加功能。 ## 你已经研究 UCL 一段时间了。UCL 究竟是什么？它和其它配置语言相比如何？相比传统配置文件，它有哪些优势？ UCL，全称 Universal Configuration Language（通用配置语言），由另一位 FreeBSD 开发者 Vsevolod Stakhov `` 为他自己的工具 rspamd 设计。它包含一个库 libucl，可将配置文件解析为对象，应用据此完成自身配置，并能将修改后的配置文件再写出。其目标是让配置文件既便于人类阅读和编写，又能被程序化操作——这是一种配置格式，任何有经验的系统管理员或用户都能理解并欣赏。 UCL 的配置语法本身基于 NGINX 和 Bind 的语法，但做了轻微调整，使其也能兼容对 JSON 的宽松解读： ```ini category { key = value; othercategory { subcategory { max_size = 10kb expiration = 3d array1 = [1, 2, 3] array2 = [ thing1, thing2, thing3, ] } } } ``` UCL 语法有许多便于人类编写的特性。它不要求行尾加分号。它支持数组，但和 JSON 不同，允许列表最后一项后跟逗号，以减少向列表追加元素时产生的 diff。还有“语法糖”，值可以带单位，比如 k（1000）、kb（1024）、h（小时）、d（天）。布尔值可写作 true/false、on/off、yes/no 任一种。UCL 还支持注释，三种主流风格皆可：单行（`//`）和多行（`/* ... */`）的 C 风格注释，以及许多配置文件格式使用的标准井号（`#`）。 它的强大之处在于对变量、宏和 include 的原生支持。变量由应用设置，供用户在配置文件中使用，例如 `$HOST` 表示系统主机名。宏允许解析配置文件的应用通过附加功能扩展配置语言。include 系统允许将额外文件包含进配置。include 支持优先级，因此应用或用户可以控制当某个设置在两处配置中都定义时使用哪一个。支持 GLOB 模式和搜索路径，可以一次包含多个文件，例如 **/usr/local/etc/appname/\*.conf**。还支持远程 include，并可选签名验证。 libucl 自身可以解析 UCL、JSON、YAML 和 Msgpack，并能以这四种格式中的任一种输出配置。使用 libucl 解析配置文件的应用将接受上述任一格式；对应用而言，它们看上去都是一样的。 ## FreeBSD 正在向 UCL 过渡。能介绍一下用户在即将到来的 10.3 和 11.0 发行版中可以期待什么吗？ 由于时间限制和兼容性顾虑，10.3 的用户不会看到任何变化。但从 11.0 开始，许多配置文件将更换格式。出于兼容和过渡便利，所有工具仍会接受它们原有的文件格式，但会同时获得对基于 UCL 的新配置文件的支持。作为 UCL 转换工作的一部分，我首先实现的就是在配置文件中加入版本标识符，这将让未来的过渡更轻松，也让应用能识别何时收到的是新格式的配置文件。把现有机器升级到 11.0 的用户既可以选择继续使用现有配置文件，也可以选择尝试转换。全新安装 11.0 的用户将默认获得新的 UCL 配置文件。这里唯一的麻烦是文档：由于旧格式仍受支持，文档需要保留，即便只是为了给那些转换配置文件的人提供参考资料。 目前没有计划由工具自动将旧配置文件转换为新格式，但也没人阻止谁往 Ports 树里添加这样一个工具。 我最初的目标是：newsyslog.conf、login.conf、jail.conf、pw\.conf、wpa\_supplicant.conf。 要覆盖的配置文件还很多，所以我总是欢迎有意帮忙的人，或者哪怕只是告诉我他们希望接下来转换哪些配置文件。 我也想重启我的 bhyveucl 项目（github.com/allanjude/bhyveucl）。它最初是一个 shell 脚本，读取一个 UCL 配置文件，并写出复杂的 bhyve 命令行，按描述启动虚拟机并按要求配置网络。后来我加入了一个直接在 bhyve 中实现配置文件解析的项目，这个工具就被搁置了。该项目在 bhyve 作者的要求下被无限期搁置，因为他们正在做大量增强工作，包括 USB 支持、网络和存储的插件架构，以及其它很多东西。这些都需要比我最初设计的更富表达力的配置文件。然而，那项工作比预期更耗时，所以重启 bhyveucl 仍可能有其价值。即便 bhyve 内部的工作完成后，这个配置文件可能仍有很大价值，作为一个像 bhyveucl 这样的工具，能接受较简单的配置文件并转换为 bhyve 所需的更富表达力的“机器描述”。 > “目前没有计划由工具自动将旧配置文件转换为新格式。但也没人阻止谁往 Ports 树里添加这样一个工具。” — Allan Jude ## bsdinstall 也在改进，以提供对 ZFS 启动环境的支持。对于不熟悉此功能的读者，能简单介绍其好处吗？为加入此支持需要做什么样的工作？何时会向用户开放？ ZFS 启动环境是一种拥有多个根（/）文件系统并在重启时在它们之间切换的方式，用于回滚有问题的升级，或在多个版本的操作系统之间双启动。可以手动管理，但 Ports 中有一个工具 sysutil/beadm，提供了友好的用户界面。每个启动环境都是一个 ZFS 数据集，尽管大多数情况下它是现有文件系统的 ZFS 克隆，因此在产生变更之前不占用额外空间。如果在升级前克隆了你的 / 文件系统，而升级效果不如预期，只需执行 `beadm activate oldbootenv` 并重启，系统就会从升级前的 / 克隆启动。其它文件系统（比如用户的家目录）不受影响。 ZFS 启动环境的最初支持在 FreeBSD 10.0 中引入到 FreeBSD 安装器。当你在安装器中使用“Automatic root-on-ZFS”模式时，它会创建 **poolname/ROOT/default**，这就是你的第一个启动环境。 使用启动环境有两种方式。PCBSD 在每次升级前创建一个新环境，在该环境中启动一个 chroot 的 jail，并在其中完成升级，然后重启进入该环境。我个人更倾向于只用“default”启动环境，并在每次升级前创建其克隆，以便在需要时回滚。另一个关键因素是决定哪些内容应纳入启动环境、哪些内容在切换时应保持不变。基本操作系统（**/bin**、**/sbin**、**/usr/bin**、**/usr/sbin** 和 **/etc**）通常被纳入，但 **/usr/local**（pkg 安装的应用所在位置）在每个环境中是各自独立，还是在所有环境中保持一致，则取决于你的环境。 10.0–10.2 中发布的启动环境存在的问题是：如果某个环境无法正确启动，唯一的切换方式是手动操作 loader 提示符，或从 live CD/USB 启动并切换“活动”启动环境。 我一直在为 beastie loader 菜单增加一个额外的菜单项，让你可以选择不同的启动环境。这让你能够在启动时快速、轻松且安全地在不同的根数据集之间切换。它与 PCBSD 使用 GRUB 或 IllumOS 当前做法的不同之处在于：不是从配置文件读取启动环境列表，而是通过检查 ZFS 池本身来生成列表，因此列表始终是最新的。 另一个复杂之处是加密。如果用户对 ZFS 池进行了 GELI 加密，目前需要一个 UFS 分区，或者第二个未加密的 ZFS 池来存放内核，以便能加载 GELI 加密支持来解密文件系统。这两种情况下都无法支持启动环境，因为内核并不位于创建启动环境的 boot 上。 我一直在通过在启动代码和 loader 中实现 GELI 解密支持来解决这个问题。我希望这项工作也能进入 10.3。这将允许从单个加密的 ZFS 池启动，即便存在加密也能完整支持启动环境。 ## 你在 ZFS 方面著述颇丰，包括 FreeBSD 手册中的 ZFS 一章以及与 Michael W Lucas 合著的《ZFS Mastery》系列图书。你是如何对 ZFS 产生兴趣的？它给你和你的公司带来了什么好处？ 我最初对 ZFS 产生兴趣，是因为公司需要以灵活且安全的方式存储大量视频文件。我在企业存储方面经验有限，此前机器上最多只用过主板 BIOS 辅助的镜像。我觉得池化存储和写时复制的概念很有趣，也很契合我们的需求。ZFS 的管理和配置接口也极其简单而强大，我很快就游刃有余。对 ZFS 了解越多，我就越想把它介绍给每个人。 自 2011 年搭建第一台 ZFS 服务器以来，我学到了很多。在我们公司，每个客户都有自己的 ZFS 数据集，这样我们就能更轻松地在服务器之间迁移客户、独立管理其快照并分配配额。最初部署 ZFS 时，我们只有一个大的视频数据集，每个客户拥有一个目录。问题在于，如果某个客户清空了大量视频或注销账户，在快照被销毁之前我们无法回收这部分空间。我们既不想丢失其它客户数据的快照，又想能回收这部分空间，因此我们改为每个客户使用独立的数据集。我们还使用 ZFS 的空间统计系统来给客户计费。 对我们公司而言，ZFS 最大的优势在于其灵活性、弹性与可调性。借助 FreeBSD 和 ZFS 提供的工具，更不用说 DTrace，我们可以轻松监控和诊断任何性能问题。每块磁盘的细节直接暴露给操作系统，而不是隐藏在 RAID 控制器背后，这也节省了时间，让管理故障磁盘更容易。 ## BSD Now 播客已经进入第三个年头。这段时间里你是否观察到 BSD 使用或认知上的趋势？ 最初提出这个节目想法时，我觉得行不通。我们做了一阵子并真正开播之后，我对它颇有信心。最让我惊讶的是，Kris 和我都还没有倦怠，仍然每周享受做这个节目。我想这在很大程度上是因为我们从社区得到了非常正面的反馈。我个人最喜欢的环节是访谈。 自节目开播以来，我明显感觉到 BSD 在认知度和采用度上都有所提升。我们每周都会收到反馈，说有人新尝试了 BSD，或者切换到了 BSD。我关心的是留存率，他们中有多少人会坚持用下去。我想知道项目能做些什么来帮助新手跨过最初的障碍，像我一样成为终身用户。我想我们看到的最大抱怨是新笔记本的硬件支持，我希望这是未来可以解决的问题。 ## 你近期还在做什么其它项目，或计划开始什么新项目？ 除了继续在 FreeBSD 中实现 UCL 配置文件，以及我那个名为 uclcmd（github.com/allanjude/uclcmd）的 UCL 命令行工具外，我还有一些关于 ZFS 新特性的想法。除了一个用于跟踪 ZFS 命令行接口变更的系统（供自动化 ZFS 部分的脚本使用），我还在实现最近添加到 ZFS 中的额外哈希算法，以便它们能在 ZFS 上使用。其中一种 SHA512t256，是将 SHA512 截断到 256 位（因为这是 ZFS 中校验和的最大长度），在 64 位 x86 硬件上计算时比普通 SHA256 快约 50%。我还在将 FreeBSD 中的工具转换为 libxo，这是一个让工具能够输出 JSON 和 XML（除了常规文本输出外）的库。 我稍宏大一些的目标是一个名为 Zoro 的项目，它是 sysutil/zxfer 的继任者，用于管理 ZFS 复制。Zoro 将管理快照创建和保留、书签以及复制。我的一些想法最好靠 ZFS 方面的一点帮助来实现，因此它可能也会带来一些新的 ZFS 特性。 我在系统的许多不同领域都有涉猎，要么是让自己的工作更轻松，要么是让 FreeBSD 发挥我所看到的更多潜力，或是解决他人的问题，希望能提升 FreeBSD 和 ZFS 的采用率。 *** **Dru Lavigne** 是 FreeBSD 基金会董事，BSD 认证小组主席。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://freebsd-journal-cn.bsdcn.org/20160102-xing-neng-tiao-you/this-month-in-freebsd.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.