本文介绍如何通过 iTunes 官方途径下载 iOS 旧版本应用。该方法 不需要 Apple Developer 账号、无需越狱、无需自签名。

此方法截至 2024 年 4 月 1 日可用。

开始前请准备以下工具：

• 一台 x86 架构 Windows 操作系统的电脑 (可以使用虚拟机)
• 一个 未开启安全密钥认证 的 Apple 账号

阅读更多

本文将简述近期笔者在 Arch Linux 上自建 NAS 的过程，兼谈个人对 NAS 的思考和看法。本文主要起记录作用，并不作为配置参考。

系统构成

• 2x WD Red Pro 4TB HDD (使用主板 RAID 功能构建 RAID 1)
• 1x Samsung PM981a 256GB NVMe SSD (仅用于缓存)
• 作为虚拟机运行于 Proxmox VE 7.2 上

笔者的 NAS 并不是一个「标准」的 NAS。经过对个人需求的分析，笔者选择了不同于传统 NAS 的配置——本文将在后面介绍这样选择的考虑。

Arch Linux 的安装过程在此不再赘述。

阅读更多

Zikin 在《使用 Cloudflare Zero Trust 保护 SSH》一文中介绍了如何使用 Cloudflare ZeroTrust 保护 SSH 的方法，同时也提供了 对于网页的保护方法。本文主要补充使用 Cloudflare SSH CA 替代 SSH 公钥的使用方法，以及在部署实践中值得注意的地方。

使用 Cloudflare SSH CA 替代 SSH 公钥，可以使用 GitHub 账户或其他 OpenID Connect 方式登录您的服务器 SSH，而无需私钥或 SSH 密码。这样可以避免私钥泄漏、忘记携带私钥，对于团队统一管理多个服务器、多个用户、分配不同的服务器权限也十分有用。

由于此方法也无需在 Cloudflare WebSSH 界面输入私钥或密码，对于不信任 Cloudflare 传输私钥的场景，也可以使用此方法。

部署中的注意事项

1. 对于非 HTTP 应用，Tunnel 需要占用整个域名——不能将 WebSSH 部署在子路径下。
2. 对于多个服务器部署，不可以将多个服务器连接到同一个 Tunnel。需要为每个服务器创建单独的 Tunnel。
3. 对于多个服务器部署，不可以多个域名共用一个 Application。
4. 不可用使用四级及以上域名（如 server.ssh.example.com）。Cloudflare 不会为四级及以上域名签发 SSL 证书。必须使用三级域名（如 server-ssh.example.com）。
5. 对于 Arch Linux，删除 Tunnel 之后需要执行 rm /etc/systemd/system/cloudflared* 删除残留的服务文件。
6. 即是使用 Passkey 登录 GitHub 来通过 Cloudflare ZeroTrust 认证，Cloudflare 依然不认为登录方式为 fido2——除非您使用付费的登录管理平台（如 Okta、Duo 等）。因此请不要在登录策略中添加登录方式为 fido2 的要求。
7. 您的邮箱前缀（如 luotianyi@example.com 的前缀是 luotianyi）必须与您的 Linux 用户名相同。否则 Cloudflare ZeroTrust 认证会失败。

阅读更多

我们常常使用 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）来说。就在刚刚，我碰到了一个生动的例子。

阅读更多

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

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

他给出的答案是：

想来想去，也只有 GitHub 了。

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

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

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

阅读更多