系统管理

cron 的 PAM 支持

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

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

背景：PAM

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

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

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

如何：重建根 zpool

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

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

备份小故事一则

原载于 Telegram 频道。

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

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

Postmortem: UPS 测试导致系统停机故障的事后回顾

摘要

事故影响

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

问题根源

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

试试看 CyberPower UPS

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

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

线上重做 FreeBSD GPT 引导分区

记一笔。

我现在这台服务器已经用了蛮久(超过10年)了，刚刚安装的时候还是 FreeBSD 8.1 RC，一路升级到 FreeBSD 12.2。 前段时间因为工作比较忙，一直没顾上把它升级到 FreeBSD 13.0，今天总算是找了点时间来做升级。

总体上这次升级比预想的还要平稳一些，由于 FreeBSD 13.0 和 12.2 的内核接口变化不大，因此我也没按照正规的做法， 即升级内核、重启第一次、etcupdate、installworld，重启第二次、delete-old/delete-old-libs，而是在 installkernel 之后直接做了 etcupdate 和 installworld。