SysAdmin

在上一家公司的时候曾经有很多关于 cron(8) 的想法，但一直没有付诸实施，很多东西放在本地慢慢生锈了。

去年年底的时候我开始着手去修了一些 cron(8) 的 bug，其中包括为 cron 之前不够完整的 PAM 支持进行了改进。

背景：PAM

Pluggable Authentication Module (PAM) 为一系列身份验证相关的操作提供了一组通用的接口。在没有 PAM 之前，应用程序需要实现大量重复的代码来完成类似的操作，例如要求用户输入密码并进行验证等。这么做的问题在于缺乏灵活性，例如，管理员可能希望将用户数据保存到 LDAP 目录中，或是使用指纹等新式验证方式。PAM 使这些相关操作可以通过插件来完成，应用程序不再需要关心「如何验证用户身份」（用户名、密码等等是不是正确），而只需要向 PAM 询问「该用户的身份是否合法？」即可。这层抽象简化了应用程序开发者的工作，并且赋予了系统管理员更大的灵活性。

PAM 将系统的认证工作分成了四组基本操作：

• auth：验证用户身份（比如检查密码）。
• account：检查账户是否有效（比如是否过期、是否允许在此时间登录）。
• password：用于修改密码。
• session：会话管理，即用户「进门前」和「出门后」需要进行的环境搭建或清理工作。这是本次更新的核心。

今年二月的时候，我发过一个段子：

「你是什么时候意识到自己可能需要休假了？」

「有一天我临睡前在家里的票务系统里给自己开了票，要求在家里的DNS域上添加 staging，preprod 等几个子域来符合最佳实践，然后在第二天醒来以后看到系统发出的今日待办事宜邮件的时候。」

段子归段子，我认为搭起票务系统是我在疫情期间干的最改善生活品质的一件事了。这里分享一下我的一些个人经验。

为什么你有可能会需要一套票务系统？或者说，票务系统能帮我干什么？

事务追踪系统，或者，由于其中的事务往往也被称作「票」（ticket），我个人也常戏称为票务系统，在成规模的团队软件开发中是经常使用的一种工具。票务系统可以记录开发期间的各类任务，将任务分解成多个可操作的子任务、为这些任务排列优先级，并将其分配给具体的人。对任何工作而言，将工作拆解到较为具体的、可以由一个人完成，并且具有优先级和依赖关系属性的子任务，都有助于帮助人们迅速、高效地完成工作。

在工作中我个人也很喜欢使用事务追踪系统来跟踪一些开发以外的事务性活动，并且将事务追踪系统作为一种类似笔记的工具使用，在「票」中关联一系列相关文档，这有助于在事后总结经验或将重复性的事务性工作整理成更容易使用的形式（例如作弊条文档，或是将常用的重复部分变成程序等等）。

其实想搭一套 paperless-ngx 已经挺久的了，趁着四月底休假的时候搞了一动。

我们经常会有一些各式各样的 PDF 文档，例如和各种供应商、公司之间签署的文件、账单，以及参加一些学术会议时留下的幻灯、资料等等。比较自然的办法就是创建不同的文件夹来分门别类地保存。然而，简单地用文件系统来保存这些文件有这样一些问题：

这篇和较早的 线上重做 FreeBSD GPT 引导分区 情况有些类似，但略有不同。

前段时间 Andriy Gapon 为 Samsung 860 / 870 SSD 增加了一个 quirk。Samsung 的 SSD 内部使用的是 8K 或 16K 的存储页，但为了和业界标准兼容，它的控制器为 4K 扇区做了优化。

原载于 Telegram 频道。

今天来讲个关于备份的小故事。

以前有个同事之前在某使用UNIX的传统行业干了多年，他们的系统可用性要求不算高，但数据非常重要，所以备份自然也是必不可少的。为了确保备份的安全性，他们还雇了一家专门的保全公司定期把备份磁带从办公室拿走到该保全公司的仓库。

上周末抽时间把服务器升级到了 FreeBSD 14.0-RELEASE。软件的发布中存在许多的工序，大致上，在 releng/ 分支上的代码树会正式命名为 -RELEASE，同时由一位 Release Engineer 开始最终的 build（对应的文件会发布到 FTP 上，并在 网站 上提供链接），并在适当的时候将 releng/ 分支上的代码tag 成 release。此后， Security Team 需要将 Release Engineer 签名的 -RELEASE 放到 freebsd-update builder 上再次 build、签名，并生成二进制更新所需的文件。

由于安装用的 ISO 映像文件都比较大，传统上将这些映像文件分发到全球的镜像站点上需要一些时间。现时，云服务提供商往往还有自己的 QA 步骤，因此最终宣布 -RELEASE 的时间往往会比 FTP上出现的时间晚上一周左右。技术上这段时间这个 build 依然只是一个发布候选版本(Release Candidate)，因此普通用户不应使用这些版本，因为在这一周的时间如果遇到一些突发状况的话可能会需要将这个版本撤回(例如原本应发布为 FreeBSD 4.6.1 的 FreeBSD 4.6.2 就是这样的情况)。

摘要

事故影响

由于 UPS 测试触发了系统停机，导致 delphij.net 部分服务停止了约40分钟。服务从 2023-01-16 15:46:20 开始受到影响，至 16:26:55 完全恢复。如果服务未能及时修复，潜在地将会进一步影响包括权威DNS（有多个独立的冗余，但依赖于持续的数据更新）在内的一些其他关键服务。

问题根源

在测试时对于 CyberPower UPS 测试特性的认识不足导致电池电量消耗至临界值，由于对 nut 的配置未考虑这种情况直接将服务器关闭，这使得必须亲自到机房才能完成服务的恢复。

因为机房和家里 之前发生过一些停电的问题，因此这两处我都放了UPS。

UPS使用的铅酸电池是有一定寿命的，机房这台UPS是2016年5月上线的（当时是觉得已经到了5年，应该换掉了；而当时查看价格发现购买一个UPS电池自己更换的原材料价值和买一个新的差不多，于是就直接整体换成了 APC BE600）。

由于使用的 port 的编译选项与官方的往往不一致（例如我非常讨厌 gnutls、avahi 这两个包，此外有时我希望使用一个和官方不太一样的 OpenLDAP 版本，或者采用不同的编译选项等等），我之前一直是 portmaster(8) 的用户。 portmaster 是Doug Barton 早年用 shell 脚本写的一个 portupgrade(1) 的替代品，和后者相比，它不需要使用数据库，并且充分利用了 shell 的任务管理功能实现了尽可能利用 CPU 的计算能力，我个人也从这个脚本中学到了不少shell 脚本的技巧。

不过，使用 portmaster 需要在每一台机器上都有一份 ports tree，并且由于直接操作的是本地的生产环境，因此对于比较基础的库，如 gettext 之类，或是在升级操作系统时，由于升级时间较久导致出现问题的可能性相对要大一些。另一方面，使用 port 来管理第三方软件意味着需要把联编过程中的所有依赖软件包全都都装到生产环境中，有时这是非常不经济的，例如大部分时候运行环境并不需要完整的跨平台 LLVM，等等，而使用 port 安装的话，每一个系统中都需要整体重新联编一遍。

我之前已经用过很长时间的 poudriere 了。这是一款现代化的联编系统，它充分利用了 FreeBSD 的一系列特性，包括 ZFS 快照/克隆、 tmpfs、jail 等等，支持交叉编译。除此之外它还支持使用 ccache 来减少重复编译，等等。不过，线上的机器出于习惯^H^H懒惰导致的惯性一直还是在沿用之前采用 portmaster 来进行更新。

随便记一笔，备忘。

形如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

dn: mail=foo@somedomain.org,ou=somedomain.org,ou=org,ou=MailAccounts,dc=somehost
mail: foo@somedomain.org
accountstatus: alias
sn: Foo
cn: Foo account at somedomain.org
objectClass: postfixAlias
objectClass: person
maildrop: delphij@delphij.net
maildrop: someone@example.org
maildrop: someoneelse@example.edu
maildrop: anotherperson@somewhere.com

这样一个项目，希望把后三项删掉。