【歪门邪道】网站迁移总结

今天上午终于完成了网站的整体迁移，历时不到5天。不知道这期间有多少朋友注意到了迁移导致的服务中断呢？本文将讨论这次迁移的全过程，以及我的一些想法。

迁移数据库

在迁移公告这篇文章里我提到的这次迁移的主要目的：

• 使用Linode的托管数据库
• 试图切换到WordPress来避开Typecho部分不成熟的功能

实际上在发出这篇公告之前，网站就已经迁移到Linode的托管数据库了，这个过程还是相对无痛的：

1. 将现有的数据库导出成sql格式
2. 连上Linode的托管数据库，导入sql文件
3. 修改Typecho设置，让Typecho使用新的数据库配置

从原理上来说这个过程不应该遇到任何麻烦，因为数据库的内容是完全没变的，只是相当于换了个地方。但是托管数据库和自建数据库不同，自建数据库运行在127.0.0.1上，通常只需要设置好密码就行了，不需要传输层加密，类似于以前的HTTP。但是托管数据库不一样，数据库位于公网的其他位置，如果继续使用明文协议，很容易会受到中间人攻击，因此需要传输层加密，也就是使用SSL连接。但是目前主流的博客平台似乎都没有考虑到这一点。在安装过程中WordPress不支持设置SSL证书，但安装完成后可以通过设置一个变量来启用相应的支持。而Typecho就不一样——压根儿不支持。好在我看到GitHub上有人提了pr，我把对应部分的修改应用到1.2.0版本上，完美可用。截至1.2.1-rc版本发出时，这个pr还没有合并，但截至本文发布时这个pr已经并入主线，不知道能不能赶上1.2.1的发布。

迁移完数据库，我注意到了公告中提到的this is incompatible with sql_mode=only_full_group_by，变萌生了迁移网站的想法。

迁移服务器

为了避免网站服务不受中断，所以我决定暂且将旧的网站搬迁到一个临时服务器上，以便我在这个服务器上尝试新的东西。这个过程也比较顺畅：

1. 开一台新的服务器，装好lnmp之类的软件
2. 使用rsync把网站复制过去，改好权限
3. 保持nginx配置不变，原封不动把网站配置和证书复制过去
4. 修改DNS记录
5. 等待旧的DNS记录失效后，验证网站是否还在如期工作

我印象中这部分好像没有遇到太多问题。在等文件迁移的过程中，我发现Typecho的作者已经声称修复了那个聚合查询的问题，但我还是遇到了。本着科学的原则，我打算深入研究一下这个问题。

我新装了一个干净的Typecho，建立了一个测试分类，又在这个分类里面创建了一个子分类。在旧的网站中，查看测试分类的页面会抛出聚合查询错误，而新装的typecho就没有这个问题。我很是费解，但是我又不会PHP，这怎么办呢？

本着自己动手丰衣足食的原则，我一边查谷歌，一边用记事本改PHP文件，开启了Typecho的debug模式，找到了报错的点，尝试使用var_dump查看出错的查询，我发现出错的点在于查询中使用了无关于内容的表。在新的Typecho中，查询分类的select部分只选择了table.contents这个表的内容，这十分合理——分类页面会列出这个分类下的文章，而文章都存储在contents表里。但是旧的Typecho则直接变成了select *，而后面用到了join，就会导致这个查询不光select文章表的内容，还会select到后面join进来的表的内容，这就导致了聚合查询的错误。

找到了问题所在，那我就要看看为什么这两个select的不一样。经过一番查找，最后发现是一个插件修改了select语句。这个插件年代久远，是统计文章阅读量的。工作原理就是访问文章的时候给数据库字段加1，查询文章的时候会查询数据，一并把阅读量作为结果返回。而又经过一番查找，我发现这个插件的作者后来提供了一个不需要数据库字段的实现：Typecho文章都可以设置自定义字段，如果把数据库字段改成文章的这个字段，岂不美哉？

只可惜我目前使用的主题依赖这个插件，不知道以后作者会不会修改。不过就算作者修改了，这样统计阅读量也有问题：这种统计方法是建立在执行PHP代码的基础上实现的，如果使用了CDN，那么页面就会被缓存，下次请求的时候就不会再触发PHP代码了。这么看还是基于JS的解决方案比较好，但我对于阅读量也没什么执念，我只管写的开心，别人爱看不看。

找到了问题所在，禁用了插件，问题解决，这下不用非得换WordPress了。

评估新的博客系统

当然，我还是想试试看WordPress的，于是就安装了。结果我大受震撼，不禁发表了如下感想：

这一回，是我自己发昏，竟想着换到 WordPress 去了。

我装好了 WordPress 一看，什么都要钱。好不容易看上一个主题，要价 59 美元我就不说了，好东西值好价，但是他妈的 59 美元竟然不支持 Dark mode？

以及什么评论同步 IFTTT 和 Pushover 竟然也都是要钱的，我真的麻了。

更让我不理解的是，插件要钱，竟然还是按月收费。WP Reset这个插件的作用是把WordPress给你回复出厂设置，但是要按月订阅，我他妈每个月都给我的博客重置一下，我是不是有病？作者是不是有病？

更何况，WordPress程序运行在我自己花钱租用的服务器上，你这代码也运行在我的服务器上，一次结清我尚且还能够理解，他妈的我自己花钱租服务器，还得花钱买软件？这不大冤种吗？这软件我要是用得上，还则罢了。他妈的一个恢复出厂设置的插件，按月收费？

还是他们挣钱狠啊

是的，WordPress作为一个强大的CMS，大家似乎更看重将其打造为电商平台。比如说使用Pushover和IFTTT推送通知，这个是针对订单的。想要通知评论？没门。

这么看我还是继续用我的Typecho吧。

配置服务器

在把网站迁回来之前，我想重新配置一下服务器。这个服务器之前用的系统是Debian 10，虽然很干净，但升级的时候总是不太方便，而我喜欢的OpenSUSE似乎又太冷门，服务商没有提供这个系统。最后我选择了Ubuntu 2204 LTS，虽然我不太喜欢Ubuntu背后的商业公司，但是Ubuntu在易用性上还是挺好的，至少大版本升级的时候不会那么痛苦，而且和Debian一样可以共享类似的软件源。

设置好之后，为了保证安全性，我安装了fail2ban，这个软件的功能比较强大，但我这里的主要用途是防止ssh被破解。如果一个人在短时间内连续多次登录ssh失败，这个软件就会把这个人的ip封禁一段时间，阻止暴力破解。在安装这个软件的过程中有两个问题：

• fail2ban抓不到ssh失败的记录，后来发现要设置ssh-backend为systemd，默认backend是不行的
• fail2ban没办法封禁ip，后来发现是非标准ssh端口导致的，不要写什么port = ssh, 1234，直接写port = 1234，然后在action里面也写port=1234，重启之后就万事大吉了。

最后为了防止我自己忘记密码，我还设置了Tailscale SSH。一开始我以为这东西就是通过Tailscale访问SSH，结果尝试之后才发现不是这样的——使用Tailscale SSH不再需要密码或密钥认证了，只要Tailscale控制台允许你访问对方的ssh，那么不需要任何密钥，可以直接登录。这也太爽了吧！

但是为了避免出现安全问题，我在访问控制里设置了如下规则：

• 一共有两个标签：device和server
• 我的个人设备被列入device
• 我的服务器列入server
• device访问server无需认证
• 其他成员可以互访，但访问之前需要使用我的tailscale账号认证

这样一来，即便我的服务器被黑了，它也没办法通过tailscale访问到我其他的设备。如果我的设备丢了，我只要在控制台上关闭这台电脑的访问权限就可以了。

最后，关于PHP，我选用的版本是PHP 8.1，开启了JIT。我并没有直观的感受到JIT带来的性能提升，但看网上评论好像都还不错，就先开着吧。

迁移网站

迁移网站并不只是原封不动的把网站迁走在迁回来。这里做了两个修改：

• 取消www.skyblond.info：在旧的网站中，很久以前博客使用了诸如www.skyblond.info/2022/10/23/678.html的格式，但后来变成了skyblond.info/archives/678.html的格式，但为了兼容原来的url，特意设置了一个www.skyblond.info的vhost，让nginx把旧的url重写成新的url。这一次迁移的时候，在迁移数据库的过程中就把原来所有的www.skyblond.info都改成了对应的新的skyblond.info
• 额外增设statics.skyblond.info：在旧的网站中，诸如图片、随机背景这些静态资源全都是和网站挤在一起，我觉得这样不是很优雅。于是将图片这些静态资源单独做了一个vhost，便于管理。

在安装好对应软件和插件之后，我一边复制数据库一边进行上述修改，按道理来说应该不会有什么问题。但是问题偏偏就发生了：我自己写的评论通知IFTTT和Pushover都没有问题，唯独那个评论通知邮件的插件坏了。无论我怎么调试，都不太行。最后折腾了两天，实在搞不定，我一想，我可去他妈的吧。

新的插件

虽然话是这么说，但是没有邮件通知不行啊。我左思右想，有了一个好办法：

ITFFF和Pushover都是同POST的方式把评论推送到对应的平台，那我也可以用类似的方式把评论推给Java，然后再让Java去发邮件

后来我简单验证了一下我这个想法，发现还挺可行的。于是写了一个简单的插件，来将评论数据推送到指定的URL上。然后再由Java程序进行处理，无论是发邮件还是通知其他平台，都比PHP自由多了。

这里有如下几点考虑：

• PHP插件方面，使用了Joyqi在新版本引入的异步服务，可以保证评论通知的处理不拖慢系统处理评论的速度
• Java方面，收到评论数据后尽快结束请求，不占用过多的PHP资源
• 关于部署，Java这边使用了Docker，配合GitHub Action的自动构建镜像，可以简化推送代码到使用成本的流程；同时为了减小Java的内存占用，这里用了IBM semeru JRE（OpenJ9），这个JRE的主要特点就是节约内存

因为本篇的重点在于迁移网站总结，而不是插件开发介绍，所以在代码方面就不多介绍了。Java发邮件是真方便，但是邮件系统不支持utf-8是真闹心。

总结

这次搬迁网站虽然看起来好像没有什么实质性的大变化，更像是把网站搬走再搬回来，不过这个过程中确实整理出来了一些资源。例如把数据库挪走了，我就可以把大部分软件迁回到这个CN2线路的服务器上了，而不用再忍受德国机房的渣网络。

总体来说这次迁移好像也没什么太大的问题，那就先这样吧。

---

【歪门邪道】网站迁移总结 由 天空 Blond 采用 知识共享 署名 - 非商业性使用 - 相同方式共享 4.0 国际 许可协议进行许可。
本许可协议授权之外的使用权限可以从 https://skyblond.info/about.html 处获得。