选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
今天来讲个关于备份的小故事。
以前有个同事之前在某使用UNIX的传统行业干了多年，他们的系统可用性要求不算高，但数据非常重要， 所以备份自然也是必不可少的。为了确保备份的安全性， 他们还雇了一家专门的保全公司定期把备份磁带从办公室拿走到该保全公司的仓库。
一切看起来万无一失，直到有一天他们的系统出现了问题，需要从备份中恢复数据。
自然，有那么多份不同时间的磁带的系统管理团队是不觉得有什么可慌的， 可是等到他们拿回了一大摞磁带的时候却傻了眼。
从磁带中恢复的只有一个符号链接 (symbolic link)。
不仅如此，之前更早的磁带里也都是同一个符号链接。最终他们成功恢复了半年之前的数据， 配合数据恢复公司恢复的硬盘数据，在几个星期之后终于把东西七七八八地怼回看起来是正确的样子了。
这是怎么回事呢？原来，他们在备份的时候选择了一个目录，然后慢慢的这个目录越来越大， 直到有一天有个大聪明表示不如这样吧，我们把数据搬到一块新的、更大的盘上，然后建个符号链接。
系统运行一切正常，甚至于备份也变得快了很多呢。
这个故事告诉我们，做了自动化备份之后，时不时的就得试试看备份出来的数据是不是真的能恢复成希望的样子。
Read more...目前的经济形势下，许多公司都在进行裁员。大部分情况下，作为雇员对于公司是否进行裁员所能做的影响极为有限， 因此有必要提前对可能发生的裁员进行准备，以免仓促之下做出错误决策，或是在大规模裁员导致的踩踏事故面前束手无策。
本文主要是针对在美国境内工作的普通雇员，家里没矿，也暂时还没攒够足够退休的钱。 内容主要来自近期的阅读和想到的一些东西，算是给自己留下一些笔记。
Read more...周三的时候，USPS发来了一封电子邮件，内容如下：
Read more...最近没怎么关注安全方面的进展，结果错过了去年年底披露的 SMTP Smuggling。 这是 Timo Longin 发现的一个全新的针对 SMTP 协议的攻击手法， 现在的年轻人真是蛮厉害的。
Read more...我搞邮件服务器有二十多年了，最开始是在学校做社团的邮件服务， 后来有几年和 老房东 在某领先网络媒体公司做了多年针对公众提供的邮件服务，因此前同事群的名字也是「老邮条」。 我个人的域名是2002年注册的，自从那时起我就一直在自己运行邮件服务。
在过去二十年中的大部分时间，我采用的是 amavisd-new， 与直接使用 SpamAssassin 相比， 它还增加了病毒扫描等一系列功能和 milter 接口，这让它与 MTA 更容易集成。
Read more...12月1日，FreeBSD 发布了 FreeBSD-EN-23:16.openzfs， 用于修正近期发现的 ZFS 数据损坏问题。 这个问题是由 Rob Norris 最终修正的，这里记一笔。
Read more...上周末抽时间把服务器升级到了 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 就是这样的情况)。
Read more...上回书 说到我换到了一个采用微波通讯技术的小型本地 ISP，然而经过将近两年的时间， 我最终还是换回了 Comcast。正如张师傅说的，南湾乡下的居民不配有好东西，经过这么久， 我家这边依然没有 5G 互联网服务，也没有光纤到府，至于 cable 也很自然地也没有 DOCSIS 4.0，也不想想看，您配吗？
为什么要换回 cable 呢？Sail 声称他们采用的设计可以避免雨季带来的干扰，事实来看确实是这样， 但是他们的服务稳定性在过去几个月出现了灾难性的下降，此外延迟由于一些未知的原因增加了不少。 我为此收集了一些数据，发现去大河以及 Google 的延迟有时竟然超过了 500ms，这个就实在是太难受了。
Read more...软件项目中，实现同一功能的源代码只保留一份是一项十分重要的最佳实践，这种做法可以带来许多显而易见的好处：
2009年的时候 kmacy@ 做了 一些初步的工作，但后续没有继续推进。 这之后 我 考虑重新把这个事给做掉，但苦于平时比较忙因此未能如愿。最终， Yoshihiro Ota 完成了大部分的工作。
Read more...这里简单记一笔。我有一个域名使用的是 Google Workspace 的邮件服务。 昨天，一位用户使用该域名向中国的 QQ 邮箱用户发送邮件时被退回了。
退信中给出的线索是：
550 DMARC check failed [XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
IP: 2607:f8b0:4864:20::112b]. https://service.mail.qq.com/detail/124/61.
腾讯给出的那个链接是一篇关于 DMARC 如何配置的文章。 从上下文来看，应该是由于腾讯的服务器认为 Google Workspace 的 IP 地址不在允许发信的范围内。
退信确实是 Google Workspace 的邮件服务生成的，数据来源是和对方(腾讯) MX 之间的 SMTP 会话。
我的这个域名确实启用了 DMARC。我的DMARC记录 (域名下的 _dmarc TXT 记录) 设置如下：
v=DMARC1; p=reject; rua=mailto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX@dmarc-reports.cloudflare.net;
pct=100; adkim=s; aspf=s
此配置要求对方检查 DKIM 和 SPF，并拒绝不匹配的邮件。
其 SPF 记录 (域名的 @ 的 TXT 记录) 设置如下。这是 Google 官方文档中推荐的设置：
v=spf1 include:_spf.google.com -all
主要的区别是，我使用的是 -all，即拒绝 SPF 不匹配的邮件，而不是更为常见的、表示即使发现 SPF
不匹配，也仅仅做标记但允许接收的 ~all。
这里需要说一下背景：在 2004 年左右，一些业内人士认为应该推荐采用
~all 而不是 -all，因为当时许多大型邮件系统的架构中存在多层邮件服务器分别进行不同的过滤处理，
而在 SMTP 会话阶段直接回一个永久性拒绝 (5XX) 代码可能会让一些不适任的邮件系统管理员如此配置的邮件系统将一些伪造了来源的邮件退到不希望的地方。
我并不赞同这样的观点。事实上，在会话阶段进行退信要比在收件方服务器上生成退信并将退信退给发件人或对方域名的 postmaster 要更好：
对于垃圾邮件的发送者，这意味着他们的邮件服务器会立即知道自己的行为被直接地丑拒，
接收方明确告知他们吞下垃圾邮件，而不是继续发送。对于正常的邮件服务器，
这意味着发件人可以立即收到退信从而找到自己的邮件系统管理员，而不是告诉收件人去翻垃圾箱看看是否有自己的邮件。
另一方面，回应永久性拒绝并不妨碍收件服务器对邮件内容进行进一步分析：它完全可以在 DATA
阶段结束时再回拒绝，从而将邮件完整地接收下来但不递给收件人。
当然，历史无法假设，并已经无数次地证明人类根本不配拥有美好的事物。
DomainKey 记录 (域名下的 google._domainkey TXT 记录) 由于与此问题无关，故在此处略去。
该域名启用了 DNSSEC。
Read more...