目录难得折腾

2020 年个人互联网基础设施更新换代手记

所谓「个人互联网基础设施」,是指能将自己从一般互联网服务提供商中独立出来为人所独立认知的基础服务,比如域名、网站服务器,邮箱,以及将这些东西互相连接的 DNS 服务。——上面这些都是我现编的,不要信。

我的好多服务都是在十月、十一月期间到期需要更新和支付账单。也是出于成本考虑也是出于一时兴起,今年把一些服务迁移的迁移换供应商的换供应商,来来回回也折腾了不少,花钱也花了不少,就在此做个简单的记录。

(更多…)

Sublime Text 3 配置文件说明中文翻译

为了日后查阅方便,将 Sublime Text 内置的默认配置文件的说明部分翻译成了中文。

基于开发版通道(Dev Channel)3175 版默认配置文件内容翻译。最后更新于 2018 年 6 月 21 日。

建议仅将此文件用于查阅,单独将希望修改的配置复制到用户配置文件中,以免被程序更新覆盖或被其它配置文件优先生效。

因为主要用途是查阅,实际配置仍需将所需选项填到用户配置文件里,所以就不给下载了。


(更多…)

部分数据丢失

由于操作失误,博客丢失了所有媒体文件。

加之当下学业繁忙,暂无法逐一检查恢复。

在此期间,博客所有图片都无法浏览。呈现半死状态……

等考完了再慢慢调……OTL

 

Update: 大部分文章题图都已恢复,其他一些文章内的截图由于是当时撰写临时截下的没有备份,所以就当做挂了先放置不管了……

唉。

又是一次当机五日

2015 年网站曾经挂过一次,当时恢复后撰写的文章的开头是这样的:

不知诸君有没有发觉,或者说在各位还未发觉的时候,本站已经挂了五天了。

历史是何其相似——

两年后网站又在各位发觉还没发觉的时候又挂了 5 天。

详细过程我已无心回忆。简单来说就是我想体验 BBR,但是系统内核版本不够,需要升级内核。结果升级完内核重启内核后,系统遭遇了内核错误(Kernel Panic,字面意思的“内核恐慌”还挺中二气的)。在抢救出网站数据备份后开始重置系统,又遭遇了新的问题:运行网站依赖的后台管理面板不能在 ConoHa 的 Ubuntu 上安装,所有网站上不了线。

因为是个软件,所以它的报错是软件内部的报错。无论我怎么修改配置环境,改 Hostname 和 Hosts,都会报没有 IP 可用、不能创建域名、还有“Error: invalid status format :: global”这类错误。

因为报的都同样的错误,我便一直围绕网络环境、Hostname、FQDN、Hosts 配置来作修改,结果全部不顶用。

最后还是在友人的建议下用 Docker 环境把管理面板成功安装回来,才恢复了网站的所有数据并上线。我们终于可以重新见面了。

至于这次经历的感想,一如两年前的那般:不懂就别瞎折腾;要有自己搜索问题、动手尝试和报 Bug 的能力;要多认识几位技术大佬

 

【大坑】CC 协议使用 FAQ

本文属兴致而起的大坑,将会不断持续更新。

本文的以下内容,是根据 CC协议官方FAQ页面 所提供的问答,出于实用目的,选取部分可能会经常遇到的问题进行的非官方、不按顺序、粗浅的翻译。希望这些翻译能够为创作者和使用者提供基本的解答。每个问题的译文都附带了英文原文标题及链接,点击即可前往查看原文。

由于 CC FAQ 提供的内容繁多,本文暂时不会依顺序逐条翻译,而是有选取的进行翻译,并不断予以更新。如果你认为某个问题应优先予以翻译,或你有意协助翻译,还请留言或私信告知。如果翻译的译文有疏漏或表述不清而使人疑惑的地方,亦请不吝赐教。

需要注意的是,本文提供的翻译仅能够作为参考之用途。受译者水平所限,有些内容可能无法确定翻译的表述是否符合原文或法律上的概念规范。在翻译过程中,对于某些中文概念无法明确,或对于其确切法律定义存疑的词汇,会在译文后以括号形式附上英文原文,以备参考。

本文采用 CC BY 4.0 协议进行授权。

(更多…)

为网站签发 ECC SSL 证书

ECC 是椭圆曲线密码学(Elliptic Curve Cryptography)的英文缩写,是一种建立公开密钥的加密算法。与流行的 RSA 算法不同,它在 SSL 的应用中主要优势是它的密钥、请求与证书长度都更短,对移动设备更友好,也是安全证书厂商们未来力图推广的一种证书算法。其缺点在于算法复杂、加密解密耗时较长,从诞生时长上讲也未经过足够长久的安全检验。

以 Comodo 的证书为例,Android 5.0.1 系统收录了其发布的 ECC 算法证书,但是并未收录它的 RSA 证书,这就导致本站在换证书之前在手机上访问都会受到红锁头提示。

(更多…)

不懂就别瞎折腾

不知诸君有没有发觉,或者说在各位还未发觉的时候,本站已经挂了五天了。

其实个中缘由非常复杂,几乎是从我作了第一次死开始 VPS 后台的问题就接连发生。

首先是想自己折腾一下为网站提供 Chrome 下试图推广的 Certificate Transparency 信息,这个一般是 EV 级证书的网站的标配,很少有有普通的网站添加这个信息。如果跟着 Certificate Transparency 组织官方提供的指南的话,主要工作是提交证书链以获取相关的证书透明度证明文件。只是这些文件要被正确使用,需要相应的扩展模块,对于 Nginx 现在推荐的是 nginx-ct 。不过问题就是,如果使用了相关的可视化管理面板(例如我用的是 Vesta)并且面板自安装了 Nginx 的话,可能就会摸不清应该在哪里导入模块的变量……
结果我就傻逼兮兮地重新覆盖安装了 Nginx。
想当然地,面板写入 Nginx 的相关配置就被覆盖了,没有提前备份所以最后落了个网站全部访问不能只能重安面板的结局……

自这次折腾以后,后台的 SS 莫名地就只能听 IPV6 而不能监听 IPV4了,SS-Py 下端口状态里连对 IPV4 的监听都没有,切换到 SS-Libev 后虽然端口能够监听 IPV4 了但是实际使用中还是不能连通。特别诡异的是自始至终手机端都是能连通到服务端的。通过 tcpdump 抓包发现只有手机端向 VPS 发送报文但 VPS 从未向手机端回发报文。

这边还没解决,紧接着接到一位好心人士发来的邮件,告诉我网站不能够留言评论了,原来这么久都没有新留言的原因是这个。为了检查这个错误,我尝试过重装 WordPress 核心,排查插件、主题是否有干扰,最后一怒之下爆破了 VPS 重装面板,又遭遇了面板无法安装只能求助于开发团队。

结果 Vesta 开发团队说我们帮你安吧,就真的花了好几天来帮我处理这件事情(虽然其中大部分时间浪费在我的失误上),最后也重新安装上了,折腾到今天凌晨2点。总觉得不买他们的收费项目支持一下都过意不去了……

面板重新安装好后导入原先的配置发现问题依旧,绝望之余只能重新排查。最后终于在最开始看过以为没问题的 .htaccess 文件中发现端倪……

其中一行是这样的

RewriteCond %{REQUEST_URI} .wp-comments-post\.php*

里面应该写成斜杠的地方写的是反!斜!杠!

把这个地方改好了以后我怀着忐忑的心情发了一条留言,还真的发出来了。

……

我都不知道这几天我浪费的时间意义何在……大概就是教训自己做事要细心,代码要耐心读吧。

OTL

为 WordPress 全站开启强制 HTTPS 访问

其实早在2月份就已经给域名配置了 SSL 证书,但是当时只用于 VPS 后台的访问,后来给 WordPress 后台也添加了强制 HTTPS 访问,今天则终于给全站都开启了强制 HTTPS 访问。

实际上对于开启 HTTPS 访问并不是难事,对于我而言只要在后台管理面板里导入证书就可以了。但是全站强制访问和激活 Chrome 上的小绿锁就需要另外的配置了。

(更多…)