永远不要使用二级域名作为 Linux Hostname

我们常常使用 Linux 的 Hostname 来标识一台服务器。Phil KarIton 曾说过:

计算机科学只存在两个难题:命名和缓存失效。

如何想出一个有意义、便于运维,甚至有个人风格(对于个人服务器来说)的 Hostname 也是一件难事。曾有一个有趣的 RFC —— RFC 1178: Choosing a Name for Your Computer 给出了一些关于命名 Hostname 的建议。

在这份 RFC 中,曾经提到了「不要使用域名或类似域名的东西作为主机名」:

Avoid domain names.
For technical reasons, domain names should be avoided. In particular, name resolution of non-absolute hostnames is problematic. Resolvers will check names against domains before checking them against hostnames. But we have seen instances of mailers that refuse to treat single token names as domains. For example, assume that you mail to “libes@rutgers” from yale.edu. Depending upon the implementation, the mail may go to rutgers.edu or rutgers.yale.edu (assuming both exist).

Avoid domain-like names.
Domain names are either organizational (e.g., cia.gov) or geographical (e.g., dallas.tx.us). Using anything like these tends to imply some connection. For example, the name “tahiti” sounds like it means you are located there. This is confusing if it is really somewhere else (e.g., “tahiti.cia.gov is located in Langley, Virginia? I thought it was the CIA’s Tahiti office!”). If it really is located there, the name implies that it is the only computer here. If this isn’t wrong now, it inevitably will be There are some organizational and geographical names that work fine. These are exactly the ones that do not function well as domain names. For example, amorphous names such as rivers, mythological places and other impossibilities are very suitable. (“earth” is not yet a domain name.)

使用域名作为 Hostname 不仅是一个技术错误,还会带来潜在的信息安全问题,尤其是对于使用二级域名(例如 example.com)来说。就在刚刚,我碰到了一个生动的例子。

阅读更多

谈谈 GitHub

laike9m 先生曾于 2019 年撰写了题为 People Die, but Long Live GitHub 的博文。文章提出了一个颇有思考价值的问题:

如果你希望存储一段信息,让 100 年后的人也能访问,要怎么做?

他给出的答案是:

想来想去,也只有 GitHub 了。

近日在 悼念陈皓先生的博文 中,他也再次重申了这个观点:

Elon 想删除不活跃的账号,而 coolshell 也总有一天会因为欠费或域名到期而下线。此时,我也不得不再贴一次 《People Die, but Long Live GitHub》,希望大家开始认真思考这个问题。

但是 GitHub 其实和其他互联网服务并没有什么区别。你所珍视的东西,你所需要托付的东西,他们理论上却可以自由支配——尽管有着法律、隐私政策和公司规章的限制,但这些限制也可能成为他们支配你的数据的理由。

阅读更多

配置基于硬件安全的 Linux:TPM2/FIDO2 解密 LUKS 全盘加密和 U2F 用户登录

前置知识:UEFI 下 Linux 的引导过程

由于 BIOS 下实现 TPM2 解密 LUKS 较为困难,本文仅介绍 UEFI 下 Linux 的引导过程。本文所给出的方案,也仅适用于 UEFI (非 CSM) 环境。

简单的说,UEFI 下 Linux 的引导过程如下:

  1. 读取 EFI 分区中的 EFI/BOOT/BOOTX64.EFI,并执行。
  2. 该 EFI 程序找到 /boot 分区,并读取配置文件。这一步是可选的。
  3. 根据配置文件,加载 Linux 内核和 initramfs。这一步是可选的:大多数发行版都有 initramfs,如 Arch Linux、openSUSE、Ubuntu 等。一些嵌入式发行版没有 initramfs,如 OpenWrt。
  4. 执行 initramfs 的 init 脚本,init 脚本挂载主目录,然后使用 exec 启动 systemd 或其他 init 程序。

需要注意的是,引导器、initramfs 和系统 init 是三个不同的东西:

  • 引导器:负责加载 Linux 内核和 initramfs,如 GRUB、systemd-boot、rEFInd 等。
  • initramfs:一个微型的、用户态的 Linux 镜像,负责挂载主目录,启动系统 init 程序。常用的 initramfs 可能基于 busybox 或 systemd。
    • 值得注意的是,initramfs 和 initramfs 生成器并不是同一个东西。常见的 initramfs 生成器有 dracut、mkinitcpio 等。
  • 系统 init:是 PID=1 的进程,负责启动并管理进程和服务。常见的系统 init 有 systemd-init、sysvinit、OpenRC 等。
    • 事实上,早在 initramfs 时期,PID=1 的进程就存在了。通常这个进程是一个 shell 脚本,但也有的 initramfs 不同。随后,initramfs 的 init 脚本会通过 exec 方式启动系统 init。因此,它们具有相同的 PID=1

此外,这三个东西一般情况下是可以自由组合的。可以使用「GRUB + Systemd-based initramfs + Systemd-init」,也可以使用「systemd-boot + Busybox-based initramfs + SysVinit」。主流的发行版选择的是「GRUB + Busybox-based initramfs + Systemd-init」。如果你非常喜欢 Systemd,那么你可以使用「Systemd-boot + Systemd-based initramfs + Systemd-init」。

兼容问题

  • Systemd-boot 引导器
    • /boot 目录必须和 / 在同一分区
    • 需要 EFI 驱动以支持 XFS、Btrfs 等文件系统,且 似乎 不支持 btrfs subvolume 作为根文件系统
    • 需要修改 /root 分区的 GPT GUID 才能支持 / 加密
  • GRUB 引导器
    • 不完整支持 LUKS2
    • 不支持 TPM2/FIDO2 解密 LUKS
  • Systemd-based initramfs
    • 不支持 LUKS1

除了上述兼容问题外,由于引导器和 initramfs 无法互通加密密钥,每次启动您都要重复解锁两次 LUKS 卷。可以选择不加密 /boot 分区来解决此问题。

阅读更多

在 VOCALOID 5 Editor for macOS 上安装 Windows 版的 VOCALOID 3 声库

最近换了一台 Apple MacBook Air M2,感觉从 Windows 切换到 macOS 还是很不习惯的。虽然编程方面的配置比较方便,但是日常使用上的操作方法还是区别很大。

由于我购买了洛天依和乐正绫的 VOCALOID 3 声库,因此当我在 macOS 上使用 VOCALOID 时,就遇到了不兼容的问题。本文给出一种正版可以在 macOS 上安装、激活并使用Windows 版 VOCALOID 3 声库的办法。

为了获取声库文件,需要一台 Windows 计算机。

阅读更多

在启动时自动解锁 LUKS

LUKS 是 Linux 上通用的磁盘加密方式。只有持有密码或密钥文件,才能解锁 LUKS 卷。其作用和 Windows 中的 BitLocker 类似,但是不使用封闭、且并不安全的 TPM。

注意:本文所述的操作,将会导致您的加密卷实质无效,并可能造成信息安全的重大损失。请在慎重思考,并明白自己正在做什么之后,再进行操作。

阅读更多