选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
这篇和较早的 线上重做 FreeBSD GPT 引导分区 情况有些类似，但略有不同。
前段时间 Andriy Gapon 为 Samsung 860 / 870 SSD 增加了一个 quirk。 Samsung 的 SSD 内部使用的是 8K 或 16K 的存储页，但为了和业界标准兼容， 它的控制器为 4K 扇区做了优化。
Read more...今天在家里的票务系统上修改某个票的状态（该操作会出发点一封邮件）时， 我正好另一个窗口开着邮件服务器的日志，观察到一些奇怪的现象：
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: self-signed certificate
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
to gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
(2048 bits) server-digest SHA256
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
gmail-smtp-in.l.google.com[142.250.142.26]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
to gmail-smtp-in.l.google.com[142.250.142.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
(256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
to alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
(2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: self-signed certificate
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established to
alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
(2048 bits) server-digest SHA256
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Verified TLS connection established to
alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA
(prime256v1) server-digest SHA256
Mar 19 20:17:15 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: to=<XXXXXXX@gmail.com>,
relay=alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25, delay=2.8,
delays=0.06/0.1/2/0.66, dsn=2.0.0, status=sent (250 2.0.0 OK XXXXXXXXXX
XXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.XX - gsmtp)
今天来讲个关于备份的小故事。
以前有个同事之前在某使用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...